Hi, Rick,
WITHIN:
Rick Reumann wrote:
In the beginning of this application I assumed the client would always
want to see all users so I created a MappingDispatchAction method (or
regular DispatchAction method) called getUsers(...) which returned a
list of all users in the company and put them
Well documented:) I'm going to try using SimpleDispatchAction starting
today and see how it goes. I'll e-mail you off list with any questions.
Thanks again.
Michael McGrady wrote the following on 9/15/2004 2:54 AM:
Hi, Rick,
WITHIN:
Rick Reumann wrote:
In the beginning of this application I
Well, if you look at this line:
newAction = 'html:rewrite page=/'+action+'.do/';
It looks like JavaScript is being used to generate an
html:rewrite/.
I read this as trying to use html:rewrite/ to generate JavaScript.
Considering that action was a parameter passed to a javascript
Don't worry, David, this is a list for exchanging ideas. Yours are
appreciated.
However, I think you are mistaken in this instance. I am fairly sure
that is the case, since this code has been run and works.
Please correct me if I am wrong, but I think that you think that somehow
the
Please correct me if I am wrong, but I think that you think that
somehow
the html:rewrite page=/'+action+'.do/ is going to show up in the
response object and be present in the JavaScript on the page, which
would be bad. However, that is not the case. What shows up on the
page
is the result
Rick and David,
DAVID
I cannot see what you are getting at, David. What is the problem? I
ran your code without incident. I assume that the result is what Rick
wants. Please state what you think the problem is. Apparently you
don't think the problem is JavaScript will have to run taglib
I'm guessing David's getting at how to properly construct a request-time value
for a tag attribute. If you're using a scripting expression, everything must be
contained within %= and %. If you're using an EL-enabled tag, then you
can do something like: /${action}.do (assuming action is a scoped
Kris Schneider wrote:
I'm guessing David's getting at how to properly construct a request-time value
for a tag attribute. If you're using a scripting expression, everything must be
contained within %= and %. If you're using an EL-enabled tag, then you
can do something like: /${action}.do (assuming
You mean the thing that starts html:rewrite is actually JavaScript? Could've
fooled me! ;-) Tags like html:rewrite and c:url are great for generating
URLs to be used by JavaScript code that needs to interact with web apps. One of
the reasons they're so useful is that they have built-in support for
Kris Schneider wrote:
You mean the thing that starts html:rewrite is actually JavaScript? Could've
fooled me! ;-) Tags like html:rewrite and c:url are great for generating
URLs to be used by JavaScript code that needs to interact with web apps. One of
the reasons they're so useful is that they
Durham David Contr 805 CSPTS/SCE wrote the following on 9/14/2004 1:31 PM:
I tested the code -- not that I needed to do so, but still.
I'm sure you didn't need to test it Oh almighty coding God.
Just throw it into a JSP and look at the resulting HTML.
Here's an index.jsp that I've ran in Tomcat
Michael McGrady wrote the following on 9/14/2004 2:26 PM:
Any way, I have something else on this. Rick, I have written a class I
call SimpleDispatchAction which allows you to use links, submits, and
images with the same code without involving struts-config.xml in the
process. I put it up at
Oh I definitely think it's more than okay to use tags to help generate
JavaScript. In fact, using server-side code to generate client-side code
is a telltale sign of a very seasoned and very respected developer ;-).
The only reason I jumped in at all (and yes, it was late, sorry if I
missed
Rick Reumann wrote:
Hey, yes that is pretty cool.
Hi, Rick,
Your notes on links confuse me a bit. Let me consider what confuses me
and then we can go from there.
FIRST
You said . . . MappingDispatchAction has . . . a cetnralized place to
decide what method is called based on the action
Ooops, Rick! I made an error speeding on this. Let me work on it and
get back to you later.
Michael
Michael McGrady wrote:
Rick Reumann wrote:
Hey, yes that is pretty cool.
Hi, Rick,
Your notes on links confuse me a bit. Let me consider what confuses
me and then we can go from there.
FIRST
Michael McGrady wrote:
Ooops, Rick!
I de-ooopsed the situation by adding
if(methodName == null) {
String parameter = mapping.getParameter();
if(parameter.endsWith(.x)) {
methodName =
buttonValue.substring(0,buttonValue.indexOf('.'));
}
Michael McGrady wrote the following on 9/14/2004 11:04 PM:
Your notes on links confuse me a bit. Let me consider what confuses me
and then we can go from there.
FIRST
You said . . . MappingDispatchAction has . . . a cetnralized place to
decide what method is called based on the action name. I
Hi Michael. I'm replying to his quickly before I run into work so I
might not have looked these approaches over enough but here are my first
impressions.
First I'd like to point out that I like to keep an application as
consistent as possible. That means that I like my links, my form
submits,
SEE WITHIN:
Michael McGrady
Rick Reumann wrote:
I hope you have a bit of time to discuss this in detail, Rick, because
the amount of activity in this area is huge. I think this is one of
those areas, along with looking for persistence not identical to the
normal scopes, where there is
(not commenting below, just up top on this)
In reference to your first comment:
I think that what appears to be a model emphasis for the
solution in your [rick's] approach is bound to fail. Further, making
the
solution view based frees the model to be built for performance, which
is why I
function swapAction( formName, action) {
formAction = document.getElementById( formName ).action;
newAction = 'html:rewrite page=/'+action+'.do/';
I don't think this will work, and I find it ironic that you literally
mixed client-side and server-side scripting.
Still, I see what
I am enjoying the discussion as well.
I can see that your schedule and my attempting to say too much are
confusing things. Let me also clarify a couple things so we are clear
what we each are saying. Then I will address the bigger issues.
The following class works fine:
public abstract
Durham David Contr 805 CSPTS/SCE wrote:
function swapAction( formName, action) {
formAction = document.getElementById( formName ).action;
newAction = 'html:rewrite page=/'+action+'.do/';
I don't think this will work, and I find it ironic that you literally
mixed client-side and
Some comments below...
Michael McGrady wrote the following on 9/13/2004 5:40 PM:
The following class works fine:
public abstract class CrackWillowLookupDispatchAction
extends DispatchAction {
public ActionForward execute(
ActionMapping mapping,
ActionForm form,
From: Michael McGrady [mailto:[EMAIL PROTECTED]
Why don't you think this will work, Dave? Why would the serverside
script care that there was client side script? This looks okay to me.
Well, if you look at this line:
newAction = 'html:rewrite page=/'+action+'.do/';
It looks like
Durham David Contr 805 CSPTS/SCE wrote the following on 9/13/2004 3:13 PM:
function swapAction( formName, action) {
formAction = document.getElementById( formName ).action;
newAction = 'html:rewrite page=/'+action+'.do/';
I don't think this will work, and I find it ironic that you
It works fine and it's not a 'true' mix of server-side scripting. I
could avoid the use of the html:rewrite
Considering that you passed the action to be re-written to a
JavaScript function, yeah it's a true mix. :)
but didn't want to hardcode
the context name. I could do away with that
Durham David Contr 805 CSPTS/SCE wrote:
From: Michael McGrady [mailto:[EMAIL PROTECTED]
Why don't you think this will work, Dave? Why would the serverside
script care that there was client side script? This looks okay to me.
Well, if you look at this line:
newAction = 'html:rewrite
Rick Reumann wrote:
Some comments below...
Michael McGrady wrote the following on 9/13/2004 5:40 PM:
Thanks for your comments below. It has helped clarify things. Your
approach is pretty nice but in the above how would you be able to use
this same Action for regular links? It seems like you have
Rick Reumann wrote:
Some comments below...
Michael McGrady wrote the following on 9/13/2004 5:40 PM:
Yes, that is a slight benefit (which is the same benefit of using the
regular DispatchAction), however, the slight cost of having to rely on
the struts-config for deciding what dispatch method is
Hoping this comes out better:
Rick Generic Action Solution
link--|
|
image---|--- to updateFooBar.do of some GenericAction class.
|
submit--|
Michael Generic Taglib Solution
link|
| A: Solution Facade Interface:
image---|
Last try. Sorry about the noise:Rick Generic Action Solution
link|
|
image---|--- to updateFooBar.do of some GenericAction class.
|
submit--|
Michael Generic Taglib Solution
link|
| A: Solution Facade Interface:
image---| facase: link, image,
Not sure which list this question/topic really belongs on so posting to
both. (I'm bringing it up on the dev list because I'm thinking maybe the
base MappingDispatchAction could/should be modified).
Some design background. I like to keep related tasks belonging in one
Dispatch Action class
33 matches
Mail list logo
