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
