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