You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Martin Marinschek <ma...@gmail.com> on 2006/01/27 10:34:48 UTC
Bookmarking, History and JSF
Hi all,
I'm having ideas again. Must come from too much work with JSF ;)
My idea:
Bookmarking is a problem with JSF, right? Except you use h:outputLink,
but then there's this slight problem with not being in the action
system anymore ;)
Now, what do I want to be able to see in my history or to bookmark? I
want to bookmark simple pages, where state is not so important at all.
Or only a small portion of the state is important...
Those simple pages I usually refer to with an "action" attribute that
is put (as a string) directly on the <h:commandLink /> or
<h:commandButton/> tag, right?
Why not render out this action attribute as a parameter to the URL of
the link optionally, not submitting a form and loosing all JSF state,
but having a bookmarkable link?
The developer can decide then:
- do I need this link to be bookmarked
- do I want this link to use the plain old JSF posting system with
state-saving.
Enhancement: we could additionally render out params to this link as -
yes, right, params to the URL. So people can optionally build there
web-apps just like they were used to when JSF wasn't around.
Good idea - bad idea - better idea ;) ?
regards,
Martin
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: Bookmarking, History and JSF
Posted by Matthias Wessendorf <mw...@gmail.com>.
Here goes the link for that servlet
http://tinyurl.com/8dv43
inside of invokeApplication() you could do some stuff w/ ValueBindings
to populate your bean.
-Matthias
On 1/27/06, Matthias Wessendorf <mw...@gmail.com> wrote:
> Hi
>
> > Now, what do I want to be able to see in my history or to bookmark? I
> > want to bookmark simple pages, where state is not so important at all.
> > Or only a small portion of the state is important...
>
> > Those simple pages I usually refer to with an "action" attribute that
> > is put (as a string) directly on the <h:commandLink /> or
> > <h:commandButton/> tag, right?
>
> right, since no *complicated* calculation for action outcome is needed.
>
> > Why not render out this action attribute as a parameter to the URL of
> > the link optionally, not submitting a form and loosing all JSF state,
> > but having a bookmarkable link?
>
> a feature like this makes it more easier to implement systems like ebay,
> where bookmarkable URLs are a must!
>
> >
> > The developer can decide then:
> > - do I need this link to be bookmarked
> > - do I want this link to use the plain old JSF posting system with
> > state-saving.
>
> ok
>
> >
> > Enhancement: we could additionally render out params to this link as -
> > yes, right, params to the URL. So people can optionally build there
> > web-apps just like they were used to when JSF wasn't around.
>
> so something like
>
> host/app/foo.faces?param1=foo¶m2=bar
>
> >
> > Good idea - bad idea - better idea ;) ?
>
> Why not rendering a link to a NonFacesRequestServlet ?
> (like the tobago stuff)
>
> For links like
> foo.faces?param1=foo¶m2=bar
>
> your backing bean construktor (or init() of ViewController) needs to
> perform some lookups.
> That could be easily done by that mentioned servlet, without doing
> that parameter catching stuff inside of your backing bean.
>
> @Manfred: I guess I saw a ticket in RI stuff for this. What's the EGs
> plan for enabling bookmarkable URLs ?
>
> -Matthias
>
> > regards,
> >
> > Martin
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
>
>
> --
> Matthias Wessendorf
> Zülpicher Wall 12, 239
> 50674 Köln
> http://www.wessendorf.net
> mwessendorf-at-gmail-dot-com
>
--
Matthias Wessendorf
Zülpicher Wall 12, 239
50674 Köln
http://www.wessendorf.net
mwessendorf-at-gmail-dot-com
Re: Bookmarking, History and JSF
Posted by Martin Marinschek <ma...@gmail.com>.
Hi Werner,
You're absolutely right. My "could" actually meant we must ;)
What we <could/> do though would be to automatically fail-over to
normal state-saving and rendering, if the state grows too large. So we
have an error, right, but the app doesn't stop working. The page just
isn't bookmarkable anymore.
regards,
Martin
On 1/27/06, Werner Punz <we...@gmx.at> wrote:
> Martin Marinschek schrieb:
> > We could optionally do that - don't know if that is practical.
> >
> > I've discussed with Manfred some more, and he suggests to do the following:
> >
> > give t:saveState an optional "bookmarkable"=true attribute, and with
> > that decide on some of the state to be saved even though the
> > tree-state is lost.
> >
> > we could also log an error to the user when the maximum url-size is exceeded.
> >
>
> That error is definitely mandatory to avoid constant posts in the users
> list why data gets lost ;-)
> No in fact the size limitation is one of the reasons post usually is
> preferred for form handling, such an error would help alot in a get
> situation to track down problems.
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: Bookmarking, History and JSF
Posted by Werner Punz <we...@gmx.at>.
Martin Marinschek schrieb:
> We could optionally do that - don't know if that is practical.
>
> I've discussed with Manfred some more, and he suggests to do the following:
>
> give t:saveState an optional "bookmarkable"=true attribute, and with
> that decide on some of the state to be saved even though the
> tree-state is lost.
>
> we could also log an error to the user when the maximum url-size is exceeded.
>
That error is definitely mandatory to avoid constant posts in the users
list why data gets lost ;-)
No in fact the size limitation is one of the reasons post usually is
preferred for form handling, such an error would help alot in a get
situation to track down problems.
Re: Bookmarking, History and JSF
Posted by Martin Marinschek <ma...@gmail.com>.
We could optionally do that - don't know if that is practical.
I've discussed with Manfred some more, and he suggests to do the following:
give t:saveState an optional "bookmarkable"=true attribute, and with
that decide on some of the state to be saved even though the
tree-state is lost.
we could also log an error to the user when the maximum url-size is exceeded.
regards,
Martin
On 1/27/06, Werner Punz <we...@gmx.at> wrote:
> Matthias Wessendorf schrieb:
>
> >
> > Why not rendering a link to a NonFacesRequestServlet ?
> > (like the tobago stuff)
> >
> Servlet = bad idea needs an additional entry in the web.xml
> (and just check how many problems the tomahawk extension filter
> already causes)
> The obvious place probably would be the extension filter (which has to
> be there anyway)
> or a phase listener - which would be even better because that one
> would not need any entry at all from the users side if packed correctly.
>
>
> > For links like
> > foo.faces?param1=foo¶m2=bar
> >
> > your backing bean construktor (or init() of ViewController) needs to
> > perform some lookups.
> > That could be easily done by that mentioned servlet, without doing
> > that parameter catching stuff inside of your backing bean.
> >
> > @Manfred: I guess I saw a ticket in RI stuff for this. What's the EGs
> > plan for enabling bookmarkable URLs ?
> >
> > -Matthias
> >
> >> regards,
> >>
> >> Martin
> >>
> >> --
> >>
> >> http://www.irian.at
> >>
> >> Your JSF powerhouse -
> >> JSF Consulting, Development and
> >> Courses in English and German
> >>
> >> Professional Support for Apache MyFaces
> >>
> >
> >
> > --
> > Matthias Wessendorf
> > Zülpicher Wall 12, 239
> > 50674 Köln
> > http://www.wessendorf.net
> > mwessendorf-at-gmail-dot-com
> >
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: Bookmarking, History and JSF
Posted by Matthias Wessendorf <mw...@gmail.com>.
> Servlet = bad idea needs an additional entry in the web.xml
> (and just check how many problems the tomahawk extension filter
> already causes)
> The obvious place probably would be the extension filter (which has to
> be there anyway)
> or a phase listener - which would be even better because that one
> would not need any entry at all from the users side if packed correctly.
yeah! right. so, instead of servlet let's take a PhaseListener. But we
definitly need (or should provide) a facility to populate your backing
beans, instead of doing parameter catching inside of that bean.
that was my message :-)
-Matthias
Re: Bookmarking, History and JSF
Posted by Werner Punz <we...@gmx.at>.
Matthias Wessendorf schrieb:
>
> Why not rendering a link to a NonFacesRequestServlet ?
> (like the tobago stuff)
>
Servlet = bad idea needs an additional entry in the web.xml
(and just check how many problems the tomahawk extension filter
already causes)
The obvious place probably would be the extension filter (which has to
be there anyway)
or a phase listener - which would be even better because that one
would not need any entry at all from the users side if packed correctly.
> For links like
> foo.faces?param1=foo¶m2=bar
>
> your backing bean construktor (or init() of ViewController) needs to
> perform some lookups.
> That could be easily done by that mentioned servlet, without doing
> that parameter catching stuff inside of your backing bean.
>
> @Manfred: I guess I saw a ticket in RI stuff for this. What's the EGs
> plan for enabling bookmarkable URLs ?
>
> -Matthias
>
>> regards,
>>
>> Martin
>>
>> --
>>
>> http://www.irian.at
>>
>> Your JSF powerhouse -
>> JSF Consulting, Development and
>> Courses in English and German
>>
>> Professional Support for Apache MyFaces
>>
>
>
> --
> Matthias Wessendorf
> Zülpicher Wall 12, 239
> 50674 Köln
> http://www.wessendorf.net
> mwessendorf-at-gmail-dot-com
>
Re: Bookmarking, History and JSF
Posted by Matthias Wessendorf <mw...@gmail.com>.
Hi
> Now, what do I want to be able to see in my history or to bookmark? I
> want to bookmark simple pages, where state is not so important at all.
> Or only a small portion of the state is important...
> Those simple pages I usually refer to with an "action" attribute that
> is put (as a string) directly on the <h:commandLink /> or
> <h:commandButton/> tag, right?
right, since no *complicated* calculation for action outcome is needed.
> Why not render out this action attribute as a parameter to the URL of
> the link optionally, not submitting a form and loosing all JSF state,
> but having a bookmarkable link?
a feature like this makes it more easier to implement systems like ebay,
where bookmarkable URLs are a must!
>
> The developer can decide then:
> - do I need this link to be bookmarked
> - do I want this link to use the plain old JSF posting system with
> state-saving.
ok
>
> Enhancement: we could additionally render out params to this link as -
> yes, right, params to the URL. So people can optionally build there
> web-apps just like they were used to when JSF wasn't around.
so something like
host/app/foo.faces?param1=foo¶m2=bar
>
> Good idea - bad idea - better idea ;) ?
Why not rendering a link to a NonFacesRequestServlet ?
(like the tobago stuff)
For links like
foo.faces?param1=foo¶m2=bar
your backing bean construktor (or init() of ViewController) needs to
perform some lookups.
That could be easily done by that mentioned servlet, without doing
that parameter catching stuff inside of your backing bean.
@Manfred: I guess I saw a ticket in RI stuff for this. What's the EGs
plan for enabling bookmarkable URLs ?
-Matthias
> regards,
>
> Martin
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
--
Matthias Wessendorf
Zülpicher Wall 12, 239
50674 Köln
http://www.wessendorf.net
mwessendorf-at-gmail-dot-com
Re: Bookmarking, History and JSF
Posted by Martin Marinschek <ma...@gmail.com>.
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 <ed...@sun.com> wrote:
> Hallo Manolito,
>
> Wie geht es in Wien?
>
> >>>>> On Fri, 27 Jan 2006 16:06:26 +0100, Manfred Geiler <ma...@gmail.com> 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
>
> --
> | 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
Re: Bookmarking, History and JSF
Posted by Ed Burns <ed...@sun.com>.
Hallo Manolito,
Wie geht es in Wien?
>>>>> On Fri, 27 Jan 2006 16:06:26 +0100, Manfred Geiler <ma...@gmail.com> 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
--
| 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
Re: Bookmarking, History and JSF
Posted by Manfred Geiler <ma...@gmail.com>.
As Ed noted, saving everything into the GET request does not work
because of URL size limitations. Old stagers within the MyFaces
community might remember the so called "minimizing state" feature in
early MyFaces 0.x versions. The goal was to provide a JSF
implementation that works without JavaScript AND without Servlet
sessions.
Well, as you know, we gave up the idea of saving everything to the
URL. It's simply unsolvable AFAICT.
What Martin proposes is a rather simple solution that - of course -
breaks normal JSF lifecycle, but could be a good solution for the
ordinary webapp. Most bookmarkable pages are those that you can reach
via a navigation menu or alike. Not much state information needed in
most of these cases. What important information do we need when a user
comes back to a "menu linked" page via bookmark?
- the logged in user: we get him from the JASS authentication if we are lucky
- some kind of id (product id or things like that): it's part of the
URL if we use the bookmarkable feature of the t:safeState tag
- more?
This is no all-out-of-the-box solution, but I think it's worth playing
around a little bit with this solution.
+1 for Martins proposal - give it a shot
Manfred
2006/1/27, Ed Burns <ed...@sun.com>:
> Gruß Gott,
>
> >>>>> On Fri, 27 Jan 2006 10:43:23 +0100, Werner Punz <we...@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
>
>
Re: Bookmarking, History and JSF
Posted by Ed Burns <ed...@sun.com>.
Gruß Gott,
>>>>> On Fri, 27 Jan 2006 10:43:23 +0100, Werner Punz <we...@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
Re: Bookmarking, History and JSF
Posted by Werner Punz <we...@gmx.at>.
+1000 for a get....
Martin Marinschek schrieb:
> Hi all,
>
> I'm having ideas again. Must come from too much work with JSF ;)
>
> My idea:
>
> Bookmarking is a problem with JSF, right? Except you use h:outputLink,
> but then there's this slight problem with not being in the action
> system anymore ;)
>
> Now, what do I want to be able to see in my history or to bookmark? I
> want to bookmark simple pages, where state is not so important at all.
> Or only a small portion of the state is important...
>
> Those simple pages I usually refer to with an "action" attribute that
> is put (as a string) directly on the <h:commandLink /> or
> <h:commandButton/> tag, right?
>
> Why not render out this action attribute as a parameter to the URL of
> the link optionally, not submitting a form and loosing all JSF state,
> but having a bookmarkable link?
>
> The developer can decide then:
> - do I need this link to be bookmarked
> - do I want this link to use the plain old JSF posting system with
> state-saving.
>
> Enhancement: we could additionally render out params to this link as -
> yes, right, params to the URL. So people can optionally build there
> web-apps just like they were used to when JSF wasn't around.
>
> Good idea - bad idea - better idea ;) ?
>
> regards,
>
> Martin
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>