What Mario is suggesting is the foundation for my stateless JSF solution. It doesn't make sense to duplicate the cabilities of a component framework and jam it into a struts/webwork solution-- around validation, parameter handling, and action invocation.
Your JSF document, with all of its components, is the tip of the iceberg of lots of functionality and behavior. Going back to the Avatar blogs, the importance of identity carries a very light-weight, agnostic way of transferring state to component handler on succeeding gets or posts via AJAX or normal submit. There's absolutely no need to re-invent the wheel here. -- Jacob > >Ok, I see... > >hmm, we'll have to think about that. > >regards, > >Martin > >On 1/29/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote: >> Hi! >> > I don't get it - you usually don't save stuff like id's in the >> > component tree, so how would it help you to apply an id to an item in >> > the component tree? >> > >> No id? >> I talked about the same id (client-id) you use to pass the request POST >> parameters into the view. >> >> So I don't talk about anything new to do, just to process the GET >> request the same way as you do with POST. And maybe do something special >> for the action, but I guess even this isn't needed. >> >> This allows you to render a commandLink with the new javascript=false >> and get a bookmarkable page. As always - the user has to ensure enough >> information will be passed to the view so it can recreate its internal >> state - even if the request created a new session. >> >> --- >> Mario >> >> > > >-- > >http://www.irian.at > >Your JSF powerhouse - >JSF Consulting, Development and >Courses in English and German > >Professional Support for Apache MyFaces
