On 01/30/2012 06:51 AM, Andy Fitzsimon wrote:
Hi all,
Hi Andy,
overall it looks great.
<snip>
## Graceful degradation
Support for all core functionality in as many scenarios as possible
* New browser features (subtle animation, gradients etc)
* Older browsers lacking features
* Browsers with javascript turned off
-1
Taking the risk I'll be stoned to death. It sounds great when written on
goals-list and 2 years ago I would happily agree with this. But in
practice this turned out to be very painful on this project. Though I'll
probably change my mind if I'll see that new "single-page-app" approach
could work ;).
I think any user with JS turned off (<2%) will use our API/CLI instead
of UI anyway.
* Screen readers (section 508, we’re going there)
******
<snip>
******
## View anchors - or 'single page app'
View anchors are portions of our design implemented within the one DOM using basic
anchoring functionality.
### Explained
In the proposed change, the entire conductor is one page for all default views,
Somehow I can't imagine how this could work in Conductor. From text
bellow and from demo (
http://file.bne.redhat.com/~afitzsim/static/) the
plan is to load whole Conductor (or some part) in one request, JS is
used only for hiding inactive parts.
I suppose you don't mean whole Conductor (including all views), but only
some logical subsection, right? But even inside a subsection are usually
many pages which can't be preloaded - all object show pages, edit pages,
index pages for nested resources...
In your demo page I see, that you have separate edit form + anchor for
for each provider, then you have list of accounts for each provider,...
It will take ages to load all this content in single page.
1. Link anchors will activate the specific view or sub-view.
2. Anchors that do not resolve will initiate a "cannot find" message which will
most commonly occur when a user does not have access to an object and has manually entered
a custom # URL. the two exceptions to this will be ~/# and ~/#top which will initiate the
default app view.
### In action
For example:
> The URL below should open the admin> providers> ec2eastcoast>
connectivity view.
https://conductor/#ec2eastcoast-connectivity
^ ^ ^
Server ObjectID ChildView
#### What the html does
e.g. the `<div>` representing admin> providers> ec2eastcoast would look
like
<div id="ec2eastcoast">.. ec2 east coast information goes here
and the connectivity tab which exists inside the ec2eastcoast provider would look like
<div id="ec2eastcoast-connectivity">
^ ^
objectID ChildViewname
Why?
Because the provider _ec2eastcoast_ lives natively within the _admin> provider_
section, it does not need to be referenced in the ID.. it simply has to be unique. But
because the connectivity tab is only unique because of the provider it is associated with,
it needs to be prefixed with the objectID
All direct links to the provider view would look like `<a href=#ec2eastcoast>EC2
East Coast</a> which would activate the provider tab.
#### what JS does
1. JS hides all non active views except for the default view (classed as active by the
js)
2.
3. when an ID is requested the object and all parent views get classed `.active`
4. [hashchange for old
browsers](http://benalman.com/projects/jquery-hashchange-plugin/)
to preserve browsing history
Jan