I should say something further as the last email may have sounded a little grumpy.
I definitely welcome any/all discussions / help with this stuff. No matter what form it may be in. The only thing I ask is that everyone does their homework first before coming to the table for discussions. On 4/5/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > > 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 > -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://opennotion.com
