Re: What to do when form depends on querystring params?

[benjamin van der veen <bv...@gmail.com>]

Andrew,

Very informative message. Thanks a lot. I'm still a bit troubled by
the fact that JSF didn't have this built in. It seems like such an
integral piece of a web framework that is used to accomplish a wide
range of tasks, so much so that it seems to me that the spec writers
couldn't have simply forgotten it, and it makes me wonder if the tasks
I would accomplish with it were accounted for somewhere else in the
specification. Could you give me an example of what you use the onload
method for? I know what I would do with it, but I'd just like to see
what you have to say without trying to take into account what I write.

Thanks,
benjamin van der veen

On 4/30/06, Andrew Robinson <an...@gmail.com> wrote:
> If you find any issues with the onload with jsf-comp please let me
> know (I am the author). I am using it at home and at work without
> issues except for JBoss-Seam EJB interceptors. Seam depends on the
> action method unfortunately.
>
> I looked fairly closely at the spec before writing the onload and made
> sure that the code I wrote conforms to what you are allowed to do. It
> behaves similarly to an action that decides to forward/include a
> non-JSF page. It uses the correct redirection and ensures the faces
> response is marked complete. So in these respects, it should not
> interfere with the specification at all. The only issue (like Seam) is
> when code may not expect action methods to be executed outside of the
> execute action JSF phase.
>
> I couldn't believe it either, before I wrote it, that JSF was missing
> such a huge piece of functionality. All other languages (PHP, Perl,
> ASP, ASP.NET, JSP) allow you to perform code when loading a page so I
> don't know why it wouldn't be in JSF.
>
> As a side note, Shale has something similar with the page controller.
> What I didn't like about it was that it had "void" as the return type
> and therefore you could not as easily interact with the navigation
> handling. The other problem I had with the JSF spec in these regards
> was the lack of externalized functionality in the NavigationHandler
> interface. I would love to get the view for a result without actually
> navigating there, or be able to extend the navigation handler and be
> able to modify the view after the method is fired but before the new
> view is created.
>
> -Andrew
>
> On 4/30/06, benjamin van der veen <bv...@gmail.com> wrote:
> > Xie Min,
> >
> > This is a great find, very close to what I'm talking about. However,
> > in the following line:
> >
> > <to-view-id>/view.jsp?objectId=#{view.objectId}</to-view-id>
> >
> > what object does 'view' in the EL expression reference? Is this an
> > implicit object, or one defined in a configuration somewhere? If it is
> > implicit, how do I set it's properties from a backing bean?
> >
> > Thanks a lot,
> > benjamin
> >
> >
> > On 4/29/06, xie min <xi...@gmail.com> wrote:
> > >
> > >
> > > in myfaces
> > > wiki(http://wiki.apache.org/myfaces/Custom_Navigation_Handler),
> > > threr are some suggestion on url parameters passing:
> > >
> > > Dynamic Url parameters passing: This allows passing parameters between pages
> > > even when using redirection method. For exmaple, in order to navigate from a
> > > pages name: view.jsp to a page named: edit.jsp, with the parameter:
> > > objectId, the following thing can be done in navigation rule code:
> > > <navigation-rule>
> > >  <from-view-id>/view.jsp</from-view-id>
> > >  <navigation-case>
> > >  <from-outcome>edit</from-outcome>
> > > <to-view-id>/view.jsp?objectId=#{view.objectId}</to-view-id>
> > >  <redirect />
> > >  </navigation-case>
> > >  </navigation-rule>
> > >
> > >
> > >
> > >
> > > 2006/4/30, benjamin van der veen <bv...@gmail.com>:
> > > > I think that jsf-comp onload thing might be what I'm looking for. I
> > > > really surprised that something like this isn't built in to JSF. Is
> > > > using this extension violating some design principle fundamental to
> > > > JSF?
> > > >
> > > > benjamin
> > > >
> > > > On 4/28/06, Andrew Robinson <an...@gmail.com> wrote:
> > > > > Have a look at:
> > > > >
> > > > >
> > > http://wiki.apache.org/myfaces/InvokingJsfPagesWithStandardUrls
> > > > >
> > > http://jsf-comp.sourceforge.net/components/onload/index.html
> > > > >
> > > > > -Andrew
> > > > >
> > > > > On 4/28/06, benjamin van der veen <bv...@gmail.com> wrote:
> > > > > > Hello,
> > > > > >
> > > > > > I sent the message quoted below to this list a few days ago, but
> > > > > > received no replies. I'm just wondering if perhaps it just got
> > > > > > overlooked; I would appreciate any insight on this issue.
> > > > > >
> > > > > > Thanks a lot,
> > > > > > benjamin
> > > > > >
> > > > > > On 4/26/06, benjamin van der veen <bv...@gmail.com> wrote:
> > > > > > > Hello,
> > > > > > >
> > > > > > > I'm coming from a PHP background, and I've run into a wall with JSF.
> > > I
> > > > > > > know how I'd get around it with PHP or ASP.NET, but for JSF I'm
> > > > > > > stumped.
> > > > > > >
> > > > > > > Here's the scenario:
> > > > > > >
> > > > > > > I'm making a message board. It has multiple forum each of which has
> > > > > > > many topics, each of which has many posts. Very standard thing here.
> > > I
> > > > > > > am implementing the page which allows a user to create a new topic.
> > > > > > > The URI is of the form "createTopic.jsf?forumId=<n>" where <n> is an
> > > > > > > integer corresponding to the forum's primary key in the database. I
> > > > > > > have a backing bean mapped in faces-config to "CreateTopicBean", and
> > > > > > > it is request scoped. Now, when the user submits the form to create
> > > a
> > > > > > > topic, what is the best way to let the bean know which forum this
> > > > > > > topic should be created under? I tried having a managed property
> > > like
> > > > > > > this:
> > > > > > >
> > > > > > > <managed-bean>
> > > > > > >
> > > <managed-bean-name>CreateTopicBean</managed-bean-name>
> > > > > > >         <managed-bean-class>
> > > > > > >
> > > com.wepwnsnails.faces.managedbean.CreateTopicBean
> > > > > > >         </managed-bean-class>
> > > > > > >
> > > <managed-bean-scope>request</managed-bean-scope>
> > > > > > >         <managed-property>
> > > > > > >
> > > <property-name>forumId</property-name>
> > > > > > >                 <value>#{param.forumId}</value>
> > > > > > >         </managed-property>
> > > > > > > </managed-bean>
> > > > > > >
> > > > > > > but when the "action" attribute of the html <form> element rendered
> > > by
> > > > > > > JSF is simply "createTopic.jsf", so an EL exception is thrown when
> > > JSF
> > > > > > > fails to set the managed property.
> > > > > > >
> > > > > > > I've also tried adding a <h:inputHidden> tag set to the forumId on
> > > the
> > > > > > > backing bean in a variety of ways, but they leave much to be desired
> > > > > > > as far as cleanliness.
> > > > > > >
> > > > > > > I'm sure that this is an issue every newbie JSF developer has
> > > > > > > scratched his head over; so what's the best way to go about this?
> > > I've
> > > > > > > had a hard time finding anything in Google, mostly because I don't
> > > > > > > know how to tersely phrase the problem for a seach query.
> > > > > > >
> > > > > > > Thanks a lot,
> > > > > > > benjamin van der veen
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> >
>

Re: What to do when form depends on querystring params?

[Andrew Robinson <an...@gmail.com>]

Dang thought of another point right after I sent. The other reason I
made on-load like the way I did is to be able to execute *any* action
method on load and not tie the code to one bean or one interface.
Since it uses EL, it is very flexible in allowing any bean's action
method to handle the load of any page. Basically keeping in the design
of JSF and decoupling business code from the UI layer.

On 5/1/06, Andrew Robinson <an...@gmail.com> wrote:
> The main reason I support redirecting on-load is due to load failures.
> So, if the user hits a page that displays data from a web service, and
> the web method call fails because the server is not running, it can
> return "webservicecallfailed" or something which would trigger a
> navigation to a "/errorPage.xhtml" for example.
>
> If the method handles the navigation in each method, there would be
> similar code repeated throughout the application, which I am not a big
> fan of.
>
> I don't see it as a use for a 2nd level of navigation as it would
> produce unnecessary overhead. The on-load component is also much more
> simple to integrate and use and I put it out there for people who
> didn't want to incorporate large frameworks into their JSF
> application, but only wanted this small sub set of functionality.
>
> With all that said, I really don't mind people using Shale instead and
> many or most may choose to do so, I just wanted to provide another
> solution that may be preferred by some people.
>
> -Andrew
>
> On 5/1/06, Craig McClanahan <cr...@apache.org> wrote:
> >
> >
> >
> > On 5/1/06, Andrew Robinson <an...@gmail.com> wrote:
> > > As I mentioned, I didn't want to use Shale as it doesn't not have the
> > > built-in ability to redirect from the methods (prerender for example),
> > > at least not when I last looked.
> >
> >
> > That (ability to redirect from *within* these event handling methods) is not
> > built in, but it is possible to do manually.  On the other hand, that also
> > goes against the design patterns these methods are there to support -- the
> > assumption is that someone, somewhere, already decided to navigate to this
> > page, and did so either with a redirect or a forward, via either a GET or a
> > POST.  The prerender() method is all about what happens *next*, not how we
> > got to this point.
> >
> > Think of prerender() as "set up the dynamic data I need to render the
> > current page", not as "decide whether to display this page or go elsewhere".
> >  That should have been done already in your application's action method (for
> > a POST), or via the hyperink or bookmark that got you here (for a GET).
> >
> > I'd be interested in exploring how your use cases might be different from
> > the one ViewController is targeted at ... but perhaps that's a subject for
> > the Struts list, since it is about the implementation of a Shale feature,
> > rather than purely about JSF.
> >
> > > I was also afraid of
> > > incompatibilities between Shale and JBoss-Seam.
> >
> >
> > That shouldn't be a concern-- they will work together fine (although you'll
> > probably be using Seam's notion of conversations rather than Shale Dialogs
> > if you are using the combination).
> >
> > > -Andrew
> >
> >
> > Craig
> >
> > > On 5/1/06, Craig McClanahan < craigmcc@apache.org> wrote:
> > > >
> > > >
> > > >
> > > > On 5/1/06, Andrew Robinson <andrew.rw.robinson@gmail.com > wrote:
> > > > > I agree, I have not given up in trying to find a "built in" way of
> > > > > doing it in JSF, but still have not found a way. The problem is that
> > > > > JSF is all about actions when execution Java code. The problem is that
> > > > > actions are never run on the first time a page is hit, only on POST
> > > > > back. I guess it is simply a major gap when decoupling the business
> > > > > code from the UI.
> > > >
> > > >
> > > > This kind of issue was a key motivation for the ViewController
> > functionality
> > > > in Shale[1].  In particular, the prerender() method is a good place to
> > deal
> > > > with this kind of issue, because it:
> > > >
> > > > * Is called on both GET and POST requests.
> > > >
> > > > * Is called *before* rendering takes place, so you can
> > > >   effect the response (include error messages, etc.)
> > > >
> > > > * Allows you to set up resources that are required for
> > > >   rendering (allocate a JDBC connection, open a Hibernate
> > > >   session, whatever) that is required for rendering, then
> > > >   clean up after rendering in the destroy() method.
> > > >
> > > > You can do this kind of thing yourself with a phase listener, but you're
> > > > going to end up basically replicating what Shale already provides.
> > > >
> > > > Craig
> > > >
> > > > [1] http://struts.apache.org/struts-shale/
> > > >
> > > >
> > > >
> > > > > I use the on-load component mostly for bookmarks. Say, somone
> > > > > bookmarks "edit.jsf", I use the on-load component to redirect them
> > > > > back to "index.jsf" if there is no property to edit (the backing bean
> > > > > is not in an editing state).
> > > > >
> > > > > The other thing I use it for is to load data that may fail. Say
> > > > > hitting a web service for example. In a getter method, the response is
> > > > > probably already committed and therefore too late to redirect the user
> > > > > or forward to a new page. Also, it is hard to add FacesMessages in a
> > > > > getter as the message(s) component(s) may have already been rendered,
> > > > > and once again it would be too late. The on-load allows me to
> > > > > gracefully handle errors in backing-bean methods during the loading of
> > > > > a new page.
> > > > >
> > > > > If there is a better way that you find or a way I can improve it, let
> > > > > me know. I would have much preferred to see this in the specification
> > > > > than have to make a one-off open source component.
> > > > >
> > > > > -Andrew
> > > > >
> > > > > On 4/30/06, benjamin van der veen <bv...@gmail.com> wrote:
> > > > > > Andrew,
> > > > > >
> > > > > > Very informative message. Thanks a lot. I'm still a bit troubled by
> > > > > > the fact that JSF didn't have this built in. It seems like such an
> > > > > > integral piece of a web framework that is used to accomplish a wide
> > > > > > range of tasks, so much so that it seems to me that the spec writers
> > > > > > couldn't have simply forgotten it, and it makes me wonder if the
> > tasks
> > > > > > I would accomplish with it were accounted for somewhere else in the
> > > > > > specification. Could you give me an example of what you use the
> > onload
> > > > > > method for? I know what I would do with it, but I'd just like to see
> > > > > > what you have to say without trying to take into account what I
> > write.
> > > > > >
> > > > > > Thanks,
> > > > > > benjamin van der veen
> > > > > >
> > > > > > On 4/30/06, Andrew Robinson <andrew.rw.robinson@gmail.com > wrote:
> > > > > > > If you find any issues with the onload with jsf-comp please let me
> > > > > > > know (I am the author). I am using it at home and at work without
> > > > > > > issues except for JBoss-Seam EJB interceptors. Seam depends on the
> > > > > > > action method unfortunately.
> > > > > > >
> > > > > > > I looked fairly closely at the spec before writing the onload and
> > made
> > > > > > > sure that the code I wrote conforms to what you are allowed to do.
> > It
> > > > > > > behaves similarly to an action that decides to forward/include a
> > > > > > > non-JSF page. It uses the correct redirection and ensures the
> > faces
> > > > > > > response is marked complete. So in these respects, it should not
> > > > > > > interfere with the specification at all. The only issue (like
> > Seam) is
> > > > > > > when code may not expect action methods to be executed outside of
> > the
> > > > > > > execute action JSF phase.
> > > > > > >
> > > > > > > I couldn't believe it either, before I wrote it, that JSF was
> > missing
> > > > > > > such a huge piece of functionality. All other languages (PHP,
> > Perl,
> > > > > > > ASP, ASP.NET, JSP) allow you to perform code when loading a page
> > so I
> > > > > > > don't know why it wouldn't be in JSF.
> > > > > > >
> > > > > > > As a side note, Shale has something similar with the page
> > controller.
> > > > > > > What I didn't like about it was that it had "void" as the return
> > type
> > > > > > > and therefore you could not as easily interact with the navigation
> > > > > > > handling. The other problem I had with the JSF spec in these
> > regards
> > > > > > > was the lack of externalized functionality in the
> > NavigationHandler
> > > > > > > interface. I would love to get the view for a result without
> > actually
> > > > > > > navigating there, or be able to extend the navigation handler and
> > be
> > > > > > > able to modify the view after the method is fired but before the
> > new
> > > > > > > view is created.
> > > > > > >
> > > > > > > -Andrew
> > > > > > >
> > > > > > > On 4/30/06, benjamin van der veen < bvanderveen@gmail.com> wrote:
> > > > > > > > Xie Min,
> > > > > > > >
> > > > > > > > This is a great find, very close to what I'm talking about.
> > However,
> > > > > > > > in the following line:
> > > > > > > >
> > > > > > > >
> > > >
> > <to-view-id>/view.jsp?objectId=#{view.objectId}</to-view-id>
> > > > > > > >
> > > > > > > > what object does 'view' in the EL expression reference? Is this
> > an
> > > > > > > > implicit object, or one defined in a configuration somewhere? If
> > it
> > > > is
> > > > > > > > implicit, how do I set it's properties from a backing bean?
> > > > > > > >
> > > > > > > > Thanks a lot,
> > > > > > > > benjamin
> > > > > > > >
> > > > > > > >
> > > > > > > > On 4/29/06, xie min < xiemin0914@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > in myfaces
> > > > > > > > > wiki(
> > > >
> > http://wiki.apache.org/myfaces/Custom_Navigation_Handler),
> > > > > > > > > threr are some suggestion on url parameters passing:
> > > > > > > > >
> > > > > > > > > Dynamic Url parameters passing: This allows passing parameters
> > > > between pages
> > > > > > > > > even when using redirection method. For exmaple, in order to
> > > > navigate from a
> > > > > > > > > pages name: view.jsp to a page named: edit.jsp, with the
> > > > parameter:
> > > > > > > > > objectId, the following thing can be done in navigation rule
> > code:
> > > > > > > > > <navigation-rule>
> > > > > > > > >  <from-view-id>/view.jsp</from-view-id>
> > > > > > > > >  <navigation-case>
> > > > > > > > >  <from-outcome>edit</from-outcome>
> > > > > > > > >
> > > > <to-view-id>/view.jsp?objectId=#{view.objectId
> > }</to-view-id>
> > > > > > > > >  <redirect />
> > > > > > > > >  </navigation-case>
> > > > > > > > >  </navigation-rule>
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > 2006/4/30, benjamin van der veen < bvanderveen@gmail.com >:
> > > > > > > > > > I think that jsf-comp onload thing might be what I'm looking
> > > > for. I
> > > > > > > > > > really surprised that something like this isn't built in to
> > JSF.
> > > > Is
> > > > > > > > > > using this extension violating some design principle
> > fundamental
> > > > to
> > > > > > > > > > JSF?
> > > > > > > > > >
> > > > > > > > > > benjamin
> > > > > > > > > >
> > > > > > > > > > On 4/28/06, Andrew Robinson < andrew.rw.robinson@gmail.com>
> > > > wrote:
> > > > > > > > > > > Have a look at:
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > >
> > http://wiki.apache.org/myfaces/InvokingJsfPagesWithStandardUrls
> > > > > > > > > > >
> > > > > > > > >
> > > >
> > http://jsf-comp.sourceforge.net/components/onload/index.html
> > > > > > > > > > >
> > > > > > > > > > > -Andrew
> > > > > > > > > > >
> > > > > > > > > > > On 4/28/06, benjamin van der veen < bvanderveen@gmail.com>
> > > > wrote:
> > > > > > > > > > > > Hello,
> > > > > > > > > > > >
> > > > > > > > > > > > I sent the message quoted below to this list a few days
> > ago,
> > > > but
> > > > > > > > > > > > received no replies. I'm just wondering if perhaps it
> > just
> > > > got
> > > > > > > > > > > > overlooked; I would appreciate any insight on this
> > issue.
> > > > > > > > > > > >
> > > > > > > > > > > > Thanks a lot,
> > > > > > > > > > > > benjamin
> > > > > > > > > > > >
> > > > > > > > > > > > On 4/26/06, benjamin van der veen <
> > bvanderveen@gmail.com>
> > > > wrote:
> > > > > > > > > > > > > Hello,
> > > > > > > > > > > > >
> > > > > > > > > > > > > I'm coming from a PHP background, and I've run into a
> > wall
> > > > with JSF.
> > > > > > > > > I
> > > > > > > > > > > > > know how I'd get around it with PHP or ASP.NET, but
> > for
> > > > JSF I'm
> > > > > > > > > > > > > stumped.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Here's the scenario:
> > > > > > > > > > > > >
> > > > > > > > > > > > > I'm making a message board. It has multiple forum each
> > of
> > > > which has
> > > > > > > > > > > > > many topics, each of which has many posts. Very
> > standard
> > > > thing here.
> > > > > > > > > I
> > > > > > > > > > > > > am implementing the page which allows a user to create
> > a
> > > > new topic.
> > > > > > > > > > > > > The URI is of the form "createTopic.jsf?forumId=<n>"
> > where
> > > > <n> is an
> > > > > > > > > > > > > integer corresponding to the forum's primary key in
> > the
> > > > database. I
> > > > > > > > > > > > > have a backing bean mapped in faces-config to
> > > > "CreateTopicBean", and
> > > > > > > > > > > > > it is request scoped. Now, when the user submits the
> > form
> > > > to create
> > > > > > > > > a
> > > > > > > > > > > > > topic, what is the best way to let the bean know which
> > > > forum this
> > > > > > > > > > > > > topic should be created under? I tried having a
> > managed
> > > > property
> > > > > > > > > like
> > > > > > > > > > > > > this:
> > > > > > > > > > > > >
> > > > > > > > > > > > > <managed-bean>
> > > > > > > > > > > > >
> > > > > > > > >
> > > > <managed-bean-name>CreateTopicBean</managed-bean-name>
> > > > > > > > > > > > >         <managed-bean-class>
> > > > > > > > > > > > >
> > > > > > > > >
> > com.wepwnsnails.faces.managedbean.CreateTopicBean
> > > > > > > > > > > > >         </managed-bean-class>
> > > > > > > > > > > > >
> > > > > > > > >
> > <managed-bean-scope>request</managed-bean-scope>
> > > > > > > > > > > > >         <managed-property>
> > > > > > > > > > > > >
> > > > > > > > > <property-name>forumId</property-name>
> > > > > > > > > > > > >                 <value>#{ param.forumId}</value>
> > > > > > > > > > > > >         </managed-property>
> > > > > > > > > > > > > </managed-bean>
> > > > > > > > > > > > >
> > > > > > > > > > > > > but when the "action" attribute of the html <form>
> > element
> > > > rendered
> > > > > > > > > by
> > > > > > > > > > > > > JSF is simply " createTopic.jsf", so an EL exception
> > is
> > > > thrown when
> > > > > > > > > JSF
> > > > > > > > > > > > > fails to set the managed property.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I've also tried adding a <h:inputHidden> tag set to
> > the
> > > > forumId on
> > > > > > > > > the
> > > > > > > > > > > > > backing bean in a variety of ways, but they leave much
> > to
> > > > be desired
> > > > > > > > > > > > > as far as cleanliness.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I'm sure that this is an issue every newbie JSF
> > developer
> > > > has
> > > > > > > > > > > > > scratched his head over; so what's the best way to go
> > > > about this?
> > > > > > > > > I've
> > > > > > > > > > > > > had a hard time finding anything in Google, mostly
> > because
> > > > I don't
> > > > > > > > > > > > > know how to tersely phrase the problem for a seach
> > query.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Thanks a lot,
> > > > > > > > > > > > > benjamin van der veen
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> >
> >
>

