OK, I like what I saw there, but I have some questions. 1. Your implementation still relies on explicitly stating which components will be updated by a particular request. What happens in the case of a component that was generated iteratively in a loop or table which needs to be updated?
2. What kind of timeframe are we talking about to get these changes built. I'm happy to join the development effort, and even task other members of my team to it, but I clearly have a lot to learn about tapestry internals. I could follow most of what you were writing about, but only just. I'll come up to speed quickly once I'm into it, but if you think this will be months, I need to pursue a faster solution myself. 3. Since I can involve 2 or 3 engineers in developing this (including myself, and I generally work as much as 2 or 3 people), would you be willing and able to act as something of a project manager and architect in order to make sure we do it right. If I thought that putting 3 engineers on this full time could get us solid working code in 2 or 3 weeks, I'd do it without a second thought, but we'd need your guidance to get it done. I don't know how much time you spend on tapestry development and what kind of prirority it is for you. I don't know that I could pay you for labor, but I could guarantee that all our work would go back to the tapestry community. My goal is to build out a framework, preferably something that can be part of Tapestry itself, such that it becomes as easy to build ajax components as it is to build static ones today. Clearly, that wasn't the case with Tacos, from your description of the hoops you had to jump through. But I've got a pretty sophisticated ui that I need to deliver by late July, so if I am not done with the infrastructural aspects and on to component and ui development within a month, I won't make it. Given that we are targeting a 'thick client' approach, moving data around but not interface elements, I am pretty sure I could get my second servlet hack working inside a month. It is less clear to me, mostly due to lack of knowledge, that we could implement your tapestry41 roadmap concepts in the same timeframe. But with your assurance that you think it is possible, I am willing to give it a shot. I'd much rather do work that benefits the community as a whole. --sam 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
