Hi Ed,
danke, in Wien geht's hervorragend ;)
you're right, of course. This has to be clearly documented. And
indeed, this problem is unsolvable. Manfred has invested a lot of work
into MyFaces trying to get this to run somehow by further minimizing
the state - but with the restrictions imposed by IE, this is clearly
undoable currently.
Still, the users obviously want something like this - me personally, I
don't care too much, I don't need it for my high-secure
banking-finance closed to the world applications ;)
And I do think they can live with the trade-off, here.
regards,
Martin
On 1/27/06, Ed Burns <[EMAIL PROTECTED]> wrote:
> Hallo Manolito,
>
> Wie geht es in Wien?
>
> >>>>> On Fri, 27 Jan 2006 16:06:26 +0100, Manfred Geiler <[EMAIL PROTECTED]>
> >>>>> said:
>
> MG> As Ed noted, saving everything into the GET request does not work
> MG> because of URL size limitations. Old stagers within the MyFaces
> MG> community might remember the so called "minimizing state" feature in
> MG> early MyFaces 0.x versions. The goal was to provide a JSF
> MG> implementation that works without JavaScript AND without Servlet
> MG> sessions.
> MG> Well, as you know, we gave up the idea of saving everything to the
> MG> URL. It's simply unsolvable AFAICT.
>
> MG> What Martin proposes is a rather simple solution that - of course -
> MG> breaks normal JSF lifecycle, but could be a good solution for the
> MG> ordinary webapp. Most bookmarkable pages are those that you can reach
> MG> via a navigation menu or alike. Not much state information needed in
> MG> most of these cases. What important information do we need when a user
> MG> comes back to a "menu linked" page via bookmark?
> MG> - the logged in user: we get him from the JASS authentication if we are
> lucky
> MG> - some kind of id (product id or things like that): it's part of the
> MG> URL if we use the bookmarkable feature of the t:safeState tag
> MG> - more?
>
> MG> This is no all-out-of-the-box solution, but I think it's worth playing
> MG> around a little bit with this solution.
>
> MG> +1 for Martins proposal - give it a shot
>
> Just make sure the limitations are well understood and clearly
> documented. I wouldn't want people thinking that MyFaces has a solution
> to an unsolvable (or at least really hard and inelegant) problem when
> really it doesn't :). This is a meritocracy after all!
>
> 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
