Hi John,
ok - so you agree with me that the renderer has to take care of that?
Cause I still don't get that getURL stuff from the navigation-handler
- It would be great if you could elaborate on that.
as for saving parameters, I see three approaches cristalizing out now:
1) configure in the
As for the security of proposal
2)
if we do client-side state-saving, we do encryption, right? Would we
have to do encryption here, too, to make this more secure?
Would that run against the notion of readable, nice bookmarks? Probably yes...
regards,
Martin
On 1/30/06, Martin Marinschek
Maybe I'm missing something, but I don't understand why state saving and bookmarking are related.Isn't a bookmark something you would potentially paste into an email and send to your friend? There doesn't seem to be any assosicated state present in the URL or on the server, so why do we need
Considering the huge number of responses in this thread, this is
obviously a big problem. While there were good suggestions on how to
improve the situation, with all of them, we are only making (better)
alternatives to the broken base functionality. And yes, some say it's
not really broken because
Well, for your suggestion, no state saving is necessary, right.
you'll only have use-data transferred via the wire to the client, so
that's somewhat ok.
In proposal 2 (see above) the use-data _and_ the structure is
transferred to the client, so by changing the structure, the (hacking)
user can
Yeah, Kalle, you're absolutely right. I was thinking about that too -
if you have a fixed action-parameter or add a defaultAction
parameter to a link, you can already render the new view-id instead of
the old one.
But: you'll have to make sure that the postback somehow includes the
information on
Thanks Adam! ;-)
I've been thinking about this a bit more recently.
One of the JSF's strengths is it's clean separation between
agent-specific details in the renderers, and it's more general
component and event model abstraction that can easily be leveraged by
application developers.
In the case
If you want to go minimal/stateless with JSF, it's somewhat do-able. I was
able to take a sandbox of Facelets and simply:
1) Always write an empty hidden input param for 'javax.faces.ViewState' to get
the succeeding request to expect a Restored View
2) Within ViewHandler.restoreView(..) call
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,
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
Hi Jacob,
yes, but I'm talking about being able to pass _some_ state here. So
you don't go fully stateless, you have the ability to reduce the state
to a size where it is usable with GET-Requests.
And I want to use MyFaces t:saveState feature for providing this
ability. Together with an error to
Yeah, that's correct, who says ViewState actually has to be your component
model? :-)
I've thought about progressing the stateless JSF solution to instead just write
Seam's converstation ID as the ViewState (a numeric long) to match up to model
state. This kind of solution makes a lot more
From: Martin Marinschek [EMAIL PROTECTED] Hi Jacob, yes, but I'm talking about being able to pass _some_ state here. So you don't go fully stateless, you have the ability to reduce the state to a size where it is usable with GET-Requests.
I agreewith youMartin. Why not burn\generate a
Hi Jacob,
Seam's state-saving method is server-side, right? The conversation
will be stored on the server? Is that a persistent storage - in the
sense of a database, or a volatile storage - in the sense of a server
session (ok, I know, server side sessions can be persisted, too;) ?
option 1) So
My idea's always been something like an optional
NavigationHandler interface:
public interface BookmarkableNavigationHandler
{
/**
* Return an URL if the MethodExpression can be handled purely
* as a GET request, or null if it cannot be done.
*/
public String getUrl(FacesContext,
BTW, a credit-where-it's-due: I should be clear that my idea's
always been... completely omits that this idea is very much
due to John Fallows!
-- Adam
On 1/27/06, Adam Winer [EMAIL PROTECTED] wrote:
My idea's always been something like an optional
NavigationHandler interface:
public
16 matches
Mail list logo
