http://wiki.apache.org/jakarta-tapestry/Tapestry41Roadmap
I would take a look at the ajax sections outlined towards the bottom. This work is already currently underway. On 4/5/06, Sam Gendler <[EMAIL PROTECTED]> wrote: > > Ive been unable to sleep, of late, worrying about my ability to > deliver a cutting edge, ajax enabled application from within Tapestry. > I chose Tapestry as a framework before I had significant user > experience, but after being utterly dissatisfied with the maturity of > all other java component-based frameworks. However, the rewind cycle > thing started to make me nervous as soon as I began to understand it, > as a good ajax application really needs to be able to make requests > back to the server that are independant of the content or structure of > a page. > > I really like Tapestry's templates, which alow me to retain the > general structure of the raw html so I can work with designers easily, > and the support for internationalization is excellent, but the page > orientation of all client-server communication was making me nervous. > I believe, from some of the reading I've done, that the Tacos > components that make async requests actually cause a full rewind on > every request. More importantly, I couldn't imagine how I would > support doing things like adding new form elements from javascript. > > I think I came up with a solution last night, but I can't be the only > person thinking about this problem, so I thought I'd run it past folks > here before writing it up in full and starting work on it. AT the > very least, hopefully someone will clue me in on the correct way to > handle this if my solution has holes in it that I am unaware of. So > please, bring on the constructive criticism. Also, bear in mind that > I don't have a very deep understanding of Tapestry internals yet, and > my first task will be to delve under the hood and figure out how I > would actually proceed, so I may make the occasional factual error > below. > > > > There are a number of available tools for marshalling/unmarshalling > java objects to and from xml (or JSON or anything else. I'm fairly > agnostic on this one). The only issue is how to submit requests to the > server and get back results without having to be concerned with page > structure or doing lots of unnecessary work. > > The thought I had was to add a second servlet to my webapp, one which > functions in a tapestry-esque manner (injecting services and > properties, autopopulating properties based on request contents, use > Tapestry annotations, etc), but which is 'stateless.' The Service (as > opposed to a Page) would have properties populated according to some > known scheme (in previous projects, I've used jakarta BeanUtils > notation, ognl, Maps, and other tricks, and then a listener method > would be called. The listener would either return an object which > could be marshalled back as XML/JSON/text, or would write directly to > the client. Of course, it would be easy to provide custom marshalling > mechanisms for any given class that might be returned. All that would > be required would be javascript in the page which knows how to parse > the incoming data. > > Now, it is entirely possible that something like this could be built > within the confines of a Tapestry Page, perhaps by providing a new > Service, so my concept of a second servlet stems mostly from ignorance > of what is available to me, currently. > > Regardless of the implementation details, the resulting app would be > quite compelling, for me, and I suspect for others. We would get > Tapestry's excellent templates/internationalization/infrastructure but > all data i/o would occur via Services instead of Pages. When Page > changes are required, and for simple forms, Tapestry Pages would still > be very useful, but much of the business logic could migrate away from > the Page rendering logic. Obviously, you'd have to be careful of the > rewind cycle when dynamically adding new input fields to a page which > might get submitted, but even that can be handled by submitting the > new objects asynchronously and then re-requesting the page > asynchronously, getting the browser version and the tapestry state > back in sync. > > At any rate, in a full ajax app, it is unlikely that form data would > ever be submitted back via a regular post, so it is probably a moot > point for many, if not most 'Web 2.0' apps. There, I actually used the > term. Ugh. > > These are just brief ramblings, as I have to run out, and I wanted to > get my thoughts out there before I am away froma computer for most of > the day. > > So please, feel free to take my idea apart, as I am sure I'll learn > plenty in the process. In the end, so long as I can do ajax-y things > within Tapestry, I don't care how I get there. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://opennotion.com
