cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: CForms' shortcomings
Date Thu, 09 Sep 2004 16:51:44 GMT
Ugo Cei wrote:

> Don't get me wrong, I love CForms, but there are some problems WRT 
> usability of the generated HTML pages.
>
> CForms gives you some very nice features, like repeaters and attaching 
> scripts to widgets to be executed on the server when some event 
> happens (see the Carselector sample).
>
> But when you start using those features, you run into usability 
> problems due to the fact that those events are handled on the server 
> and so require a client-server roundtrip and, what is most painful, a 
> full redraw of the GUI.
>
> Whenever you form is so large as to require vertical scrolling, every 
> time the GUI is redrawn, you lose focus and lose the vertical scroll 
> position.


About vertical position, I've been thinking about sending it in a hidden 
field along with other form values, so that it can be sent back in order 
to set it whenever the form is redisplayed. Just a workaround the 
problems you mention below though.

> If you click the back button, you aren't sent to the page before the 
> form, but to the version of the form before the handling of the event.


I've seen webapps where hitting back reloads the previous page, probably 
because of some clever expiration headers. If we modify form.showForm() 
so that the same continuation is always used (using what's in 
v2/form.js), that could be a way to reload the form in its current state 
whenever the user hits the back button.

> If you click the reload button, the browser asks you if you want to 
> resend your POST request (try to explain this to your customer).


Well, your customer must be very new to web browsers if he never saw 
this message before...

> This really sucks!


Sure :-)

> Actually the problems are not CForms' fault, but HTTP's, as we all 
> know. HTTP just wasn't designed to handle these kinds of use-cases.
>
> We could turn to some proprietary technologies for a solution (XAML, 
> XUL, Flash, ...), wait for a usable XForms implementation or use Java 
> applets (brrrr). Or we could use something that is cool, available now 
> and a de-facto standard. I mean, something like XMLHTTPRequest [1].
>
> In order to show what I mean, I decided to create a small sample, so I 
> just committed a modified carselector sample in the trunk. It's not 
> linked from the samples page, but you can find it at 
> <http://localhost:8888/samples/blocks/forms/xhr_carselector>. I hope 
> you agree with me that it's much better, usability-wise, than the 
> original carselector.
>
> I think CForms should include some kind of support for this, in order 
> to make is as easy as the current methods are, and if you agree with 
> me, you are welcome to try and make this happen.


+1000.

There are some limitations to this though, as it mostly applies to 
roundtrips that do not modify the form's structure. In other cases, such 
as adding a repeater row, we could end up with reinventing XUL to make 
it happen using xmlhttprequest.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }


Mime
View raw message