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