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]

Reply via email to