>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, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> >> >>>>>> 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 >> > >> >-- >> >| [EMAIL PROTECTED] | {home: 407 869 9587, office: 408 884 9519 OR x31640} >> >| homepage: | http://purl.oclc.org/NET/edburns/ >> >| aim: edburns0sunw | iim: [EMAIL PROTECTED] >> > >> > > >-- > >http://www.irian.at > >Your JSF powerhouse - >JSF Consulting, Development and >Courses in English and German > >Professional Support for Apache MyFaces
