RE: Action question
-Original Message- From: Travis Chase [mailto:[EMAIL PROTECTED]] Ok last question I promise. I have been going through the code and I see where almost everything is being done. The only thing I still am having trouble with is if the Digester loads the ActionMapping objects and the RequestProcessor loads the Action objects, how does the Action object get at the dynamic properties set in the set-property element of the action element? I would think either the ActionMapping object would have to have a collection of the properties for the Action to query or someone would have to set the properties on the extended Action object. Is this correct? Where am I missing the tie between? Thank you for being patient and answering my questions. Great framework! The action element in struts-config.xml actually represents an ActionMapping object, in a rather confusing turn of events. So the ActionMapping instance is the one that can have properties set on it. Action instances do not exist when the Digester plows through struts-config.xml. A property in this case is basically a Javabean property. So if you do a set-property of name, then if your ActionMapping subclass has a public void setName(String) method on it, it will be called. Hope this helps, Laird -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Action question
-Original Message- From: Travis Chase [mailto:[EMAIL PROTECTED]] A Thank you. I am such a moron. No, you're not; it's not a very well-named element and causes lots of people lots of problems. The good (or bad!) news is you'll probably now edit your struts-config.xml file and forget all about it. :-) Laird -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Passing parameters with mapping.findforward
-Original Message- From: Rajendra Yadav [mailto:[EMAIL PROTECTED]] How do we pass parameters from one jsp to another using the Struts framework. Nothing to do with Struts. See the Servlet API. http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/ServletRequest.h tml#setAttribute(java.lang.String, java.lang.Object) HTH, Laird -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [OT] Re: Why are people are up on Struts
-Original Message- From: Jason Rosenblum [mailto:[EMAIL PROTECTED]] how do you people live without the refactoring tools provided by IDEs like Eclipse and IntelliJ? We type fast. :-) No, but seriously: I'm stupid enough that if I don't do the refactoring myself, laborious line by line, I lose track of what's happening. Cheers, Laird -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Action chaining
-Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] So, if we're talking about one ActionMapping forwarding (or redirecting) to another ActionMapping, then sure. Everything is above board, and you can follow the bouncing ball through the Struts Config and see what's happening. Ah, that's what I use. I think. That is, if I'm going to cause two different Actions' perform() methods to be invoked during the same browser request, then I always do it via a mapping.findForward(XYZ) call instead of a new ActionForward(someComputedString) call. But, then there's Action chaining. Here, people have an Action class create an ActionForward on the fly, jam in some parameters, and toss it back to the controller. This is where Action classes start binding to Action classes, and the mudslide begins. Agreed. Mudslides are kind of tasty, though. It's my feeling that if Action classes start creating query strings and need to be coded in terms of what they need to send to the next Action, then you're starting to use Action classes to implement a business facade. Action classes should be clients of the facade, not the facade itself. One variation on this that I don't think suffers from the same problems is to do something like: // Work has completed by this point, let's say. request.setAttribute(resultOfWork); return mapping.findForward(DONE); ...where the next Action selected by the ActionMapping may very well be expecting resultOfWork to be present as a request attribute for presentation/UI-layer purposes only. That is, the semantics of putting resultOfWork into the request must not require that there be a next Action--it's just something this Action has to do, regardless of whether someone else down the line consumes it or not. In the current example, using an ActionMapping to call a DeleteAction and have it route back to some list afterwards seems fine to me. So, long as the DeleteAction doesn't know or care if its going back to a particular list or a given form. IMHO, an Action class should just return a simple semantic like success, failure, cancel, and so forth, and let the ActionMapping decide how to handle the given gesture. Right; Actions are web GUI EventListeners. The difference between this (and lots of other web-centric) event handling system and the Java beans event handling system is that the event type is basically the same: you get a request event that has a logical hashtable in it of parameters and values, and an identifier (the path) that tells you what kind of event it is. And following Laird's example, an application could also include a workflow engine that would return a semantic to go get the whatchacallit. But the ActionMappings would hook up the semantic with the actual URI. The real presentation logic is that there's a JSP stored at /WEB-INF/pages/whatchacallit. On top of that, there's application/workflow logic that might say the semantic whatchamcallit should display the form that collects the whatchallit property. Minor quibble: in my mind, the *application* doesn't say to display anything. The presentation layer, which for these purposes I'm separating from the application, does. I only make this point because to me what you're calling the application workflow is really a property of the GUI/presentation layer, not the application. From my previous example, the application domain/business logic domain begins when the frobnicate() method is called, and ends once it returns. All the machinery to gather the requisite parameters and to render the response is presentation logic. Call it workflow if you must, but it's not workflow that's essential to the task (that of frobnication :-)) at hand. Where things get messy is that sometimes people come up with a multi-step server-side workflow, where they want to, say, copy and delete (or move) a record, and then return to a list. So you got the copy action looking at some flag that says do delete next, and so it sets something in the request or action form, and forwards on to delete, which then looks at something that tells it to forward on to a list. You must have been looking at some of the code that I'm currently forced to maintain. :-) The business facade is your application's internal API. It defines what the application can do, what it needs to do it, and what it returns when something is done. The Action classes interact with the business facade by allowing access to the facade from the web tier. Other tiers could also interact with the same facade from other platforms. Yes, exactly. One of the things I was trying to articulate (badly) in an earlier message was that if you do this right, you can swap out GUIs at configuration time. The way that I'm currently trying to do this is by approaching application design from an event perspective (what events should any GUI for this application be expected to fire to the
RE: [OT] Re: Why are people are up on Struts
-Original Message- From: Phase Web and Multimedia [mailto:[EMAIL PROTECTED]] Wow, are guys geezers? vi!? emacs!? I just use my ssh secure shell by ssh.com and use the file browser to locate the file and edit it locally then when i click save it conveniently loads it back on the server all snug and secure. But if you are working on terminal system I guess you are stuck. But, who is working on pure terminal systems for development these days? I would be interested to know. You need not be working on a terminal system to use emacs. I use the Windows version of emacs on every contract I get, following the advice of the authors of The Pragmatic Programmer, who advise you to pick one cross-platform editor and learn it well, to the exclusion of all other editors/IDEs if necessary. Cheers, Laird -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Action chaining: (was - Re: Why are people up on Struts)
-Original Message- From: Erik Hatcher [mailto:[EMAIL PROTECTED]] There is no question that there are issues with forwarding with form population and such [...] I'm sure it just flew by me in all the email, but where can I look to see what these issues are? Any good search terms to use on the archives? Cheers, Laird -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: RE: servletMapping field in ActionServlet (1.0.2) (long)
-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED]]
IMHO, the best way to use XML is as a generator/decorator for
objects. One decoration might be to pass a script to a Java class
for processing, but framing conditions in a XML files seems to
step over the line to me.
Fair enough. My real goal is to separate
Right now, a very good way to test preconditions is through a
component like the Struts validator. It plugs into the ActionForm
and confirms that whatever properties are needed are ready,
willing and agle to go.
I'll take a look (we're in 1.0.2 land at the moment, and I wasn't aware that
the validator worked with it).
In the normal course, an Action should not need to interact with
the request or session at all. The ActionForm should encapsulate
whatever input is needed.
How does the ActionForm work with Cookies? Ancient, legacy systems that
maintain their own notion of session state? I thought ActionForms only work
with request parameters, request attributes and session attributes.
The routing instructions in Struts are the ActionForwards. The
Actions can select a destiation using a logical name, and that
name is mapped to a destination in the configuration.
Yeah, but that's only part of the equation. To me, how actions choose
*which **logical** name to use* is routing logic as well, right? Surely the
simple hashtable lookup that happens with a mapping.findForward() does not
itself wholly constitute all of Struts routing logic!
Here's a situation we run into all the time:
1. URL /a/b/c comes in.
2. Struts routes that to RedirectorAction using its normal features, i.e.
struts-config.xml, ActionMappings, ActionForms, etc.
3. ROUTING LOGIC: RedirectorAction makes connection to Big Hairy Nasty Old
Legacy System to get Magic Flag. If Magic Flag is QRC@43, then return
mapping.findForward(condition1); if Magic Flag is 7#5%FFX AND Obscure
Cookie Foobar is set to 87YYX, then return
mapping.findForward(condition2); else return
mapping.findForward(defaultCondition)
(Note that the ActionForward returned for mapping.findForward(condition1),
etc. is not a JSP page or another view component, but another controller
component (usually another Action in the same webapp)).
We have Actions all over the place that do some variation on (3). Note that
this hypothetical RedirectorAction never invokes business objects--it's just
a rules engine that augments Struts' existing routing logic, since /a/b/c
is not enough on its own--even with its associated ActionForm--to uniquely
select the proper destination. So all I'd like to do is move this kind of
rules engine stuff up into Struts' *existing* rules engine stuff--the
ActionMapping class, or at least its XML representation--so that all the
rules engine processing (Struts' native if path ends with '/a/b/c then
invoke ActionX and ActionX's if Magic Flag is 'QRC@43', then return
mapping.findForward('conditional')) is in the same place. Whether that's
in an XML file, a separate configuration file, a BSF script, etc. doesn't
matter to me.
Cheers,
Laird
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [Unverified Sender] RE: RE: servletMapping field in ActionServlet (1.0.2) (long)
-Original Message- From: Nelson, Laird [mailto:[EMAIL PROTECTED]] -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] IMHO, the best way to use XML is as a generator/decorator for objects. One decoration might be to pass a script to a Java class for processing, but framing conditions in a XML files seems to step over the line to me. Fair enough. My real goal is to separate ...my brain from my fingers! I think I've succeeded. Ahem. ...to separate routing logic and precondition validation from operations on the model tier. Cheers, Laird -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: RE: servletMapping field in ActionServlet (1.0.2)
-Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] 11/22/2002 1:26:45 PM, Nelson, Laird [EMAIL PROTECTED] wrote: Is my company unique in trying to do things this way? Probably not, but Struts hasn't been trying to be all things to all people. =:0) It does what the people working on it need it to do, and if it doesn't do what we need, then we work to change it. But we're not sitting around a whiteboard trying to figure out the best way to capture market share. (Sorry; my previous message wasn't intended to be whiny. I just wondered whether what we were doing warranted my digging further or if I should just let Struts be and keep our patches in house. It sounds like the multiple-servlet-mapping thing that we're doing to keep our reporting folks happy is fairly unique and nasty.) Struts does restrict what URIs you can map to an Action. The underlying issue, as Craig pointed out, is that the Action path is not a truly logical identifier. It's a hash based on the URI that Struts munged and demunges. Isn't it just pathinfo (in the case of prefix mapping, not extension mapping)? Or is there a section of the code besides processPath() I should be looking at? There are of course other ways we could link up actions and URIs, but that would be something we'd explore in the Struts 2.0 frame. One thing I was looking at on an earlier project was setting up the action mappings section of the struts-config.xml file to be able to switch not only off of URL fragments like pathinfo but also the presence or absence of certain attributes in various scopes. Interestingly, of course, Struts offers XML tags that test for the presence or absence of such attributes--wouldn't it be twisted and awful and cool to use those tags in the action-mappings section? So you could say (warning; unchecked syntax but you get the idea): action-mappings logic:present name=loggedIn scope=session action ... / /logic /action-mappings Anyway, just brainstorming. Thanks as always for your (and Craig's) time and input. Cheers, Laird (at work on a Saturday :-( ) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
servletMapping field in ActionServlet (1.0.2)
Hi; I'm looking at the v1.0.2 ActionServlet's addServletMapping() method, and I'm noticing that it only handles the case where the ActionServlet has one servlet mapping associated with it. But it's legal (is it not?) to establish several servlet mappings for a Servlet under the 2.2 spec, right? In our case, we have an ActionServlet that is currently set up to handle several different paths. These paths are not really important to the Actions per se, but (depending on various factors) may be important for reporting purposes (i.e. did the person get into the website via path A, path B or path C, even though all will route him to ActionA). The Form tag seems to be the only Struts tag that uses the servletMapping attribute. Because the addServletMapping() method only ever takes the last mapping it finds, it will always look (if I'm reading the code right) like all requests that make use of the Form tag were submitted to path C. Is there a simple workaround for this, or should I look into submitting a patch? Or should I just not worry about it? :-) Thanks kindly and happy Friday. Laird -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: servletMapping field in ActionServlet (1.0.2)
-Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Struts currently does not know how to reliably compute URLs for things like html:form in the face of more than one mapping. OK. A subtle point needs to be remembered -- from the client viewpoint, the URL you *submit* to (i.e. the action) is what shows in the Location bar on a browser. Since the Action that is invoked can return an ActionForward to *any* page, the same URL can literally display anything. This applies to any scenario that uses RequestDispatcher.forward(), not just to Struts. Right. The reporting folks unfortunately have always attached--and continue to attach--great significance to said URL. We have grumbled and gotten around this problem by logging the page that is forwarded to as the request processing completes (in processActionForward() if I remember correctly). Not pretty, but satisfies the twin demons of architectural correctness on the one hand (what you are espousing here and what I agree with) and but-we've-already-firmed-up-the-URLs-and-this-is-how-it's-always-worked reporting requirements on the other. More fundamentally, then, I would contend that the absolute value of a URL is totally meaningless in a web application based on an MVC architecture that uses RD.forward() the way Struts uses it. I agree wholesale with you. That does not change the fact that unfortunately old habits die hard, especially where reporting and URL analysis is concerned. :-( Web Applications != Web Sites Agreed. There is not going to be a useful workaround for this -- it's fundamental to the nature of the architecture. OK. So not even an extra optional attribute on the form tag somewhere (Use servletPath X instead of servletPath Y), bearing in mind the limitations of our current reporting requirements? Is my company unique in trying to do things this way? Thanks for your time and help. Laird -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [Unverified Sender] RE: servletMapping field in ActionServlet (1.0.2)
-Original Message-
From: Nelson, Laird [mailto:[EMAIL PROTECTED]]
OK. So not even an extra optional attribute on the form tag
somewhere (Use
servletPath X instead of servletPath Y), bearing in mind the
limitations of
our current reporting requirements?
Following up my own message: or how about simply using the servlet path
instead of the servlet mapping when you're not using extension mapping?
Something like this (starting at line 713 in ...taglib.html.FormTag in the
getActionMappingURL() method; I changed the final else block as follows):
if (servletMapping.startsWith(*.)) {
value.append(actionMapping);
value.append(servletMapping.substring(1));
} else {
// In the case of path mapping, just use the servlet path,
// since we are guaranteed by the 2.2 spec that it will reflect
// the correct servlet mapping
value.append(pageContext.getRequest().getServletPath());
value.append(actionMapping);
}
(Warning: code is untested, but you get the idea.)
The basic gist is that if path mapping is in effect, use the servlet path
instead, because the servlet 2.2 specification, section 5.4, guarantees that
the servlet path will be what you want. Or, another way to put it is that
the servlet mapping is only really important when it's extension mapping, as
far as I can tell, since the servlet path will otherwise give you what you
want.
Cheers,
Laird
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
