cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: [RT] Modernizing CForms
Date Mon, 19 Mar 2007 17:34:15 GMT
Grzegorz Kossakowski wrote:
> Daniel Fagerstrom napisaƂ(a):
>   
>> I don't propose that we should throw out the current Forms framework.
>> What I do propose is that it could be improved so that it would
>> require less work to use and so that it would support AJAX+REST style
>> webapps better.
>>
>> Don't repeat yourself
>> =====================
>>
>> As an alternative to using XML configurations for form definition and
>> binding both the form definition object and the binding object could
>> be configured from annotations in the model bean. With some decent set
>> of conventions, people who follow the conventions would be able to
>> connect forms to the business model with considerably less code
>> writing. JBoss Seam is a good example of what I have in mind.
>>     
>
> I tend to agree with this one. I'm also supporter of less
> configuration-demanding solutions and conventions where applicable. I
> fear only if Java world (and we in particular) eventually leap from the
> "XML hell" to the "annotations hell". I can imagine this situation and
> would like to avoid it.
>
>   
>> AJAX+REST friendliness
>> ======================
>>
>> IMHO the preferred webapp architecture will move from MVC model 2
>> towards the kind of architecture described in figure 2 in
>> http://www-128.ibm.com/developerworks/websphere/library/techarticles/0606_barcia/0606_barcia.html
>>
>> and in http://websphere.sys-con.com/read/196269.htm.
>>
>> One way to support such a architectural style with our forms framework
>> would be to refactor it so that it allows for a more RESTish
>> communication style. Think about the form instance as a resource that
>> can have JSON (or XML) representation that you can GET, PUT, POST or
>> DELETE. One could also have support for letting the client ask for
>> tthe data types of the form for supporting client side validation.
>>     
>
> I wonder where are the limits. Is it valid to treat browser as VM
> machine where we execute complicated (name them Rich) client
> applications? Although such an idea is nice, when I think of "IE" all
> the simplicity and flexibility of the solution seems to flow away to
> some nowhere land. Am I only one not so enthusiastic about AJAX
> everywhere vision?
>   

The "IE gives me shudders" feeling is partly one of the reasons for Ajax
toolkits to exist. This unfortunately doesn't solve everything, but
helps a lot!

> Maybe I'm just ignorant but... is there any multi threading capability
> on browser side? Is it only me experiencing Firefox freezing while dojo
> toolkit is being loaded?
>   

No, JavaScript is not multi-threaded, and although there are discussions
IIRC to introduce it in JavaScript 2.0, we won't be able to rely on it
on our browsers for many years.

The freezing you experience is that because you're using an uncompressed
Dojo, and every dojo.require() potentially does a _synchronous_
XmlHttpRequest, hence freezing the browser. The solution, that has to be
used for any production deployment, is to use Dojo's compressor to group
all JS files used by an application into a single compressed one. No
more freezing in that case.

Sylvain

-- 
Sylvain Wallez - http://bluxte.net


Mime
View raw message