Robert Douglass wrote:
This is an excerpt from my xwork.xml file? That's incredible. That's exactly what I want, and I think I've read posts from a few other people over the last months who were looking for just about the same thing. Is this in the Wiki?
Thanks,
Robert
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Pat Lightbody Sent: Thursday, September 25, 2003 7:10 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Hyperlink best practices - use of actions
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
------------------------------------------------------- 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