Re: What to do when form depends on querystring params?

[Andrew Robinson <an...@gmail.com>]

The main reason I support redirecting on-load is due to load failures.
So, if the user hits a page that displays data from a web service, and
the web method call fails because the server is not running, it can
return "webservicecallfailed" or something which would trigger a
navigation to a "/errorPage.xhtml" for example.

If the method handles the navigation in each method, there would be
similar code repeated throughout the application, which I am not a big
fan of.

I don't see it as a use for a 2nd level of navigation as it would
produce unnecessary overhead. The on-load component is also much more
simple to integrate and use and I put it out there for people who
didn't want to incorporate large frameworks into their JSF
application, but only wanted this small sub set of functionality.

With all that said, I really don't mind people using Shale instead and
many or most may choose to do so, I just wanted to provide another
solution that may be preferred by some people.

-Andrew

On 5/1/06, Craig McClanahan <cr...@apache.org> wrote:
>
>
>
> On 5/1/06, Andrew Robinson <an...@gmail.com> wrote:
> > As I mentioned, I didn't want to use Shale as it doesn't not have the
> > built-in ability to redirect from the methods (prerender for example),
> > at least not when I last looked.
>
>
> That (ability to redirect from *within* these event handling methods) is not
> built in, but it is possible to do manually.  On the other hand, that also
> goes against the design patterns these methods are there to support -- the
> assumption is that someone, somewhere, already decided to navigate to this
> page, and did so either with a redirect or a forward, via either a GET or a
> POST.  The prerender() method is all about what happens *next*, not how we
> got to this point.
>
> Think of prerender() as "set up the dynamic data I need to render the
> current page", not as "decide whether to display this page or go elsewhere".
>  That should have been done already in your application's action method (for
> a POST), or via the hyperink or bookmark that got you here (for a GET).
>
> I'd be interested in exploring how your use cases might be different from
> the one ViewController is targeted at ... but perhaps that's a subject for
> the Struts list, since it is about the implementation of a Shale feature,
> rather than purely about JSF.
>
> > I was also afraid of
> > incompatibilities between Shale and JBoss-Seam.
>
>
> That shouldn't be a concern-- they will work together fine (although you'll
> probably be using Seam's notion of conversations rather than Shale Dialogs
> if you are using the combination).
>
> > -Andrew
>
>
> Craig
>
> > On 5/1/06, Craig McClanahan < craigmcc@apache.org> wrote:
> > >
> > >
> > >
> > > On 5/1/06, Andrew Robinson <andrew.rw.robinson@gmail.com > wrote:
> > > > I agree, I have not given up in trying to find a "built in" way of
> > > > doing it in JSF, but still have not found a way. The problem is that
> > > > JSF is all about actions when execution Java code. The problem is that
> > > > actions are never run on the first time a page is hit, only on POST
> > > > back. I guess it is simply a major gap when decoupling the business
> > > > code from the UI.
> > >
> > >
> > > This kind of issue was a key motivation for the ViewController
> functionality
> > > in Shale[1].  In particular, the prerender() method is a good place to
> deal
> > > with this kind of issue, because it:
> > >
> > > * Is called on both GET and POST requests.
> > >
> > > * Is called *before* rendering takes place, so you can
> > >   effect the response (include error messages, etc.)
> > >
> > > * Allows you to set up resources that are required for
> > >   rendering (allocate a JDBC connection, open a Hibernate
> > >   session, whatever) that is required for rendering, then
> > >   clean up after rendering in the destroy() method.
> > >
> > > You can do this kind of thing yourself with a phase listener, but you're
> > > going to end up basically replicating what Shale already provides.
> > >
> > > Craig
> > >
> > > [1] http://struts.apache.org/struts-shale/
> > >
> > >
> > >
> > > > I use the on-load component mostly for bookmarks. Say, somone
> > > > bookmarks "edit.jsf", I use the on-load component to redirect them
> > > > back to "index.jsf" if there is no property to edit (the backing bean
> > > > is not in an editing state).
> > > >
> > > > The other thing I use it for is to load data that may fail. Say
> > > > hitting a web service for example. In a getter method, the response is
> > > > probably already committed and therefore too late to redirect the user
> > > > or forward to a new page. Also, it is hard to add FacesMessages in a
> > > > getter as the message(s) component(s) may have already been rendered,
> > > > and once again it would be too late. The on-load allows me to
> > > > gracefully handle errors in backing-bean methods during the loading of
> > > > a new page.
> > > >
> > > > If there is a better way that you find or a way I can improve it, let
> > > > me know. I would have much preferred to see this in the specification
> > > > than have to make a one-off open source component.
> > > >
> > > > -Andrew
> > > >
> > > > On 4/30/06, benjamin van der veen <bv...@gmail.com> wrote:
> > > > > Andrew,
> > > > >
> > > > > Very informative message. Thanks a lot. I'm still a bit troubled by
> > > > > the fact that JSF didn't have this built in. It seems like such an
> > > > > integral piece of a web framework that is used to accomplish a wide
> > > > > range of tasks, so much so that it seems to me that the spec writers
> > > > > couldn't have simply forgotten it, and it makes me wonder if the
> tasks
> > > > > I would accomplish with it were accounted for somewhere else in the
> > > > > specification. Could you give me an example of what you use the
> onload
> > > > > method for? I know what I would do with it, but I'd just like to see
> > > > > what you have to say without trying to take into account what I
> write.
> > > > >
> > > > > Thanks,
> > > > > benjamin van der veen
> > > > >
> > > > > On 4/30/06, Andrew Robinson <andrew.rw.robinson@gmail.com > wrote:
> > > > > > If you find any issues with the onload with jsf-comp please let me
> > > > > > know (I am the author). I am using it at home and at work without
> > > > > > issues except for JBoss-Seam EJB interceptors. Seam depends on the
> > > > > > action method unfortunately.
> > > > > >
> > > > > > I looked fairly closely at the spec before writing the onload and
> made
> > > > > > sure that the code I wrote conforms to what you are allowed to do.
> It
> > > > > > behaves similarly to an action that decides to forward/include a
> > > > > > non-JSF page. It uses the correct redirection and ensures the
> faces
> > > > > > response is marked complete. So in these respects, it should not
> > > > > > interfere with the specification at all. The only issue (like
> Seam) is
> > > > > > when code may not expect action methods to be executed outside of
> the
> > > > > > execute action JSF phase.
> > > > > >
> > > > > > I couldn't believe it either, before I wrote it, that JSF was
> missing
> > > > > > such a huge piece of functionality. All other languages (PHP,
> Perl,
> > > > > > ASP, ASP.NET, JSP) allow you to perform code when loading a page
> so I
> > > > > > don't know why it wouldn't be in JSF.
> > > > > >
> > > > > > As a side note, Shale has something similar with the page
> controller.
> > > > > > What I didn't like about it was that it had "void" as the return
> type
> > > > > > and therefore you could not as easily interact with the navigation
> > > > > > handling. The other problem I had with the JSF spec in these
> regards
> > > > > > was the lack of externalized functionality in the
> NavigationHandler
> > > > > > interface. I would love to get the view for a result without
> actually
> > > > > > navigating there, or be able to extend the navigation handler and
> be
> > > > > > able to modify the view after the method is fired but before the
> new
> > > > > > view is created.
> > > > > >
> > > > > > -Andrew
> > > > > >
> > > > > > On 4/30/06, benjamin van der veen < bvanderveen@gmail.com> wrote:
> > > > > > > Xie Min,
> > > > > > >
> > > > > > > This is a great find, very close to what I'm talking about.
> However,
> > > > > > > in the following line:
> > > > > > >
> > > > > > >
> > >
> <to-view-id>/view.jsp?objectId=#{view.objectId}</to-view-id>
> > > > > > >
> > > > > > > what object does 'view' in the EL expression reference? Is this
> an
> > > > > > > implicit object, or one defined in a configuration somewhere? If
> it
> > > is
> > > > > > > implicit, how do I set it's properties from a backing bean?
> > > > > > >
> > > > > > > Thanks a lot,
> > > > > > > benjamin
> > > > > > >
> > > > > > >
> > > > > > > On 4/29/06, xie min < xiemin0914@gmail.com> wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > in myfaces
> > > > > > > > wiki(
> > >
> http://wiki.apache.org/myfaces/Custom_Navigation_Handler),
> > > > > > > > threr are some suggestion on url parameters passing:
> > > > > > > >
> > > > > > > > Dynamic Url parameters passing: This allows passing parameters
> > > between pages
> > > > > > > > even when using redirection method. For exmaple, in order to
> > > navigate from a
> > > > > > > > pages name: view.jsp to a page named: edit.jsp, with the
> > > parameter:
> > > > > > > > objectId, the following thing can be done in navigation rule
> code:
> > > > > > > > <navigation-rule>
> > > > > > > >  <from-view-id>/view.jsp</from-view-id>
> > > > > > > >  <navigation-case>
> > > > > > > >  <from-outcome>edit</from-outcome>
> > > > > > > >
> > > <to-view-id>/view.jsp?objectId=#{view.objectId
> }</to-view-id>
> > > > > > > >  <redirect />
> > > > > > > >  </navigation-case>
> > > > > > > >  </navigation-rule>
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > 2006/4/30, benjamin van der veen < bvanderveen@gmail.com >:
> > > > > > > > > I think that jsf-comp onload thing might be what I'm looking
> > > for. I
> > > > > > > > > really surprised that something like this isn't built in to
> JSF.
> > > Is
> > > > > > > > > using this extension violating some design principle
> fundamental
> > > to
> > > > > > > > > JSF?
> > > > > > > > >
> > > > > > > > > benjamin
> > > > > > > > >
> > > > > > > > > On 4/28/06, Andrew Robinson < andrew.rw.robinson@gmail.com>
> > > wrote:
> > > > > > > > > > Have a look at:
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > >
> http://wiki.apache.org/myfaces/InvokingJsfPagesWithStandardUrls
> > > > > > > > > >
> > > > > > > >
> > >
> http://jsf-comp.sourceforge.net/components/onload/index.html
> > > > > > > > > >
> > > > > > > > > > -Andrew
> > > > > > > > > >
> > > > > > > > > > On 4/28/06, benjamin van der veen < bvanderveen@gmail.com>
> > > wrote:
> > > > > > > > > > > Hello,
> > > > > > > > > > >
> > > > > > > > > > > I sent the message quoted below to this list a few days
> ago,
> > > but
> > > > > > > > > > > received no replies. I'm just wondering if perhaps it
> just
> > > got
> > > > > > > > > > > overlooked; I would appreciate any insight on this
> issue.
> > > > > > > > > > >
> > > > > > > > > > > Thanks a lot,
> > > > > > > > > > > benjamin
> > > > > > > > > > >
> > > > > > > > > > > On 4/26/06, benjamin van der veen <
> bvanderveen@gmail.com>
> > > wrote:
> > > > > > > > > > > > Hello,
> > > > > > > > > > > >
> > > > > > > > > > > > I'm coming from a PHP background, and I've run into a
> wall
> > > with JSF.
> > > > > > > > I
> > > > > > > > > > > > know how I'd get around it with PHP or ASP.NET, but
> for
> > > JSF I'm
> > > > > > > > > > > > stumped.
> > > > > > > > > > > >
> > > > > > > > > > > > Here's the scenario:
> > > > > > > > > > > >
> > > > > > > > > > > > I'm making a message board. It has multiple forum each
> of
> > > which has
> > > > > > > > > > > > many topics, each of which has many posts. Very
> standard
> > > thing here.
> > > > > > > > I
> > > > > > > > > > > > am implementing the page which allows a user to create
> a
> > > new topic.
> > > > > > > > > > > > The URI is of the form "createTopic.jsf?forumId=<n>"
> where
> > > <n> is an
> > > > > > > > > > > > integer corresponding to the forum's primary key in
> the
> > > database. I
> > > > > > > > > > > > have a backing bean mapped in faces-config to
> > > "CreateTopicBean", and
> > > > > > > > > > > > it is request scoped. Now, when the user submits the
> form
> > > to create
> > > > > > > > a
> > > > > > > > > > > > topic, what is the best way to let the bean know which
> > > forum this
> > > > > > > > > > > > topic should be created under? I tried having a
> managed
> > > property
> > > > > > > > like
> > > > > > > > > > > > this:
> > > > > > > > > > > >
> > > > > > > > > > > > <managed-bean>
> > > > > > > > > > > >
> > > > > > > >
> > > <managed-bean-name>CreateTopicBean</managed-bean-name>
> > > > > > > > > > > >         <managed-bean-class>
> > > > > > > > > > > >
> > > > > > > >
> com.wepwnsnails.faces.managedbean.CreateTopicBean
> > > > > > > > > > > >         </managed-bean-class>
> > > > > > > > > > > >
> > > > > > > >
> <managed-bean-scope>request</managed-bean-scope>
> > > > > > > > > > > >         <managed-property>
> > > > > > > > > > > >
> > > > > > > > <property-name>forumId</property-name>
> > > > > > > > > > > >                 <value>#{ param.forumId}</value>
> > > > > > > > > > > >         </managed-property>
> > > > > > > > > > > > </managed-bean>
> > > > > > > > > > > >
> > > > > > > > > > > > but when the "action" attribute of the html <form>
> element
> > > rendered
> > > > > > > > by
> > > > > > > > > > > > JSF is simply " createTopic.jsf", so an EL exception
> is
> > > thrown when
> > > > > > > > JSF
> > > > > > > > > > > > fails to set the managed property.
> > > > > > > > > > > >
> > > > > > > > > > > > I've also tried adding a <h:inputHidden> tag set to
> the
> > > forumId on
> > > > > > > > the
> > > > > > > > > > > > backing bean in a variety of ways, but they leave much
> to
> > > be desired
> > > > > > > > > > > > as far as cleanliness.
> > > > > > > > > > > >
> > > > > > > > > > > > I'm sure that this is an issue every newbie JSF
> developer
> > > has
> > > > > > > > > > > > scratched his head over; so what's the best way to go
> > > about this?
> > > > > > > > I've
> > > > > > > > > > > > had a hard time finding anything in Google, mostly
> because
> > > I don't
> > > > > > > > > > > > know how to tersely phrase the problem for a seach
> query.
> > > > > > > > > > > >
> > > > > > > > > > > > Thanks a lot,
> > > > > > > > > > > > benjamin van der veen
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>

