I dont think ajax is a compromise .. Not for the kind of webframe work we are.. We are a serverside framework. just like struts/jsf/tapestry. I guess you compare it with full client side frameworks (gwt or echo2) yes those are ajax through and through (they have to) But that doesn't mean that i call ours a compromise, we just do or use it differently.
Back button in ajax (so an ajax request triggers a change that then should be a backbutton change?) "Everything" on the serverside is ready for that.. Somebody just need to write the javascript/behavior.. But nobody seems to really want to have that... bookmarkability in full ajax frameworks? I guess the have support for that but then you have to code that in. And we also have that thats called BookmarkableLinks.. asynchronous server handling we also have ofcourse, what we dont have is multply request at the same time.. thats just our single threaded model...(can by bypassed with resources but...) Maybe we can relax that a bit in a next version where we can say "this ajax request/behavior doesnt lock" Some kind of tagging interface for an ajax behavior.. But then it is really up to the user to be very carefull and we as a framework also have to really look into our own page handling code :( Hybrid approach? Make a (statefull) page with stateless links that have parameters... I call that hybrid.. The page can live and will be reused, if not and you click on that stateless link a new page is created and the link has its state. So thats already doable. Only the encoding of the params is maybe a bit cumbersome. johan On Nov 15, 2007 10:18 PM, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > * Ajax support is a compromise. We can't really help this, and I feel > we did/ are doing the best we can, but our Ajax support suffers from > the fact that we're trying to support both a traditional (page based) > and ajax approach. Particularly, back button support, bookmarkability > and asynchronous server handling suffers. Some of this might still be > improved in future versions, but I think we're already easily one of > the most complex web frameworks out there when it comes to the > internals, and these fixes are only gonna make things more difficult. > > * No Hybrid approach to state handling. I know many team members > disagree here, but I've always had in my mind that the perfect > approach to state handling would be to give users the choice between > server managed and client managed (i.e. by passing parameters/ rest) > on a component level. To our defense, none of our competitors support > this either, at least not on the component level I am envisioning. > >
