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 Fri, 27 Jan 2006 17:17:13 GMT
>How do you explain the user that he's using actions all over the
>application, and then for his GET needs, he has to provide an url with
>parameters and other stuff?

I don't think it's confusing at all.  If anything, I would suggest something like Craig has
been bringing up where the requested URI *is* an action, nothing parameter based (as suggested
by exadel).  In any case, you would still be in the same boat of having alternate methods
of invoking actions which is extremely confusing.

>From a front controller aspect (which is what you are describing), 90% of people's needs
are handled by filters or global error policies.  Its a niche case where you would want to
display a completely different view based on action invocation within the front controller
in a GET request.  Again, a user can sit there and hit refresh and keep on invoking that GET
request, maybe in a draconic sense, JSF is preventing users from doing things they shouldn't
be.

In my mind, a bookmarkable link should just be /user.jsf?id=433, let login and error filters
handle assertions over the URI outside of JSF's action controller.  If you need to execute
some behavior, such as a fetch, then use JSF 1.2's phase listeners that are attachable to
the UIViewRoot.

-- Jacob



>
>Well,
>
>I think you have to distinct clearly here. The concept of "actions"
>which lead to somewhere else is a somewhat widely used concept in
>web-applications. If you don't call dynamic method-bindings, but you
>have static action-references, I don't think that you can lump
>together calling actions and saving state.
>
>I don't see why we force on our users to learn actions first - and
>then don't allow them to use these actions for doing get-requests as
>well. That ought to be possible, really.
>How do you explain the user that he's using actions all over the
>application, and then for his GET needs, he has to provide an url with
>parameters and other stuff?
>
>How does solving this issue break POST vs. GET?
>
>We are making it clear to the user that something differently happens
>here if he uses a bookmarkable link.
>
>regards,
>
>Martin
>
>
>On 1/27/06, jacob@hookom.net <jacob@hookom.net> wrote:
>> I don't think the problem should be solved.
>>
>> No one says that all of your commandLinks need to invoke actions-- you can 
>render normal links.  With invoking actions, you posting transitional 
>behavior, with gets, there is not transitional behavior to retain.  When you 
>want to bookmark things, that designates the URI as repeatable, which is a far 
>separation from the intentions of JSF's action/stateful capabilities.
>>
>> Nothing is stopping someone from using JSF to render a table that prints out 
>normal links like: <a href="/person.jsf?id=533">Click</a> and use RESTful

>principles for actually rendering that page based on Ed's/EG's 1) ManagedBean 
>Create/Destroy annotations and 2) Attaching listeners to the UIViewRoot
>>
>> I (personally) think this issue shouldn't be solved since it breaks POST vs. 
>GET and would assert transitional behavior where it shouldn't be.
>>
>> -- Jacob
>>
>> >
>> >Gruß Gott,
>> >
>> >>>>>> On Fri, 27 Jan 2006 10:43:23 +0100, Werner Punz <werpu@gmx.at>
said:
>> >
>> >WP> +1000 for a get....
>> >WP> Martin Marinschek schrieb:
>> >
>> >MM> I'm having ideas again. Must come from too much work with JSF ;)
>> >MM>
>> >MM> My idea:
>> >MM>
>> >MM> Bookmarking is a problem with JSF, right? Except you use h:outputLink,
>> >MM> but then there's this slight problem with not being in the action
>> >MM> system anymore ;)
>> >MM>
>> >MM> Now, what do I want to be able to see in my history or to bookmark? I
>> >MM> want to bookmark simple pages, where state is not so important at all.
>> >MM> Or only a small portion of the state is important...
>> >MM>
>> >MM> Those simple pages I usually refer to with an "action" attribute that
>> >MM> is put (as a string) directly on the <h:commandLink /> or
>> >MM> <h:commandButton/> tag, right?
>> >MM>
>> >MM> Why not render out this action attribute as a parameter to the URL of
>> >MM> the link optionally, not submitting a form and loosing all JSF state,
>> >MM> but having a bookmarkable link?
>> >MM>
>> >MM> The developer can decide then:
>> >MM> - do I need this link to be bookmarked
>> >MM> - do I want this link to  use the plain old JSF posting system with
>> >MM> state-saving.
>> >
>> >Right, I've thought about this problem for the Sun impl, and we even
>> >have an issue on our issue tracker for it:
>> >
>> >https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=72
>> >
>> >MM> Enhancement: we could additionally render out params to this link as -
>> >MM> yes, right, params to the URL. So people can optionally build there
>> >MM> web-apps just like they were used to when JSF wasn't around.
>> >
>> >MM> Good idea - bad idea - better idea ;) ?
>> >
>> >But I can't see how to do it in a general way while supporting both
>> >client and server side state saving modes.  This is due, of course,
>> >to the restriction on size of the GET request.
>> >
>> >Another problem, when using the server side mode, is what to do when the
>> >session expires.
>> >
>> >Any solution that doesn't deal with these cases is a less than full
>> >solution.
>> >
>> >I was thinking of decorating the state manager to somehow write out
>> >bookmarked pages to the filesystem so they can survive session
>> >expiration, but then, what do you do about failover?
>> >
>> >Ed
>> >
>> >--
>> >| ed.burns@sun.com  | {home: 407 869 9587, office: 408 884 9519 OR x31640}
>> >| homepage:         | http://purl.oclc.org/NET/edburns/
>> >| aim: edburns0sunw | iim: ed.burns@sun.com
>> >
>>
>
>
>--
>
>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