On 5/1/06, Andrew Robinson <[EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]>:
> > > > > 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 < [EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> >
>

Reply via email to