Re: What to do when form depends on querystring params?

[Craig McClanahan <cr...@apache.org>]

On 5/1/06, Andrew Robinson <an...@gmail.com> wrote:
>
> As I mentioned, I didn't want to use Shale as it doesn't not have the
> built-in ability to redirect from the methods (prerender for example),
> at least not when I last looked.


That (ability to redirect from *within* these event handling methods) is not
built in, but it is possible to do manually.  On the other hand, that also
goes against the design patterns these methods are there to support -- the
assumption is that someone, somewhere, already decided to navigate to this
page, and did so either with a redirect or a forward, via either a GET or a
POST.  The prerender() method is all about what happens *next*, not how we
got to this point.

Think of prerender() as "set up the dynamic data I need to render the
current page", not as "decide whether to display this page or go
elsewhere".  That should have been done already in your application's action
method (for a POST), or via the hyperink or bookmark that got you here (for
a GET).

I'd be interested in exploring how your use cases might be different from
the one ViewController is targeted at ... but perhaps that's a subject for
the Struts list, since it is about the implementation of a Shale feature,
rather than purely about JSF.

I was also afraid of
> incompatibilities between Shale and JBoss-Seam.


That shouldn't be a concern-- they will work together fine (although you'll
probably be using Seam's notion of conversations rather than Shale Dialogs
if you are using the combination).

