One of the points that Jesse makes is very important! We, as in the Tapestry "we", treat the browser as a way to render html. Occasionally, we throw in some JavaScript. However, we don't address the real client here which is the DOM and I think that is Jesse's point. If it isn't then it is mine.
Viewing the browser as the "client" side of a server application changes the whole view of what we are building. Web 2.0 and AJAX are starting to shift the emphasis away from only rendering HTML to downloading a client and data to the browser and having it interact with the Server. Right now they are very seperate. If the browser sends back something the rewind doesn't expect then bad things happen. That is because the state is stored on the server. What should be happening on a submit is for the DOM to create a data stream and update the server. For example if my shopping cart has two items and I "add" an item to the DOM, now there are three. Tapestry has a hissy fit because the rewind doesn't match. We are very tightly tied directly to the state of the server. What should happen is that the browser should submit an array of these and populate the server. What Jesse is doing with Tacos is a good start, but it can only be piecemeal until we seperate the state from the server. Is this making any sense? Can somebody explain this better than I am doing? regards, Mark -----Original Message----- From: Jesse Kuhnert [mailto:[EMAIL PROTECTED] Sent: Sun 2/26/2006 6:05 PM To: Tapestry development Subject: Re: [Discuss]long - Tapestry 5 stuff. It's like a framework christmas! The EventListener idea is incredibly cool. Mixing that in with ajax/json/flash/form logic and pretty soon the whole thing just starts working in incredible ways. I'm not trying to be all "gung ho" about every little thing I read, but this is really a critical step. No one has really addressed all the changing design patterns that are emerging and this one seems to do just that. I won't call it web 3.0 though. Just tapestry 5 ;) Seriously though, all of the core-ish people on the "exciting new web 2.0" ajax end of things have been hinting about how cool it will be when a framework really gets what they're doing /embraces it and provides a new development style for these things. Not just another wrapper around a few js libraries... That sounds like exactly what you're describing. The only actual "new" thing I can add to your thought pool would be addressing client state. I think a lot of work is going to go into 4.1 for this - but if you think of the client as just a pure gui with a remoted backend, that is also handicapped in that it doesn't really know how to render itself without the backend's help, you can get a better vision for what is more or less going on there. (ie a bunch of gui code running around , maintaing state of some of that info on the server/client and being very very smart about what gets updated when , even what happens before/during/after update...etc ) jesse On 2/26/06, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > Other ideas: > > Components will be able to emit events. Methods on your components > will have an @EventListener annotation that defines which components > and events they should be invoked for. So instead of defining > listeners via parameters (pushing the listener method into the > component), we just define the listeners and let Tapestry wire it up. > > I'm looking for more areas where Tapestry can 'do the right thing'. > > -- > Howard M. Lewis Ship > Independent J2EE / Open-Source Java Consultant > Creator, Jakarta Tapestry > Creator, Jakarta HiveMind > > Professional Tapestry training, mentoring, support > and project work. http://howardlewisship.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
