You should be able to do:
<result name="success">browse.action?id=${product.id}</result>
This will cause the Ognl expression "product.id" to be evaluated and placed
in the URL. Is that what you want?
-Pat
----- Original Message -----
From: "Robert Douglass" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, September 23, 2003 7:53 AM
Subject: RE: [OS-webwork] Hyperlink best practices - use of actions
> This leads me to another question. What is the best way to implement the
> forwarding in the model that I described below. The url is formed by
> document id and template name, so completely dynamically. I've been using
a
> very bad hack where I put the url in the session and forward it to a .jsp
> called forwarder.jsp, which in turn pulls the url from the session and
> forwards. This isn't a very WW-like design, and I'm sure there must be a
> better way, but as far as I can tell, the redirect action built in is
> dependent on xwork.xml mappings, thus not dynamic (even if I use different
> aliases for the same action). My attempts to write my own forward.action
> have led to some interesting recursive messes, which is why I initially
gave
> up on the idea. Now I'm convinced it is what I want. Any advice?
>
> -Robert Douglass
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of
> Robert Douglass
> Sent: Tuesday, September 23, 2003 9:07 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [OS-webwork] Hyperlink best practices - use of actions
>
>
> The idea of the browse.action, given an id and a templateName, is that the
> getModel() method can do something like
> return dataBase.getDocument(id);
> and the forward could do something like
> forwardTo(documentType, templateName);
>
> One would then name the template files (vm or jsp)
> DocumentType_TemplateName.jsp, or by some other convention.
>
> browse.action?id=4711&template=homepage // if document 4711 is a user,
then
> this will lead to the user's homepage
> browse.action?id=4711&template=admin // this will lead to the
> administration page for that user (ostensibly off limits to that user as
> well!)
>
> Does anyone else use a pattern like this? What are the possible drawbacks?
>
> -Robert Douglass
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of
> Francisco Hernandez
> Sent: Tuesday, September 23, 2003 8:47 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [OS-webwork] Hyperlink best practices - use of actions
>
>
> this is how i've done it,
>
> homepage -> login -> homepage(with a welcome message to the user) ->
> viewProfile -> editProfile -> updateProfile -> viewProfile
>
> the *Profile actions can only be accessed if the user is logged in, if
> someone tries to access those pages and are not they just get sent to
> the homepage
>
> after a good login theres a redirect to the homepage action
>
> editProfile gets posted to updateProfile and then redirected back to
> viewProfile on success
>
> hope this helps, im not sure what your browse.action does though and how
> that would fit into my usage pattern for this
>
>
>
>
>
>
>
> Robert Douglass wrote:
> > I have another question on how people organize the navigation within
their
> > apps. First a use case:
> >
> > login -> homepage -> account details -> change password
> >
> >>From what I have understood so far, a typical WW application would have
> >
> > login.action -> homepage.action -> account.action -> and
changePass.action
> >
> > Each action would build up the context or offer a model in anticipation
of
> > the page to come. Homepage.action would offer a UserBean as a model, and
> > account.action would offer an AccountBean, or something similar.
Xork.xml
> > would specify that homepage.success = account.jsp, and homepage.login =
> > login.jsp. This is what I understand to be the typical approach from
> reading
> > the docs, examples and mailing list.
> >
> > To me, however, I tend to see the use case above as the following set of
> > actions:
> >
> > login.action, browse.action -> browse.action -> browse.action ->
> > changePass.action, browse.action
> >
> > login.action has no view, browse.success = some sort of forward,
> > changePass.success has no view.
> >
> > In other words, things like logging in and changing account details
always
> > chain to a browse.action. Browse.action would expect to receive at the
> > minimum an id of some sort and a template name of some sort, from which
it
> > would build a URL and redirect or forward the request to it.
> >
> > I haven't implemented this yet, as I'm still discovering the ins and
outs
> of
> > basic WW2 usage. The question is, though, does anybody else do business
> this
> > way? If so, how did you implement it?
> >
> > -Robert Douglass
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] Behalf Of
> > Robert Douglass
> > Sent: Tuesday, September 23, 2003 7:58 AM
> > To: [EMAIL PROTECTED]
> > Subject: [OS-webwork] Hyperlink best practices
> >
> >
> > Hello,
> > I'm looking for code examples of how people build their hyperlinks in
> > WW2/JSP view. The examples in the distribution don't really address
this,
> > and the ww:url tag seems to be more of an encoding helper than the
> beginning
> > of a solution to generating dynamic anchor tags. What I'd ideally like
is
> a
> > <ww:anchor> tag:
> >
> > <ww:anchor href="ognl.here" target="'_top'" encode="true|false">
> > <ww:param/>
> > </ww:anchor>
> >
> > I'm sure that this problem has been solved a hundred times and I just
> > haven't comprehended it yet.
> >
> > -Robert Douglass
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Opensymphony-webwork mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Opensymphony-webwork mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
> >
> >
> >
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Opensymphony-webwork mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Opensymphony-webwork mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Opensymphony-webwork mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
>
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
