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/04/04 06:03:01 UTC
RESTful JSF
Now that the old discussion has settled, I'd like to relive it a little bit.
If you remember, we discussed that writing out parameters and managed
bean states could be done easily with adding an attribute to
commandLink (bookmarkable=true), and also add this attribute to
saveState (well, there have been other propositions as well, but this
is what generally seemed doable).
The discussion ran then wild on how we would reapply this state to the
component tree or the backing beans.
The biggest problem in this was security - we couldn't just reapply
the state without knowing if this state was even allowed to be
reapplied.
There have been two suggestions to solve this problem:
1) configure centrally in your faces-config.xml which state may be reapplied
2) client side encryption
the problem with client side encryption is that
a) the state on client-side might be quite ugly
b) you'll not be able to change the encryption key on the server
anymore, if you want your pages to remain bookmarkable
together with Thomas, we've discussed about a third solution:
3) create a new component, which takes the values out of the request,
and reapplies them either to another component, or the managed bean.
It could look much like the aliasBean today.
this component would get rid of the necessary configuration (in fact,
it might be much nicer to let a component in the page decide on which
will be reapplied or not of the request saved state), plus you'd have
inherent security: only the state that is explicitly configured will
be reapplied.
wdyt?
regards,
Martin
P.S.: In case there was such an approach in the original discussion
and I overlooked it, please excuse me and tell me so ;)
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: RESTful JSF
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> Why do we need a component to take values out of the request and
> apply them to a managed bean? JSF managed-beans can do this
> right now without putting anything in the component tree.
>
As the example shows, it allows us to attach converter and validators.
Not every property of a managed bean is a string or other primitive type.
And not every converter can be looked up from the faces-config.
At last using validators we can secure what CAN be set to the managed
property.
I think it makes no difference if the data were entered by the user or
comes in through get-requests.
It might look like overhead using the view for this, but it'll give us
the same flexibility as we have normally.
And it detaches the url parameter from the managed-bean. So you can
refactor your beans withouth breaking the url.
Ciao,
Mario
Re: RESTful JSF
Posted by Matthias Wessendorf <mw...@gmail.com>.
> people would build stronger, more powerful ones. I continue to
> be surprised that no one's doing that (Shale's dialogs being one
> of the sole exceptions).
Beehive and Spring-Web-Flow also contain their custom
NavigationHandler, since they are doing *similar* stuff like Shale's
dialog does.
-Matthias
Re: RESTful JSF
Posted by Adam Winer <aw...@gmail.com>.
OK, so what's wrong with developing a custom NavigationHandler
reading off of its own metadata outside of faces-config.xml (not just
playing outcome or to-view-id syntactical tricks)?
When we designed NavigationHandler in the spec, we very intentionally
built a bare-bones navigation system with the absolute intention that
people would build stronger, more powerful ones. I continue to
be surprised that no one's doing that (Shale's dialogs being one
of the sole exceptions).
-- Adam
On 4/6/06, Martin Marinschek <ma...@gmail.com> wrote:
> the navigation handler doesn't read in the configuration. Reading in
> the configuration is implementation specific, AFAIK.
>
> you could parse the faces-config.xml's twice, eventually.
>
> regards,
>
> Martin
>
> On 4/6/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> > Martin,
> > > John (I think) suggested to do it in the navigation rules of the
> > > faces-config.xml, but there it will be implementation specific, except
> > > you get it in the spec.
> > >
> > With some tricks we might get this in in an custom NavigationHandler, no?
> >
> > Ciao,
> > Mario
> >
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
Re: RESTful JSF
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi Martin!
> the navigation handler doesn't read in the configuration. Reading in
> the configuration is implementation specific, AFAIK.
>
since it works only with <redirect> only maybe this hack might do it:
public void handleNavigation(final FacesContext facesContext, String
fromAction, String outcome)
{
original.handleNavigation(new FacesContextWrapper(facesContext)
{
public ExternalContext getExternalContext()
{
return new
com.ops.OPSJ.jsflib.ExternalContextWrapper(super.getExternalContext())
{
public void redirect(String url) throws IOException
{
url = prepareRedirect(facesContext, url);
super.redirect(url);
}
};
}
}, fromAction, outcome);
}
Where prepareRedirect replaces the bean properties.
A hack - I know ;-)
Ciao,
Mario
Re: RESTful JSF
Posted by Martin Marinschek <ma...@gmail.com>.
the navigation handler doesn't read in the configuration. Reading in
the configuration is implementation specific, AFAIK.
you could parse the faces-config.xml's twice, eventually.
regards,
Martin
On 4/6/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> Martin,
> > John (I think) suggested to do it in the navigation rules of the
> > faces-config.xml, but there it will be implementation specific, except
> > you get it in the spec.
> >
> With some tricks we might get this in in an custom NavigationHandler, no?
>
> Ciao,
> Mario
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: RESTful JSF
Posted by Mario Ivankovits <ma...@ops.co.at>.
Martin,
> John (I think) suggested to do it in the navigation rules of the
> faces-config.xml, but there it will be implementation specific, except
> you get it in the spec.
>
With some tricks we might get this in in an custom NavigationHandler, no?
Ciao,
Mario
Re: RESTful JSF
Posted by Martin Marinschek <ma...@gmail.com>.
Well, I know I may not say this from a theoretical point of view.
Ok, I'll do it anyways. It's just too much fun.
I don't see the managed beans (except for creation) in the controller
layer, nor do I see them in the navigation handler layer. Guck, guck,
where are you?
If I try to fit them in, I have to bend my knees and stick something
up my a.. (yes, another configuration file, with a cool new format, is
that nice).
regards,
Martin
On 4/6/06, Adam Winer <aw...@gmail.com> wrote:
> On 4/6/06, Martin Marinschek <ma...@gmail.com> wrote:
> > Adam,
> >
> > we've been through the phase listener approach already. Was nice, but
> > with security it doesn't work out.
> >
> > How do you restrict what can be applied to the backing beans or the
> > components? It's just not possible, except you configure it somehow.
>
> Well, sure: you have to configure it! To do bookmarking right,
> you need new metadata that doesn't exist anywhere . You can
> either put that metadata in the view - where it doesn't fit well - or
> in the controller/NavigationHandler layer - where it fits naturally.
> That means a custom NavigationHandler with a new configuration
> file.
>
> -- Adam
>
>
> > John (I think) suggested to do it in the navigation rules of the
> > faces-config.xml, but there it will be implementation specific, except
> > you get it in the spec.
> >
> > So for now, the best solution will be to do the configuration in the
> > view itself.
> >
> > regards,
> >
> > Martin
> >
> > On 4/5/06, Adam Winer <aw...@gmail.com> wrote:
> > > Why do we need a component to take values out of the request and
> > > apply them to a managed bean? JSF managed-beans can do this
> > > right now without putting anything in the component tree.
> > >
> > > I don't think bookmarkability is something that should be
> > > approached from the perspective of the component tree - it
> > > should be tackled as an application-level concern - generate
> > > bookmarkable links via ViewHandler.createActionURL(), handle
> > > restoring state on the incoming requests via a PhaseListener.
> > >
> > > -- Adam
> > >
> > >
> > >
> > > On 4/5/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> > > > Hi!
> > > > > 3) create a new component, which takes the values out of the request,
> > > > > and reapplies them either to another component, or the managed bean.
> > > > > It could look much like the aliasBean today.
> > > > Ok, finally I think this is not that bad idea :-)
> > > >
> > > > It defines the possibilities within the view (which is my main
> > > > requirement) and thus makes it easily possible to use all the jsf
> > > > functionality.
> > > >
> > > > I propose to also have the possibility to attach converter/validators to it.
> > > > So the tag will be something like:
> > > >
> > > > <t:getParam name="urlParamName" value="#{managedBean.property}">
> > > > <f:convertNumber
> > > > minFractionDigits="2"
> > > > groupingUsed="true" />
> > > > <f:validateLength maximum="10" minimum="2"/>
> > > > </t:getParam>
> > > >
> > > >
> > > > May I also propose to put all those getParam into a container elemenent
> > > > - e.g. getParams
> > > > This might make it possible to do e.g.
> > > >
> > > > <t:getParams renderBookmarkLink="true">
> > > > <f:facet name="text">
> > > > <h:outputText value="link value" />
> > > > </f:facet>
> > > > <t:getParam name="urlParamName" value="#{managedBean.property}">
> > > > <f:convertNumber
> > > > minFractionDigits="2"
> > > > groupingUsed="true" />
> > > > <f:validateLength maximum="10" minimum="2"/>
> > > > </t:getParam>
> > > > </t:getParams>
> > > >
> > > > This will not only set the parameters to the property in case of a get
> > > > request, but will also generate a "bookmark me" link. Using javascript
> > > > only a single click will be required to add it to the favorites.
> > > >
> > > > For those not willing to use such links we can provide a way to add the
> > > > parameters to the url by using a special navigation entry.
> > > > Someone else on the ML mentioned it, but I dont know who it was - sorry.
> > > >
> > > > <navigation-rule>
> > > > <navigation-case>
> > > > <from-outcome>MyOutcome</from-outcome>
> > > >
> > > > <to-view-id>/Bookmarkable.jsp?param=#{managerBean.property}</to-view-id>
> > > > <redirect />
> > > > </navigation-case>
> > > > </navigation-rule>
> > > >
> > > > In this case it is not possible to add a special converter, though one
> > > > will be used if its possible to find one for the property-type.
> > > >
> > > > It will only work with <redirect/>, but I'll start fixing
> > > > http://issues.apache.org/jira/browse/MYFACES-516 then there should be a
> > > > problem with this.
> > > > I know, it will work without fixing MYFACES-516 as the page is
> > > > "bookmarkable", but I also think that such pages are able in dual mode,
> > > > means: with or without previously added request parameters. And we still
> > > > have to preserve stuff like messages, locales, etc.
> > > >
> > > > The real link generation should be routed through an interface to make
> > > > it possible to create links ala TinyURL, encryption and/or compression.
> > > >
> > > >
> > > > Looks like this will be a really nice solution.
> > > > Lets define who does what ;-)
> > > >
> > > > Ciao,
> > > > Mario
> > > >
> > > >
> > >
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: RESTful JSF
Posted by Jacob Hookom <ja...@hookom.net>.
Covered here a bit:
http://weblogs.java.net/blog/jhook/archive/2006/03/the_new_servlet_1.html
Mario Ivankovits wrote:
> Hi!
>
>> what would be the representation used for a date/long/double in a
>> string? Can we look into the xsd definition for that? Would an xsd
>> type representation converter be a good solution for this?
>>
>>
> No need to do anything special other then fixate the locale/encoding
> used (configureable through context-param) when encoding the values.
> The same way as it is if JSF converts a value to string and back.
>
> See if there is a converter attached/if not lookup by type/if not
> fallback to serialization ... sounds familiar, no? ;-)
>
> It already works, JSF converts to a date and back from user input. This
> is why I dont see any difference between user input and url paramter.
> We can fully rely on JSF default mechanism - and the user has the full,
> well known configuration possibillities.
>
> Ciao,
> Mario
>
>
>
--
--------------------------
Sent from my FrankenBerry Wireless Handheld
Re: RESTful JSF
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> what would be the representation used for a date/long/double in a
> string? Can we look into the xsd definition for that? Would an xsd
> type representation converter be a good solution for this?
>
No need to do anything special other then fixate the locale/encoding
used (configureable through context-param) when encoding the values.
The same way as it is if JSF converts a value to string and back.
See if there is a converter attached/if not lookup by type/if not
fallback to serialization ... sounds familiar, no? ;-)
It already works, JSF converts to a date and back from user input. This
is why I dont see any difference between user input and url paramter.
We can fully rely on JSF default mechanism - and the user has the full,
well known configuration possibillities.
Ciao,
Mario
Re: RESTful JSF
Posted by Martin Marinschek <ma...@gmail.com>.
Yes, it's actually a mixture of conversion and coercion which is
necessary. Hmm...
what would be the representation used for a date/long/double in a
string? Can we look into the xsd definition for that? Would an xsd
type representation converter be a good solution for this?
But custom converters should definitely be possible, whatever solution we find.
regards,
Martin
On 4/6/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi!
> > Well, you definitely need some validation. I'm not positive
> > that JSF converters are totally the right way to go, because (generally)
> > converters are Locale dependent and user-readable - whereas
> > URL parameters must be Locale independent.
> Thats a good point, but ...
>
> > EL coercion is
> > more along the lines of what's wanted here.
> >
> this might not be sufficient as a bean property might be a complex
> object (e.g. hibernate entity).
> You know, you can have e.g. a select box of complex objects (or enums)
> and the converter take care of it.
> This is something I'd do with bookmarkable links too.
>
> To workaround the locale problem we could define to render them always
> in local "en" and UTF-8 (to workaround the encoding problem :-) )
>
> > Certainly the view that's being pointed to by the URL is JSF content.
> >
> > Were you imagining a stub JSF component tree that simply processes
> > the bookmark (after validating), then forwards on to the real page?
> >
> I already thought about this. Yes, this will be possible, but optional.
> The user will not be forced to do so.
> If we define it as a requirement I am fine with it too as almost always
> a bookmark call require some special setup of internal data structures
> to startup the system again.
>
> Ciao,
> Mario
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: RESTful JSF
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> Well, you definitely need some validation. I'm not positive
> that JSF converters are totally the right way to go, because (generally)
> converters are Locale dependent and user-readable - whereas
> URL parameters must be Locale independent.
Thats a good point, but ...
> EL coercion is
> more along the lines of what's wanted here.
>
this might not be sufficient as a bean property might be a complex
object (e.g. hibernate entity).
You know, you can have e.g. a select box of complex objects (or enums)
and the converter take care of it.
This is something I'd do with bookmarkable links too.
To workaround the locale problem we could define to render them always
in local "en" and UTF-8 (to workaround the encoding problem :-) )
> Certainly the view that's being pointed to by the URL is JSF content.
>
> Were you imagining a stub JSF component tree that simply processes
> the bookmark (after validating), then forwards on to the real page?
>
I already thought about this. Yes, this will be possible, but optional.
The user will not be forced to do so.
If we define it as a requirement I am fine with it too as almost always
a bookmark call require some special setup of internal data structures
to startup the system again.
Ciao,
Mario
Re: RESTful JSF
Posted by Adam Winer <aw...@gmail.com>.
On 4/6/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi!
>
> Just to make sure we talk about the same.
> We have the place where we create a bookmarkable link - which can be the
> NavigationHandler - and we have the place where we have to process the
> incoming get parameters.
>
> > You can either put that metadata in the view - where it doesn't fit well - or
> > in the controller/NavigationHandler layer - where it fits naturally.
> >
> To the "Process" part:
>
> I dont understand whats the difference between user-input and url-input
> - but are from external and are subject to be wrong.
> Both should go through the whole validator/converter stuff in JSF.
Well, you definitely need some validation. I'm not positive
that JSF converters are totally the right way to go, because (generally)
converters are Locale dependent and user-readable - whereas
URL parameters must be Locale independent. EL coercion is
more along the lines of what's wanted here.
> We need a way to handle all this, so why not do it through the view. All
> what we need is in place there.
IMO, I think you want the code that generates the bookmark
URLs to be the same code that handles the bookmark URLs,
so you're not performing very similar configuration in two places.
> Else we have to create another jsp/facelete like configuration for this
> "mini-view".
> And then still we need the real view the bookmark url points to - JSF
> needs something to show.
Certainly the view that's being pointed to by the URL is JSF content.
Were you imagining a stub JSF component tree that simply processes
the bookmark (after validating), then forwards on to the real page?
That sounds better than mixing the bookmarking processing into the
view page, which has a whiff of old Model 1 development about it.
-- Adam
> > That means a custom NavigationHandler with a new configuration
> > file.
> >
>
> The "Create" part:
> To create a bookmarkable link we do not need much more than the propose
> in my post - somethink like toViewId=/view.jsp?param=#{...}
>
> Ciao,
> Mario
>
>
Re: RESTful JSF
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
Just to make sure we talk about the same.
We have the place where we create a bookmarkable link - which can be the
NavigationHandler - and we have the place where we have to process the
incoming get parameters.
> You can either put that metadata in the view - where it doesn't fit well - or
> in the controller/NavigationHandler layer - where it fits naturally.
>
To the "Process" part:
I dont understand whats the difference between user-input and url-input
- but are from external and are subject to be wrong.
Both should go through the whole validator/converter stuff in JSF.
We need a way to handle all this, so why not do it through the view. All
what we need is in place there.
Else we have to create another jsp/facelete like configuration for this
"mini-view".
And then still we need the real view the bookmark url points to - JSF
needs something to show.
> That means a custom NavigationHandler with a new configuration
> file.
>
The "Create" part:
To create a bookmarkable link we do not need much more than the propose
in my post - somethink like toViewId=/view.jsp?param=#{...}
Ciao,
Mario
Re: RESTful JSF
Posted by Adam Winer <aw...@gmail.com>.
On 4/6/06, Martin Marinschek <ma...@gmail.com> wrote:
> Adam,
>
> we've been through the phase listener approach already. Was nice, but
> with security it doesn't work out.
>
> How do you restrict what can be applied to the backing beans or the
> components? It's just not possible, except you configure it somehow.
Well, sure: you have to configure it! To do bookmarking right,
you need new metadata that doesn't exist anywhere . You can
either put that metadata in the view - where it doesn't fit well - or
in the controller/NavigationHandler layer - where it fits naturally.
That means a custom NavigationHandler with a new configuration
file.
-- Adam
> John (I think) suggested to do it in the navigation rules of the
> faces-config.xml, but there it will be implementation specific, except
> you get it in the spec.
>
> So for now, the best solution will be to do the configuration in the
> view itself.
>
> regards,
>
> Martin
>
> On 4/5/06, Adam Winer <aw...@gmail.com> wrote:
> > Why do we need a component to take values out of the request and
> > apply them to a managed bean? JSF managed-beans can do this
> > right now without putting anything in the component tree.
> >
> > I don't think bookmarkability is something that should be
> > approached from the perspective of the component tree - it
> > should be tackled as an application-level concern - generate
> > bookmarkable links via ViewHandler.createActionURL(), handle
> > restoring state on the incoming requests via a PhaseListener.
> >
> > -- Adam
> >
> >
> >
> > On 4/5/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> > > Hi!
> > > > 3) create a new component, which takes the values out of the request,
> > > > and reapplies them either to another component, or the managed bean.
> > > > It could look much like the aliasBean today.
> > > Ok, finally I think this is not that bad idea :-)
> > >
> > > It defines the possibilities within the view (which is my main
> > > requirement) and thus makes it easily possible to use all the jsf
> > > functionality.
> > >
> > > I propose to also have the possibility to attach converter/validators to it.
> > > So the tag will be something like:
> > >
> > > <t:getParam name="urlParamName" value="#{managedBean.property}">
> > > <f:convertNumber
> > > minFractionDigits="2"
> > > groupingUsed="true" />
> > > <f:validateLength maximum="10" minimum="2"/>
> > > </t:getParam>
> > >
> > >
> > > May I also propose to put all those getParam into a container elemenent
> > > - e.g. getParams
> > > This might make it possible to do e.g.
> > >
> > > <t:getParams renderBookmarkLink="true">
> > > <f:facet name="text">
> > > <h:outputText value="link value" />
> > > </f:facet>
> > > <t:getParam name="urlParamName" value="#{managedBean.property}">
> > > <f:convertNumber
> > > minFractionDigits="2"
> > > groupingUsed="true" />
> > > <f:validateLength maximum="10" minimum="2"/>
> > > </t:getParam>
> > > </t:getParams>
> > >
> > > This will not only set the parameters to the property in case of a get
> > > request, but will also generate a "bookmark me" link. Using javascript
> > > only a single click will be required to add it to the favorites.
> > >
> > > For those not willing to use such links we can provide a way to add the
> > > parameters to the url by using a special navigation entry.
> > > Someone else on the ML mentioned it, but I dont know who it was - sorry.
> > >
> > > <navigation-rule>
> > > <navigation-case>
> > > <from-outcome>MyOutcome</from-outcome>
> > >
> > > <to-view-id>/Bookmarkable.jsp?param=#{managerBean.property}</to-view-id>
> > > <redirect />
> > > </navigation-case>
> > > </navigation-rule>
> > >
> > > In this case it is not possible to add a special converter, though one
> > > will be used if its possible to find one for the property-type.
> > >
> > > It will only work with <redirect/>, but I'll start fixing
> > > http://issues.apache.org/jira/browse/MYFACES-516 then there should be a
> > > problem with this.
> > > I know, it will work without fixing MYFACES-516 as the page is
> > > "bookmarkable", but I also think that such pages are able in dual mode,
> > > means: with or without previously added request parameters. And we still
> > > have to preserve stuff like messages, locales, etc.
> > >
> > > The real link generation should be routed through an interface to make
> > > it possible to create links ala TinyURL, encryption and/or compression.
> > >
> > >
> > > Looks like this will be a really nice solution.
> > > Lets define who does what ;-)
> > >
> > > Ciao,
> > > Mario
> > >
> > >
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
Re: RESTful JSF
Posted by Martin Marinschek <ma...@gmail.com>.
Adam,
we've been through the phase listener approach already. Was nice, but
with security it doesn't work out.
How do you restrict what can be applied to the backing beans or the
components? It's just not possible, except you configure it somehow.
John (I think) suggested to do it in the navigation rules of the
faces-config.xml, but there it will be implementation specific, except
you get it in the spec.
So for now, the best solution will be to do the configuration in the
view itself.
regards,
Martin
On 4/5/06, Adam Winer <aw...@gmail.com> wrote:
> Why do we need a component to take values out of the request and
> apply them to a managed bean? JSF managed-beans can do this
> right now without putting anything in the component tree.
>
> I don't think bookmarkability is something that should be
> approached from the perspective of the component tree - it
> should be tackled as an application-level concern - generate
> bookmarkable links via ViewHandler.createActionURL(), handle
> restoring state on the incoming requests via a PhaseListener.
>
> -- Adam
>
>
>
> On 4/5/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> > Hi!
> > > 3) create a new component, which takes the values out of the request,
> > > and reapplies them either to another component, or the managed bean.
> > > It could look much like the aliasBean today.
> > Ok, finally I think this is not that bad idea :-)
> >
> > It defines the possibilities within the view (which is my main
> > requirement) and thus makes it easily possible to use all the jsf
> > functionality.
> >
> > I propose to also have the possibility to attach converter/validators to it.
> > So the tag will be something like:
> >
> > <t:getParam name="urlParamName" value="#{managedBean.property}">
> > <f:convertNumber
> > minFractionDigits="2"
> > groupingUsed="true" />
> > <f:validateLength maximum="10" minimum="2"/>
> > </t:getParam>
> >
> >
> > May I also propose to put all those getParam into a container elemenent
> > - e.g. getParams
> > This might make it possible to do e.g.
> >
> > <t:getParams renderBookmarkLink="true">
> > <f:facet name="text">
> > <h:outputText value="link value" />
> > </f:facet>
> > <t:getParam name="urlParamName" value="#{managedBean.property}">
> > <f:convertNumber
> > minFractionDigits="2"
> > groupingUsed="true" />
> > <f:validateLength maximum="10" minimum="2"/>
> > </t:getParam>
> > </t:getParams>
> >
> > This will not only set the parameters to the property in case of a get
> > request, but will also generate a "bookmark me" link. Using javascript
> > only a single click will be required to add it to the favorites.
> >
> > For those not willing to use such links we can provide a way to add the
> > parameters to the url by using a special navigation entry.
> > Someone else on the ML mentioned it, but I dont know who it was - sorry.
> >
> > <navigation-rule>
> > <navigation-case>
> > <from-outcome>MyOutcome</from-outcome>
> >
> > <to-view-id>/Bookmarkable.jsp?param=#{managerBean.property}</to-view-id>
> > <redirect />
> > </navigation-case>
> > </navigation-rule>
> >
> > In this case it is not possible to add a special converter, though one
> > will be used if its possible to find one for the property-type.
> >
> > It will only work with <redirect/>, but I'll start fixing
> > http://issues.apache.org/jira/browse/MYFACES-516 then there should be a
> > problem with this.
> > I know, it will work without fixing MYFACES-516 as the page is
> > "bookmarkable", but I also think that such pages are able in dual mode,
> > means: with or without previously added request parameters. And we still
> > have to preserve stuff like messages, locales, etc.
> >
> > The real link generation should be routed through an interface to make
> > it possible to create links ala TinyURL, encryption and/or compression.
> >
> >
> > Looks like this will be a really nice solution.
> > Lets define who does what ;-)
> >
> > Ciao,
> > Mario
> >
> >
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: RESTful JSF
Posted by Adam Winer <aw...@gmail.com>.
Why do we need a component to take values out of the request and
apply them to a managed bean? JSF managed-beans can do this
right now without putting anything in the component tree.
I don't think bookmarkability is something that should be
approached from the perspective of the component tree - it
should be tackled as an application-level concern - generate
bookmarkable links via ViewHandler.createActionURL(), handle
restoring state on the incoming requests via a PhaseListener.
-- Adam
On 4/5/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi!
> > 3) create a new component, which takes the values out of the request,
> > and reapplies them either to another component, or the managed bean.
> > It could look much like the aliasBean today.
> Ok, finally I think this is not that bad idea :-)
>
> It defines the possibilities within the view (which is my main
> requirement) and thus makes it easily possible to use all the jsf
> functionality.
>
> I propose to also have the possibility to attach converter/validators to it.
> So the tag will be something like:
>
> <t:getParam name="urlParamName" value="#{managedBean.property}">
> <f:convertNumber
> minFractionDigits="2"
> groupingUsed="true" />
> <f:validateLength maximum="10" minimum="2"/>
> </t:getParam>
>
>
> May I also propose to put all those getParam into a container elemenent
> - e.g. getParams
> This might make it possible to do e.g.
>
> <t:getParams renderBookmarkLink="true">
> <f:facet name="text">
> <h:outputText value="link value" />
> </f:facet>
> <t:getParam name="urlParamName" value="#{managedBean.property}">
> <f:convertNumber
> minFractionDigits="2"
> groupingUsed="true" />
> <f:validateLength maximum="10" minimum="2"/>
> </t:getParam>
> </t:getParams>
>
> This will not only set the parameters to the property in case of a get
> request, but will also generate a "bookmark me" link. Using javascript
> only a single click will be required to add it to the favorites.
>
> For those not willing to use such links we can provide a way to add the
> parameters to the url by using a special navigation entry.
> Someone else on the ML mentioned it, but I dont know who it was - sorry.
>
> <navigation-rule>
> <navigation-case>
> <from-outcome>MyOutcome</from-outcome>
>
> <to-view-id>/Bookmarkable.jsp?param=#{managerBean.property}</to-view-id>
> <redirect />
> </navigation-case>
> </navigation-rule>
>
> In this case it is not possible to add a special converter, though one
> will be used if its possible to find one for the property-type.
>
> It will only work with <redirect/>, but I'll start fixing
> http://issues.apache.org/jira/browse/MYFACES-516 then there should be a
> problem with this.
> I know, it will work without fixing MYFACES-516 as the page is
> "bookmarkable", but I also think that such pages are able in dual mode,
> means: with or without previously added request parameters. And we still
> have to preserve stuff like messages, locales, etc.
>
> The real link generation should be routed through an interface to make
> it possible to create links ala TinyURL, encryption and/or compression.
>
>
> Looks like this will be a really nice solution.
> Lets define who does what ;-)
>
> Ciao,
> Mario
>
>
Re: RESTful JSF
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> 3) create a new component, which takes the values out of the request,
> and reapplies them either to another component, or the managed bean.
> It could look much like the aliasBean today.
Ok, finally I think this is not that bad idea :-)
It defines the possibilities within the view (which is my main
requirement) and thus makes it easily possible to use all the jsf
functionality.
I propose to also have the possibility to attach converter/validators to it.
So the tag will be something like:
<t:getParam name="urlParamName" value="#{managedBean.property}">
<f:convertNumber
minFractionDigits="2"
groupingUsed="true" />
<f:validateLength maximum="10" minimum="2"/>
</t:getParam>
May I also propose to put all those getParam into a container elemenent
- e.g. getParams
This might make it possible to do e.g.
<t:getParams renderBookmarkLink="true">
<f:facet name="text">
<h:outputText value="link value" />
</f:facet>
<t:getParam name="urlParamName" value="#{managedBean.property}">
<f:convertNumber
minFractionDigits="2"
groupingUsed="true" />
<f:validateLength maximum="10" minimum="2"/>
</t:getParam>
</t:getParams>
This will not only set the parameters to the property in case of a get
request, but will also generate a "bookmark me" link. Using javascript
only a single click will be required to add it to the favorites.
For those not willing to use such links we can provide a way to add the
parameters to the url by using a special navigation entry.
Someone else on the ML mentioned it, but I dont know who it was - sorry.
<navigation-rule>
<navigation-case>
<from-outcome>MyOutcome</from-outcome>
<to-view-id>/Bookmarkable.jsp?param=#{managerBean.property}</to-view-id>
<redirect />
</navigation-case>
</navigation-rule>
In this case it is not possible to add a special converter, though one
will be used if its possible to find one for the property-type.
It will only work with <redirect/>, but I'll start fixing
http://issues.apache.org/jira/browse/MYFACES-516 then there should be a
problem with this.
I know, it will work without fixing MYFACES-516 as the page is
"bookmarkable", but I also think that such pages are able in dual mode,
means: with or without previously added request parameters. And we still
have to preserve stuff like messages, locales, etc.
The real link generation should be routed through an interface to make
it possible to create links ala TinyURL, encryption and/or compression.
Looks like this will be a really nice solution.
Lets define who does what ;-)
Ciao,
Mario