You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Ugo Cei <ug...@apache.org> on 2004/09/09 18:00:20 UTC
CForms' shortcomings
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.
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.
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).
This really sucks!
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.
Caveat: the sample works with Mozilla (1.6) and Safari (1.2) but not
with IE. I haven't got a Windows machine and even if I had one, I
wouldn't know where to start debugging javascript code, so I hope some
Windows user will kindly provide a fix. Shouldn't be hard.
Ugo
[1] http://developer.apple.com/internet/webcontent/xmlhttpreq.html
--
Ugo Cei - http://beblogging.com/
Re: CForms' shortcomings
Posted by Sylvain Wallez <sy...@apache.org>.
Ugo Cei wrote:
> Il giorno 09/set/04, alle 18:51, Sylvain Wallez ha scritto:
>
>> 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.
>
>
> I wasn't even aware that you could determine the scrollbar's position,
> not to mention setting it.
It's available in most browsers in strict mode using either
document.documentElement.scrollTop or document.body.scrollTop.
See http://www.quirksmode.org/viewport/compatibility.html
>>> 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...
>
>
> Yes, some of them are not familiar with using the Internet at all,
> besides causal surfing.
:-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: CForms' shortcomings
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 09/set/04, alle 18:51, Sylvain Wallez ha scritto:
> 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.
I wasn't even aware that you could determine the scrollbar's position,
not to mention setting it.
>> 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...
Yes, some of them are not familiar with using the Internet at all,
besides causal surfing.
Ugo
--
Ugo Cei - http://beblogging.com/
Re: CForms' shortcomings
Posted by Sylvain Wallez <sy...@apache.org>.
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 }