-Andrew


Craig

On 5/1/06, Craig McClanahan <cr...@apache.org> wrote:
> >
> >
> >
> > On 5/1/06, Andrew Robinson <andrew.rw.robinson@gmail.com > wrote:
> > > I agree, I have not given up in trying to find a "built in" way of
> > > doing it in JSF, but still have not found a way. The problem is that
> > > JSF is all about actions when execution Java code. The problem is that
> > > actions are never run on the first time a page is hit, only on POST
> > > back. I guess it is simply a major gap when decoupling the business
> > > code from the UI.
> >
> >
> > This kind of issue was a key motivation for the ViewController
> functionality
> > in Shale[1].  In particular, the prerender() method is a good place to
> deal
> > with this kind of issue, because it:
> >
> > * Is called on both GET and POST requests.
> >
> > * Is called *before* rendering takes place, so you can
> >   effect the response (include error messages, etc.)
> >
> > * Allows you to set up resources that are required for
> >   rendering (allocate a JDBC connection, open a Hibernate
> >   session, whatever) that is required for rendering, then
> >   clean up after rendering in the destroy() method.
> >
> > You can do this kind of thing yourself with a phase listener, but you're
> > going to end up basically replicating what Shale already provides.
> >
> > Craig
> >
> > [1] http://struts.apache.org/struts-shale/
> >
> >
> >
> > > I use the on-load component mostly for bookmarks. Say, somone
> > > bookmarks "edit.jsf", I use the on-load component to redirect them
> > > back to "index.jsf" if there is no property to edit (the backing bean
> > > is not in an editing state).
> > >
> > > The other thing I use it for is to load data that may fail. Say
> > > hitting a web service for example. In a getter method, the response is
> > > probably already committed and therefore too late to redirect the user
> > > or forward to a new page. Also, it is hard to add FacesMessages in a
> > > getter as the message(s) component(s) may have already been rendered,
> > > and once again it would be too late. The on-load allows me to
> > > gracefully handle errors in backing-bean methods during the loading of
> > > a new page.
> > >
> > > If there is a better way that you find or a way I can improve it, let
> > > me know. I would have much preferred to see this in the specification
> > > than have to make a one-off open source component.
> > >
> > > -Andrew
> > >
> > > On 4/30/06, benjamin van der veen <bv...@gmail.com> wrote:
> > > > Andrew,
> > > >
> > > > Very informative message. Thanks a lot. I'm still a bit troubled by
> > > > the fact that JSF didn't have this built in. It seems like such an
> > > > integral piece of a web framework that is used to accomplish a wide
> > > > range of tasks, so much so that it seems to me that the spec writers
> > > > couldn't have simply forgotten it, and it makes me wonder if the
> tasks
> > > > I would accomplish with it were accounted for somewhere else in the
> > > > specification. Could you give me an example of what you use the
> onload
> > > > method for? I know what I would do with it, but I'd just like to see
> > > > what you have to say without trying to take into account what I
> write.
> > > >
> > > > Thanks,
> > > > benjamin van der veen
> > > >
> > > > On 4/30/06, Andrew Robinson <an...@gmail.com> wrote:
> > > > > If you find any issues with the onload with jsf-comp please let me
> > > > > know (I am the author). I am using it at home and at work without
> > > > > issues except for JBoss-Seam EJB interceptors. Seam depends on the
> > > > > action method unfortunately.
> > > > >
> > > > > I looked fairly closely at the spec before writing the onload and
> made
> > > > > sure that the code I wrote conforms to what you are allowed to do.
> It
> > > > > behaves similarly to an action that decides to forward/include a
> > > > > non-JSF page. It uses the correct redirection and ensures the
> faces
> > > > > response is marked complete. So in these respects, it should not
> > > > > interfere with the specification at all. The only issue (like
> Seam) is
> > > > > when code may not expect action methods to be executed outside of
> the
> > > > > execute action JSF phase.
> > > > >
> > > > > I couldn't believe it either, before I wrote it, that JSF was
> missing
> > > > > such a huge piece of functionality. All other languages (PHP,
> Perl,
> > > > > ASP, ASP.NET, JSP) allow you to perform code when loading a page
> so I
> > > > > don't know why it wouldn't be in JSF.
> > > > >
> > > > > As a side note, Shale has something similar with the page
> controller.
> > > > > What I didn't like about it was that it had "void" as the return
> type
> > > > > and therefore you could not as easily interact with the navigation
> > > > > handling. The other problem I had with the JSF spec in these
> regards
> > > > > was the lack of externalized functionality in the
> NavigationHandler
> > > > > interface. I would love to get the view for a result without
> actually
> > > > > navigating there, or be able to extend the navigation handler and
> be
> > > > > able to modify the view after the method is fired but before the
> new
> > > > > view is created.
> > > > >
> > > > > -Andrew
> > > > >
> > > > > On 4/30/06, benjamin van der veen < bvanderveen@gmail.com> wrote:
> > > > > > Xie Min,
> > > > > >
> > > > > > This is a great find, very close to what I'm talking about.
> However,
> > > > > > in the following line:
> > > > > >
> > > > > >
> > <to-view-id>/view.jsp?objectId=#{view.objectId}</to-view-id>
> > > > > >
> > > > > > what object does 'view' in the EL expression reference? Is this
> an
> > > > > > implicit object, or one defined in a configuration somewhere? If
> it
> > is
> > > > > > implicit, how do I set it's properties from a backing bean?
> > > > > >
> > > > > > Thanks a lot,
> > > > > > benjamin
> > > > > >
> > > > > >
> > > > > > On 4/29/06, xie min < xiemin0914@gmail.com> wrote:
> > > > > > >
> > > > > > >
> > > > > > > in myfaces
> > > > > > > wiki(
> > http://wiki.apache.org/myfaces/Custom_Navigation_Handler),
> > > > > > > threr are some suggestion on url parameters passing:
> > > > > > >
> > > > > > > Dynamic Url parameters passing: This allows passing parameters
> > between pages
> > > > > > > even when using redirection method. For exmaple, in order to
> > navigate from a
> > > > > > > pages name: view.jsp to a page named: edit.jsp, with the
> > parameter:
> > > > > > > objectId, the following thing can be done in navigation rule
> code:
> > > > > > > <navigation-rule>
> > > > > > >  <from-view-id>/view.jsp</from-view-id>
> > > > > > >  <navigation-case>
> > > > > > >  <from-outcome>edit</from-outcome>
> > > > > > >
> > <to-view-id>/view.jsp?objectId=#{view.objectId}</to-view-id>
> > > > > > >  <redirect />
> > > > > > >  </navigation-case>
> > > > > > >  </navigation-rule>
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > 2006/4/30, benjamin van der veen < bvanderveen@gmail.com>:
> > > > > > > > I think that jsf-comp onload thing might be what I'm looking
> > for. I
> > > > > > > > really surprised that something like this isn't built in to
> JSF.
> > Is
> > > > > > > > using this extension violating some design principle
> fundamental
> > to
> > > > > > > > JSF?
> > > > > > > >
> > > > > > > > benjamin
> > > > > > > >
> > > > > > > > On 4/28/06, Andrew Robinson < andrew.rw.robinson@gmail.com>
> > wrote:
> > > > > > > > > Have a look at:
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > http://wiki.apache.org/myfaces/InvokingJsfPagesWithStandardUrls
> > > > > > > > >
> > > > > > >
> > http://jsf-comp.sourceforge.net/components/onload/index.html
> > > > > > > > >
> > > > > > > > > -Andrew
> > > > > > > > >
> > > > > > > > > On 4/28/06, benjamin van der veen < bvanderveen@gmail.com>
> > wrote:
> > > > > > > > > > Hello,
> > > > > > > > > >
> > > > > > > > > > I sent the message quoted below to this list a few days
> ago,
> > but
> > > > > > > > > > received no replies. I'm just wondering if perhaps it
> just
> > got
> > > > > > > > > > overlooked; I would appreciate any insight on this
> issue.
> > > > > > > > > >
> > > > > > > > > > Thanks a lot,
> > > > > > > > > > benjamin
> > > > > > > > > >
> > > > > > > > > > On 4/26/06, benjamin van der veen <
> bvanderveen@gmail.com>
> > wrote:
> > > > > > > > > > > Hello,
> > > > > > > > > > >
> > > > > > > > > > > I'm coming from a PHP background, and I've run into a
> wall
> > with JSF.
> > > > > > > I
> > > > > > > > > > > know how I'd get around it with PHP or ASP.NET, but
> for
> > JSF I'm
> > > > > > > > > > > stumped.
> > > > > > > > > > >
> > > > > > > > > > > Here's the scenario:
> > > > > > > > > > >
> > > > > > > > > > > I'm making a message board. It has multiple forum each
> of
> > which has
> > > > > > > > > > > many topics, each of which has many posts. Very
> standard
> > thing here.
> > > > > > > I
> > > > > > > > > > > am implementing the page which allows a user to create
> a
> > new topic.
> > > > > > > > > > > The URI is of the form "createTopic.jsf?forumId=<n>"
> where
> > <n> is an
> > > > > > > > > > > integer corresponding to the forum's primary key in
> the
> > database. I
> > > > > > > > > > > have a backing bean mapped in faces-config to
> > "CreateTopicBean", and
> > > > > > > > > > > it is request scoped. Now, when the user submits the
> form
> > to create
> > > > > > > a
> > > > > > > > > > > topic, what is the best way to let the bean know which
> > forum this
> > > > > > > > > > > topic should be created under? I tried having a
> managed
> > property
> > > > > > > like
> > > > > > > > > > > this:
> > > > > > > > > > >
> > > > > > > > > > > <managed-bean>
> > > > > > > > > > >
> > > > > > >
> > <managed-bean-name>CreateTopicBean</managed-bean-name>
> > > > > > > > > > >         <managed-bean-class>
> > > > > > > > > > >
> > > > > > > com.wepwnsnails.faces.managedbean.CreateTopicBean
> > > > > > > > > > >         </managed-bean-class>
> > > > > > > > > > >
> > > > > > > <managed-bean-scope>request</managed-bean-scope>
> > > > > > > > > > >         <managed-property>
> > > > > > > > > > >
> > > > > > > <property-name>forumId</property-name>
> > > > > > > > > > >                 <value>#{ param.forumId}</value>
> > > > > > > > > > >         </managed-property>
> > > > > > > > > > > </managed-bean>
> > > > > > > > > > >
> > > > > > > > > > > but when the "action" attribute of the html <form>
> element
> > rendered
> > > > > > > by
> > > > > > > > > > > JSF is simply "createTopic.jsf", so an EL exception is
> > thrown when
> > > > > > > JSF
> > > > > > > > > > > fails to set the managed property.
> > > > > > > > > > >
> > > > > > > > > > > I've also tried adding a <h:inputHidden> tag set to
> the
> > forumId on
> > > > > > > the
> > > > > > > > > > > backing bean in a variety of ways, but they leave much
> to
> > be desired
> > > > > > > > > > > as far as cleanliness.
> > > > > > > > > > >
> > > > > > > > > > > I'm sure that this is an issue every newbie JSF
> developer
> > has
> > > > > > > > > > > scratched his head over; so what's the best way to go
> > about this?
> > > > > > > I've
> > > > > > > > > > > had a hard time finding anything in Google, mostly
> because
> > I don't
> > > > > > > > > > > know how to tersely phrase the problem for a seach
> query.
> > > > > > > > > > >
> > > > > > > > > > > Thanks a lot,
> > > > > > > > > > > benjamin van der veen
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >
>

Re: What to do when form depends on querystring params?

[Andrew Robinson <an...@gmail.com>]

As I mentioned, I didn't want to use Shale as it doesn't not have the
built-in ability to redirect from the methods (prerender for example),
at least not when I last looked. I was also afraid of
incompatibilities between Shale and JBoss-Seam.

-Andrew

On 5/1/06, Craig McClanahan <cr...@apache.org> wrote:
>
>
>
> On 5/1/06, Andrew Robinson <andrew.rw.robinson@gmail.com > wrote:
> > I agree, I have not given up in trying to find a "built in" way of
> > doing it in JSF, but still have not found a way. The problem is that
> > JSF is all about actions when execution Java code. The problem is that
> > actions are never run on the first time a page is hit, only on POST
> > back. I guess it is simply a major gap when decoupling the business
> > code from the UI.
>
>
> This kind of issue was a key motivation for the ViewController functionality
> in Shale[1].  In particular, the prerender() method is a good place to deal
> with this kind of issue, because it:
>
> * Is called on both GET and POST requests.
>
> * Is called *before* rendering takes place, so you can
>   effect the response (include error messages, etc.)
>
> * Allows you to set up resources that are required for
>   rendering (allocate a JDBC connection, open a Hibernate
>   session, whatever) that is required for rendering, then
>   clean up after rendering in the destroy() method.
>
> You can do this kind of thing yourself with a phase listener, but you're
> going to end up basically replicating what Shale already provides.
>
> Craig
>
> [1] http://struts.apache.org/struts-shale/
>
>
>
> > I use the on-load component mostly for bookmarks. Say, somone
> > bookmarks "edit.jsf", I use the on-load component to redirect them
> > back to "index.jsf" if there is no property to edit (the backing bean
> > is not in an editing state).
> >
> > The other thing I use it for is to load data that may fail. Say
> > hitting a web service for example. In a getter method, the response is
> > probably already committed and therefore too late to redirect the user
> > or forward to a new page. Also, it is hard to add FacesMessages in a
> > getter as the message(s) component(s) may have already been rendered,
> > and once again it would be too late. The on-load allows me to
> > gracefully handle errors in backing-bean methods during the loading of
> > a new page.
> >
> > If there is a better way that you find or a way I can improve it, let
> > me know. I would have much preferred to see this in the specification
> > than have to make a one-off open source component.
> >
> > -Andrew
> >
> > On 4/30/06, benjamin van der veen <bv...@gmail.com> wrote:
> > > Andrew,
> > >
> > > Very informative message. Thanks a lot. I'm still a bit troubled by
> > > the fact that JSF didn't have this built in. It seems like such an
> > > integral piece of a web framework that is used to accomplish a wide
> > > range of tasks, so much so that it seems to me that the spec writers
> > > couldn't have simply forgotten it, and it makes me wonder if the tasks
> > > I would accomplish with it were accounted for somewhere else in the
> > > specification. Could you give me an example of what you use the onload
> > > method for? I know what I would do with it, but I'd just like to see
> > > what you have to say without trying to take into account what I write.
> > >
> > > Thanks,
> > > benjamin van der veen
> > >
> > > On 4/30/06, Andrew Robinson <an...@gmail.com> wrote:
> > > > If you find any issues with the onload with jsf-comp please let me
> > > > know (I am the author). I am using it at home and at work without
> > > > issues except for JBoss-Seam EJB interceptors. Seam depends on the
> > > > action method unfortunately.
> > > >
> > > > I looked fairly closely at the spec before writing the onload and made
> > > > sure that the code I wrote conforms to what you are allowed to do. It
> > > > behaves similarly to an action that decides to forward/include a
> > > > non-JSF page. It uses the correct redirection and ensures the faces
> > > > response is marked complete. So in these respects, it should not
> > > > interfere with the specification at all. The only issue (like Seam) is
> > > > when code may not expect action methods to be executed outside of the
> > > > execute action JSF phase.
> > > >
> > > > I couldn't believe it either, before I wrote it, that JSF was missing
> > > > such a huge piece of functionality. All other languages (PHP, Perl,
> > > > ASP, ASP.NET, JSP) allow you to perform code when loading a page so I
> > > > don't know why it wouldn't be in JSF.
> > > >
> > > > As a side note, Shale has something similar with the page controller.
> > > > What I didn't like about it was that it had "void" as the return type
> > > > and therefore you could not as easily interact with the navigation
> > > > handling. The other problem I had with the JSF spec in these regards
> > > > was the lack of externalized functionality in the NavigationHandler
> > > > interface. I would love to get the view for a result without actually
> > > > navigating there, or be able to extend the navigation handler and be
> > > > able to modify the view after the method is fired but before the new
> > > > view is created.
> > > >
> > > > -Andrew
> > > >
> > > > On 4/30/06, benjamin van der veen < bvanderveen@gmail.com> wrote:
> > > > > Xie Min,
> > > > >
> > > > > This is a great find, very close to what I'm talking about. However,
> > > > > in the following line:
> > > > >
> > > > >
> <to-view-id>/view.jsp?objectId=#{view.objectId}</to-view-id>
> > > > >
> > > > > what object does 'view' in the EL expression reference? Is this an
> > > > > implicit object, or one defined in a configuration somewhere? If it
> is
> > > > > implicit, how do I set it's properties from a backing bean?
> > > > >
> > > > > Thanks a lot,
> > > > > benjamin
> > > > >
> > > > >
> > > > > On 4/29/06, xie min < xiemin0914@gmail.com> wrote:
> > > > > >
> > > > > >
> > > > > > in myfaces
> > > > > > wiki(
> http://wiki.apache.org/myfaces/Custom_Navigation_Handler),
> > > > > > threr are some suggestion on url parameters passing:
> > > > > >
> > > > > > Dynamic Url parameters passing: This allows passing parameters
> between pages
> > > > > > even when using redirection method. For exmaple, in order to
> navigate from a
> > > > > > pages name: view.jsp to a page named: edit.jsp, with the
> parameter:
> > > > > > objectId, the following thing can be done in navigation rule code:
> > > > > > <navigation-rule>
> > > > > >  <from-view-id>/view.jsp</from-view-id>
> > > > > >  <navigation-case>
> > > > > >  <from-outcome>edit</from-outcome>
> > > > > >
> <to-view-id>/view.jsp?objectId=#{view.objectId}</to-view-id>
> > > > > >  <redirect />
> > > > > >  </navigation-case>
> > > > > >  </navigation-rule>
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > 2006/4/30, benjamin van der veen < bvanderveen@gmail.com>:
> > > > > > > I think that jsf-comp onload thing might be what I'm looking
> for. I
> > > > > > > really surprised that something like this isn't built in to JSF.
> Is
> > > > > > > using this extension violating some design principle fundamental
> to
> > > > > > > JSF?
> > > > > > >
> > > > > > > benjamin
> > > > > > >
> > > > > > > On 4/28/06, Andrew Robinson < andrew.rw.robinson@gmail.com>
> wrote:
> > > > > > > > Have a look at:
> > > > > > > >
> > > > > > > >
> > > > > >
> http://wiki.apache.org/myfaces/InvokingJsfPagesWithStandardUrls
> > > > > > > >
> > > > > >
> http://jsf-comp.sourceforge.net/components/onload/index.html
> > > > > > > >
> > > > > > > > -Andrew
> > > > > > > >
> > > > > > > > On 4/28/06, benjamin van der veen < bvanderveen@gmail.com>
> wrote:
> > > > > > > > > Hello,
> > > > > > > > >
> > > > > > > > > I sent the message quoted below to this list a few days ago,
> but
> > > > > > > > > received no replies. I'm just wondering if perhaps it just
> got
> > > > > > > > > overlooked; I would appreciate any insight on this issue.
> > > > > > > > >
> > > > > > > > > Thanks a lot,
> > > > > > > > > benjamin
> > > > > > > > >
> > > > > > > > > On 4/26/06, benjamin van der veen < bvanderveen@gmail.com>
> wrote:
> > > > > > > > > > Hello,
> > > > > > > > > >
> > > > > > > > > > I'm coming from a PHP background, and I've run into a wall
> with JSF.
> > > > > > I
> > > > > > > > > > know how I'd get around it with PHP or ASP.NET, but for
> JSF I'm
> > > > > > > > > > stumped.
> > > > > > > > > >
> > > > > > > > > > Here's the scenario:
> > > > > > > > > >
> > > > > > > > > > I'm making a message board. It has multiple forum each of
> which has
> > > > > > > > > > many topics, each of which has many posts. Very standard
> thing here.
> > > > > > I
> > > > > > > > > > am implementing the page which allows a user to create a
> new topic.
> > > > > > > > > > The URI is of the form "createTopic.jsf?forumId=<n>" where
> <n> is an
> > > > > > > > > > integer corresponding to the forum's primary key in the
> database. I
> > > > > > > > > > have a backing bean mapped in faces-config to
> "CreateTopicBean", and
> > > > > > > > > > it is request scoped. Now, when the user submits the form
> to create
> > > > > > a
> > > > > > > > > > topic, what is the best way to let the bean know which
> forum this
> > > > > > > > > > topic should be created under? I tried having a managed
> property
> > > > > > like
> > > > > > > > > > this:
> > > > > > > > > >
> > > > > > > > > > <managed-bean>
> > > > > > > > > >
> > > > > >
> <managed-bean-name>CreateTopicBean</managed-bean-name>
> > > > > > > > > >         <managed-bean-class>
> > > > > > > > > >
> > > > > > com.wepwnsnails.faces.managedbean.CreateTopicBean
> > > > > > > > > >         </managed-bean-class>
> > > > > > > > > >
> > > > > > <managed-bean-scope>request</managed-bean-scope>
> > > > > > > > > >         <managed-property>
> > > > > > > > > >
> > > > > > <property-name>forumId</property-name>
> > > > > > > > > >                 <value>#{ param.forumId}</value>
> > > > > > > > > >         </managed-property>
> > > > > > > > > > </managed-bean>
> > > > > > > > > >
> > > > > > > > > > but when the "action" attribute of the html <form> element
> rendered
> > > > > > by
> > > > > > > > > > JSF is simply "createTopic.jsf", so an EL exception is
> thrown when
> > > > > > JSF
> > > > > > > > > > fails to set the managed property.
> > > > > > > > > >
> > > > > > > > > > I've also tried adding a <h:inputHidden> tag set to the
> forumId on
> > > > > > the
> > > > > > > > > > backing bean in a variety of ways, but they leave much to
> be desired
> > > > > > > > > > as far as cleanliness.
> > > > > > > > > >
> > > > > > > > > > I'm sure that this is an issue every newbie JSF developer
> has
> > > > > > > > > > scratched his head over; so what's the best way to go
> about this?
> > > > > > I've
> > > > > > > > > > had a hard time finding anything in Google, mostly because
> I don't
> > > > > > > > > > know how to tersely phrase the problem for a seach query.
> > > > > > > > > >
> > > > > > > > > > Thanks a lot,
> > > > > > > > > > benjamin van der veen
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
>

Re: What to do when form depends on querystring params?

[Craig McClanahan <cr...@apache.org>]

On 5/1/06, Andrew Robinson <an...@gmail.com> wrote:
>
> I agree, I have not given up in trying to find a "built in" way of
> doing it in JSF, but still have not found a way. The problem is that
> JSF is all about actions when execution Java code. The problem is that
> actions are never run on the first time a page is hit, only on POST
> back. I guess it is simply a major gap when decoupling the business
> code from the UI.


This kind of issue was a key motivation for the ViewController functionality
in Shale[1].  In particular, the prerender() method is a good place to deal
with this kind of issue, because it:

* Is called on both GET and POST requests.

* Is called *before* rendering takes place, so you can
  effect the response (include error messages, etc.)

* Allows you to set up resources that are required for
  rendering (allocate a JDBC connection, open a Hibernate
  session, whatever) that is required for rendering, then
  clean up after rendering in the destroy() method.

You can do this kind of thing yourself with a phase listener, but you're
going to end up basically replicating what Shale already provides.

Craig

[1] http://struts.apache.org/struts-shale/


I use the on-load component mostly for bookmarks. Say, somone
> bookmarks "edit.jsf", I use the on-load component to redirect them
> back to "index.jsf" if there is no property to edit (the backing bean
> is not in an editing state).
>
> The other thing I use it for is to load data that may fail. Say
> hitting a web service for example. In a getter method, the response is
> probably already committed and therefore too late to redirect the user
> or forward to a new page. Also, it is hard to add FacesMessages in a
> getter as the message(s) component(s) may have already been rendered,
> and once again it would be too late. The on-load allows me to
> gracefully handle errors in backing-bean methods during the loading of
> a new page.
>
> If there is a better way that you find or a way I can improve it, let
> me know. I would have much preferred to see this in the specification
> than have to make a one-off open source component.
>
> -Andrew
>
> On 4/30/06, benjamin van der veen <bv...@gmail.com> wrote:
> > Andrew,
> >
> > Very informative message. Thanks a lot. I'm still a bit troubled by
> > the fact that JSF didn't have this built in. It seems like such an
> > integral piece of a web framework that is used to accomplish a wide
> > range of tasks, so much so that it seems to me that the spec writers
> > couldn't have simply forgotten it, and it makes me wonder if the tasks
> > I would accomplish with it were accounted for somewhere else in the
> > specification. Could you give me an example of what you use the onload
> > method for? I know what I would do with it, but I'd just like to see
> > what you have to say without trying to take into account what I write.
> >
> > Thanks,
> > benjamin van der veen
> >
> > On 4/30/06, Andrew Robinson <an...@gmail.com> wrote:
> > > If you find any issues with the onload with jsf-comp please let me
> > > know (I am the author). I am using it at home and at work without
> > > issues except for JBoss-Seam EJB interceptors. Seam depends on the
> > > action method unfortunately.
> > >
> > > I looked fairly closely at the spec before writing the onload and made
> > > sure that the code I wrote conforms to what you are allowed to do. It
> > > behaves similarly to an action that decides to forward/include a
> > > non-JSF page. It uses the correct redirection and ensures the faces
> > > response is marked complete. So in these respects, it should not
> > > interfere with the specification at all. The only issue (like Seam) is
> > > when code may not expect action methods to be executed outside of the
> > > execute action JSF phase.
> > >
> > > I couldn't believe it either, before I wrote it, that JSF was missing
> > > such a huge piece of functionality. All other languages (PHP, Perl,
> > > ASP, ASP.NET, JSP) allow you to perform code when loading a page so I
> > > don't know why it wouldn't be in JSF.
> > >
> > > As a side note, Shale has something similar with the page controller.
> > > What I didn't like about it was that it had "void" as the return type
> > > and therefore you could not as easily interact with the navigation
> > > handling. The other problem I had with the JSF spec in these regards
> > > was the lack of externalized functionality in the NavigationHandler
> > > interface. I would love to get the view for a result without actually
> > > navigating there, or be able to extend the navigation handler and be
> > > able to modify the view after the method is fired but before the new
> > > view is created.
> > >
> > > -Andrew
> > >
> > > On 4/30/06, benjamin van der veen < bvanderveen@gmail.com> wrote:
> > > > Xie Min,
> > > >
> > > > This is a great find, very close to what I'm talking about. However,
> > > > in the following line:
> > > >
> > > > <to-view-id>/view.jsp?objectId=#{view.objectId}</to-view-id>
> > > >
> > > > what object does 'view' in the EL expression reference? Is this an
> > > > implicit object, or one defined in a configuration somewhere? If it
> is
> > > > implicit, how do I set it's properties from a backing bean?
> > > >
> > > > Thanks a lot,
> > > > benjamin
> > > >
> > > >
> > > > On 4/29/06, xie min < xiemin0914@gmail.com> wrote:
> > > > >
> > > > >
> > > > > in myfaces
> > > > > wiki( http://wiki.apache.org/myfaces/Custom_Navigation_Handler),
> > > > > threr are some suggestion on url parameters passing:
> > > > >
> > > > > Dynamic Url parameters passing: This allows passing parameters
> between pages
> > > > > even when using redirection method. For exmaple, in order to
> navigate from a
> > > > > pages name: view.jsp to a page named: edit.jsp, with the
> parameter:
> > > > > objectId, the following thing can be done in navigation rule code:
>
> > > > > <navigation-rule>
> > > > >  <from-view-id>/view.jsp</from-view-id>
> > > > >  <navigation-case>
> > > > >  <from-outcome>edit</from-outcome>
> > > > > <to-view-id>/view.jsp?objectId=#{view.objectId}</to-view-id>
> > > > >  <redirect />
> > > > >  </navigation-case>
> > > > >  </navigation-rule>
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > 2006/4/30, benjamin van der veen <bv...@gmail.com>:
> > > > > > I think that jsf-comp onload thing might be what I'm looking
> for. I
> > > > > > really surprised that something like this isn't built in to JSF.
> Is
> > > > > > using this extension violating some design principle fundamental
> to
> > > > > > JSF?
> > > > > >
> > > > > > benjamin
> > > > > >
> > > > > > On 4/28/06, Andrew Robinson < andrew.rw.robinson@gmail.com>
> wrote:
> > > > > > > Have a look at:
> > > > > > >
> > > > > > >
> > > > > http://wiki.apache.org/myfaces/InvokingJsfPagesWithStandardUrls
> > > > > > >
> > > > > http://jsf-comp.sourceforge.net/components/onload/index.html
> > > > > > >
> > > > > > > -Andrew
> > > > > > >
> > > > > > > On 4/28/06, benjamin van der veen < bvanderveen@gmail.com>
> wrote:
> > > > > > > > Hello,
> > > > > > > >
> > > > > > > > I sent the message quoted below to this list a few days ago,
> but
> > > > > > > > received no replies. I'm just wondering if perhaps it just
> got
> > > > > > > > overlooked; I would appreciate any insight on this issue.
> > > > > > > >
> > > > > > > > Thanks a lot,
> > > > > > > > benjamin
> > > > > > > >
> > > > > > > > On 4/26/06, benjamin van der veen < bvanderveen@gmail.com>
> wrote:
> > > > > > > > > Hello,
> > > > > > > > >
> > > > > > > > > I'm coming from a PHP background, and I've run into a wall
> with JSF.
> > > > > I
> > > > > > > > > know how I'd get around it with PHP or ASP.NET, but for
> JSF I'm
> > > > > > > > > stumped.
> > > > > > > > >
> > > > > > > > > Here's the scenario:
> > > > > > > > >
> > > > > > > > > I'm making a message board. It has multiple forum each of
> which has
> > > > > > > > > many topics, each of which has many posts. Very standard
> thing here.
> > > > > I
> > > > > > > > > am implementing the page which allows a user to create a
> new topic.
> > > > > > > > > The URI is of the form "createTopic.jsf?forumId=<n>" where
> <n> is an
> > > > > > > > > integer corresponding to the forum's primary key in the
> database. I
> > > > > > > > > have a backing bean mapped in faces-config to
> "CreateTopicBean", and
> > > > > > > > > it is request scoped. Now, when the user submits the form
> to create
> > > > > a
> > > > > > > > > topic, what is the best way to let the bean know which
> forum this
> > > > > > > > > topic should be created under? I tried having a managed
> property
> > > > > like
> > > > > > > > > this:
> > > > > > > > >
> > > > > > > > > <managed-bean>
> > > > > > > > >
> > > > > <managed-bean-name>CreateTopicBean</managed-bean-name>
> > > > > > > > >         <managed-bean-class>
> > > > > > > > >
> > > > > com.wepwnsnails.faces.managedbean.CreateTopicBean
> > > > > > > > >         </managed-bean-class>
> > > > > > > > >
> > > > > <managed-bean-scope>request</managed-bean-scope>
> > > > > > > > >         <managed-property>
> > > > > > > > >
> > > > > <property-name>forumId</property-name>
> > > > > > > > >                 <value>#{ param.forumId}</value>
> > > > > > > > >         </managed-property>
> > > > > > > > > </managed-bean>
> > > > > > > > >
> > > > > > > > > but when the "action" attribute of the html <form> element
> rendered
> > > > > by
> > > > > > > > > JSF is simply "createTopic.jsf", so an EL exception is
> thrown when
> > > > > JSF
> > > > > > > > > fails to set the managed property.
> > > > > > > > >
> > > > > > > > > I've also tried adding a <h:inputHidden> tag set to the
> forumId on
> > > > > the
> > > > > > > > > backing bean in a variety of ways, but they leave much to
> be desired
> > > > > > > > > as far as cleanliness.
> > > > > > > > >
> > > > > > > > > I'm sure that this is an issue every newbie JSF developer
> has
> > > > > > > > > scratched his head over; so what's the best way to go
> about this?
> > > > > I've
> > > > > > > > > had a hard time finding anything in Google, mostly because
> I don't
> > > > > > > > > know how to tersely phrase the problem for a seach query.
> > > > > > > > >
> > > > > > > > > Thanks a lot,
> > > > > > > > > benjamin van der veen
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: What to do when form depends on querystring params?

[Joey Geiger <jo...@staff.onmilwaukee.com>]

My solution was to use javascript redirecting on the page.

The backingbean had a value Valid, and if isValid was false, the 
javascript redirect rendered at the top of the page.

Messy? Maybe, but it does what I need it to do.

Re: What to do when form depends on querystring params?

[Andrew Robinson <an...@gmail.com>]

I agree, I have not given up in trying to find a "built in" way of
doing it in JSF, but still have not found a way. The problem is that
JSF is all about actions when execution Java code. The problem is that
actions are never run on the first time a page is hit, only on POST
back. I guess it is simply a major gap when decoupling the business
code from the UI.

I use the on-load component mostly for bookmarks. Say, somone
bookmarks "edit.jsf", I use the on-load component to redirect them
back to "index.jsf" if there is no property to edit (the backing bean
is not in an editing state).

The other thing I use it for is to load data that may fail. Say
hitting a web service for example. In a getter method, the response is
probably already committed and therefore too late to redirect the user
or forward to a new page. Also, it is hard to add FacesMessages in a
getter as the message(s) component(s) may have already been rendered,
and once again it would be too late. The on-load allows me to
gracefully handle errors in backing-bean methods during the loading of
a new page.

If there is a better way that you find or a way I can improve it, let
me know. I would have much preferred to see this in the specification
than have to make a one-off open source component.

-Andrew

On 4/30/06, benjamin van der veen <bv...@gmail.com> wrote:
> Andrew,
>
> Very informative message. Thanks a lot. I'm still a bit troubled by
> the fact that JSF didn't have this built in. It seems like such an
> integral piece of a web framework that is used to accomplish a wide
> range of tasks, so much so that it seems to me that the spec writers
> couldn't have simply forgotten it, and it makes me wonder if the tasks
> I would accomplish with it were accounted for somewhere else in the
> specification. Could you give me an example of what you use the onload
> method for? I know what I would do with it, but I'd just like to see
> what you have to say without trying to take into account what I write.
>
> Thanks,
> benjamin van der veen
>
> On 4/30/06, Andrew Robinson <an...@gmail.com> wrote:
> > If you find any issues with the onload with jsf-comp please let me
> > know (I am the author). I am using it at home and at work without
> > issues except for JBoss-Seam EJB interceptors. Seam depends on the
> > action method unfortunately.
> >
> > I looked fairly closely at the spec before writing the onload and made
> > sure that the code I wrote conforms to what you are allowed to do. It
> > behaves similarly to an action that decides to forward/include a
> > non-JSF page. It uses the correct redirection and ensures the faces
> > response is marked complete. So in these respects, it should not
> > interfere with the specification at all. The only issue (like Seam) is
> > when code may not expect action methods to be executed outside of the
> > execute action JSF phase.
> >
> > I couldn't believe it either, before I wrote it, that JSF was missing
> > such a huge piece of functionality. All other languages (PHP, Perl,
> > ASP, ASP.NET, JSP) allow you to perform code when loading a page so I
> > don't know why it wouldn't be in JSF.
> >
> > As a side note, Shale has something similar with the page controller.
> > What I didn't like about it was that it had "void" as the return type
> > and therefore you could not as easily interact with the navigation
> > handling. The other problem I had with the JSF spec in these regards
> > was the lack of externalized functionality in the NavigationHandler
> > interface. I would love to get the view for a result without actually
> > navigating there, or be able to extend the navigation handler and be
> > able to modify the view after the method is fired but before the new
> > view is created.
> >
> > -Andrew
> >
> > On 4/30/06, benjamin van der veen <bv...@gmail.com> wrote:
> > > Xie Min,
> > >
> > > This is a great find, very close to what I'm talking about. However,
> > > in the following line:
> > >
> > > <to-view-id>/view.jsp?objectId=#{view.objectId}</to-view-id>
> > >
> > > what object does 'view' in the EL expression reference? Is this an
> > > implicit object, or one defined in a configuration somewhere? If it is
> > > implicit, how do I set it's properties from a backing bean?
> > >
> > > Thanks a lot,
> > > benjamin
> > >
> > >
> > > On 4/29/06, xie min <xi...@gmail.com> wrote:
> > > >
> > > >
> > > > in myfaces
> > > > wiki(http://wiki.apache.org/myfaces/Custom_Navigation_Handler),
> > > > threr are some suggestion on url parameters passing:
> > > >
> > > > Dynamic Url parameters passing: This allows passing parameters between pages
> > > > even when using redirection method. For exmaple, in order to navigate from a
> > > > pages name: view.jsp to a page named: edit.jsp, with the parameter:
> > > > objectId, the following thing can be done in navigation rule code:
> > > > <navigation-rule>
> > > >  <from-view-id>/view.jsp</from-view-id>
> > > >  <navigation-case>
> > > >  <from-outcome>edit</from-outcome>
> > > > <to-view-id>/view.jsp?objectId=#{view.objectId}</to-view-id>
> > > >  <redirect />
> > > >  </navigation-case>
> > > >  </navigation-rule>
> > > >
> > > >
> > > >
> > > >
> > > > 2006/4/30, benjamin van der veen <bv...@gmail.com>:
> > > > > I think that jsf-comp onload thing might be what I'm looking for. I
> > > > > really surprised that something like this isn't built in to JSF. Is
> > > > > using this extension violating some design principle fundamental to
> > > > > JSF?
> > > > >
> > > > > benjamin
> > > > >
> > > > > On 4/28/06, Andrew Robinson <an...@gmail.com> wrote:
> > > > > > Have a look at:
> > > > > >
> > > > > >
> > > > http://wiki.apache.org/myfaces/InvokingJsfPagesWithStandardUrls
> > > > > >
> > > > http://jsf-comp.sourceforge.net/components/onload/index.html
> > > > > >
> > > > > > -Andrew
> > > > > >
> > > > > > On 4/28/06, benjamin van der veen <bv...@gmail.com> wrote:
> > > > > > > Hello,
> > > > > > >
> > > > > > > I sent the message quoted below to this list a few days ago, but
> > > > > > > received no replies. I'm just wondering if perhaps it just got
> > > > > > > overlooked; I would appreciate any insight on this issue.
> > > > > > >
> > > > > > > Thanks a lot,
> > > > > > > benjamin
> > > > > > >
> > > > > > > On 4/26/06, benjamin van der veen <bv...@gmail.com> wrote:
> > > > > > > > Hello,
> > > > > > > >
> > > > > > > > I'm coming from a PHP background, and I've run into a wall with JSF.
> > > > I
> > > > > > > > know how I'd get around it with PHP or ASP.NET, but for JSF I'm
> > > > > > > > stumped.
> > > > > > > >
> > > > > > > > Here's the scenario:
> > > > > > > >
> > > > > > > > I'm making a message board. It has multiple forum each of which has
> > > > > > > > many topics, each of which has many posts. Very standard thing here.
> > > > I
> > > > > > > > am implementing the page which allows a user to create a new topic.
> > > > > > > > The URI is of the form "createTopic.jsf?forumId=<n>" where <n> is an
> > > > > > > > integer corresponding to the forum's primary key in the database. I
> > > > > > > > have a backing bean mapped in faces-config to "CreateTopicBean", and
> > > > > > > > it is request scoped. Now, when the user submits the form to create
> > > > a
> > > > > > > > topic, what is the best way to let the bean know which forum this
> > > > > > > > topic should be created under? I tried having a managed property
> > > > like
> > > > > > > > this:
> > > > > > > >
> > > > > > > > <managed-bean>
> > > > > > > >
> > > > <managed-bean-name>CreateTopicBean</managed-bean-name>
> > > > > > > >         <managed-bean-class>
> > > > > > > >
> > > > com.wepwnsnails.faces.managedbean.CreateTopicBean
> > > > > > > >         </managed-bean-class>
> > > > > > > >
> > > > <managed-bean-scope>request</managed-bean-scope>
> > > > > > > >         <managed-property>
> > > > > > > >
> > > > <property-name>forumId</property-name>
> > > > > > > >                 <value>#{param.forumId}</value>
> > > > > > > >         </managed-property>
> > > > > > > > </managed-bean>
> > > > > > > >
> > > > > > > > but when the "action" attribute of the html <form> element rendered
> > > > by
> > > > > > > > JSF is simply "createTopic.jsf", so an EL exception is thrown when
> > > > JSF
> > > > > > > > fails to set the managed property.
> > > > > > > >
> > > > > > > > I've also tried adding a <h:inputHidden> tag set to the forumId on
> > > > the
> > > > > > > > backing bean in a variety of ways, but they leave much to be desired
> > > > > > > > as far as cleanliness.
> > > > > > > >
> > > > > > > > I'm sure that this is an issue every newbie JSF developer has
> > > > > > > > scratched his head over; so what's the best way to go about this?
> > > > I've
> > > > > > > > had a hard time finding anything in Google, mostly because I don't
> > > > > > > > know how to tersely phrase the problem for a seach query.
> > > > > > > >
> > > > > > > > Thanks a lot,
> > > > > > > > benjamin van der veen
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> >
>