[Framework-Team] Re: content tab switching

Godefroid Chapelle gotcha at bubblenet.be
Wed Feb 28 08:48:00 UTC 2007


Wichert Akkerman wrote:
> As you're all probably aware there has been some discussion recently
> about the kss based content tab switching feature in Plone 3. I have
> tried to get a good grasp on the situations and this is what I came
> up with.
> 
> This discussions revolves around the implementation of PLIP 121
> http://plone.org/products/plone/roadmap/121 . This PLIP documents
> a single reason for doing in-place replacement of the content view:
> performance. Only reloading the content view but keeping the rest
> of the page in place should be a lot faster.
> 
> Looking at the current situations there are a few problems:
> 
> - the in-place loading behaviour breaks the back button. This breaks
>   user expectations and leads to frustration. 
> - one of the risks mentioned in the PLIP mentions is that the tabs are
>   no longer bookmarkable but says that we are willing to sacrifice this
>   for the speed benefits. Later user testing has revealed that this
>   might not be acceptable.

I see those two points as a singe point and as the major current 
problem. I have started to look at history issues... which we will need 
to solve in short-middle term anyway as this is a generic problem.

For instance, the user doing selections with the selection widget could 
also need back and forward navigation.

> - at this moment the in-place reloading is not faster. The AT edit forms
>   are too heavy, so loading the edit tabs takes long enough to negate
>   any benefits from not reloading the whole page.

This is true for edit form but what about the others...

Because we render all fields (which was not the case before), improving 
the performance of the rendering of the edit tab is something that we 
should tackle before final anyway.

The edit tab was already painful in 2.1 and 2.5... :-(

This is unrelated to KSS issues.

> - javascript triggers do not work correctly when replacing the content
>   (autofocus, form unload protection)

AFAIK, form unload protection bugs are supposed to have been solved. Any 
issues remaining ?

Autofocus is a problem we will need to solve generically, exactly as the 
history stuff above...
What I mean is that we need to add "SetFocus" code to KSS so that we can 
explicitely autofocus to the first field.

Are there other issues ?

> 
> This makes me think that at this moment we should not ship with the
> in-place content tab replacement functionality enabled. The concept is
> still good, but in order to realize the desired benefits we need more
> extensive work: the edit forms have to become a lot simpler and cleaner
> and we need to find a way to keep the browser history updated so the
> back button keeps working. We might be able to take some inspiration
> from what gmail does. It is definitely a direction in which we should be
> going.
> 
> Opinions? Thoughts?
> 
 > Wichert.


I have the feeling that, if we just disable those stuff now, the generic 
problems they trigger will never be solved.

OTOH, I totally agree that 3.0 final should not ship with stuff we know 
is really not usable.

I propose that we keep the stuff as late as possible, trying to solve 
the history and autofocus issues and postpone the decision.

IMO, postponing is not a risky decision as it is so easy to do the 
disabling : comments in a single file.

This will give chance to Balazs and I (and others that would like to 
contribute) to improve KSS on those aspects.

I am wondering if it would make sense to do ajax switching for all tabs 
except the edit tab.  IOW when clicking edit, we would get a full page 
reload but not when clicking other tabs.


-- 
Godefroid Chapelle (aka __gotcha)- BubbleNet  http://bubblenet.be





More information about the Framework-Team mailing list