myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ja...@hookom.net
Subject Re: Bookmarking, History and JSF
Date Sun, 29 Jan 2006 19:14:29 GMT
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 <mario@ops.co.at> 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

Mime
View raw message