Re: [s1] ActionContext in execute()?
Niall Pemberton wrote: Better IMO to move from Action's to Commands rather than putting the Command into the Action - also Commons Chain has a DispatchCommand: http://tinyurl.com/38j7vk Niall Thanks Niall. After going out to dinner, I decided against my own idea. This would be a 3rd form of dispatching in the Struts universe. I would prefer actually to make it look identical to the Struts 2 signature: public void execute() throws Exception Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s1] ActionContext in execute()?
On 3/19/07, Paul Benedict <[EMAIL PROTECTED]> wrote:
I tried this out tonight, and I thought it was very beneficial to
cleaning up my code. In particular, not having to declare parameters
that I do not need to use.
public void execute(ActionContext context) throws Exception {
}
Steps for development:
1) Add this method signature to Action
2) Would then dispatch to a like signature but of ServletActionContext
3) #2 method would, by default, dispatch to the typical parameter version.
This also allows some interesting dispatching. I can also write a
dispatcher that dispatches according to this method signature. I really
like it the idea.
Better IMO to move from Action's to Commands rather than putting the
Command into the Action - also Commons Chain has a DispatchCommand:
http://tinyurl.com/38j7vk
Niall
+1. Anyone against it?
Paul
Ted Husted wrote:
> Yes, doing this was on the old 1.4 roadmap.
>
> On 3/7/07, Joe Germuska <[EMAIL PROTECTED]> wrote:
>> We talked about this at some length when the ActionContext was first
>> introduced. We also talked about having the base action implement
>> ActionCommand and/or some other options.
>>
>> I think the only reason we didn't do it then was because it was still
>> new,
>> and we thought we'd let it settle in for a while. In fact, the idea you
>> suggest may at one point have been on the roadmap for 1.4.
>>
>> Joe
>>
>> On 3/7/07, Paul Benedict <[EMAIL PROTECTED]> wrote:
>> >
>> > Just gathering some opinions here...
>> >
>> > Would it be preferable to accept an ActionContext in execute() rather
>> > than the 4 parameters?
>> >
>> > public ActionForward execute(ActionContext context) throws Exception;
>> >
>> > Thanks,
>> > Paul
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s1] ActionContext in execute()?
I tried this out tonight, and I thought it was very beneficial to
cleaning up my code. In particular, not having to declare parameters
that I do not need to use.
public void execute(ActionContext context) throws Exception {
}
Steps for development:
1) Add this method signature to Action
2) Would then dispatch to a like signature but of ServletActionContext
3) #2 method would, by default, dispatch to the typical parameter version.
This also allows some interesting dispatching. I can also write a
dispatcher that dispatches according to this method signature. I really
like it the idea.
+1. Anyone against it?
Paul
Ted Husted wrote:
Yes, doing this was on the old 1.4 roadmap.
On 3/7/07, Joe Germuska <[EMAIL PROTECTED]> wrote:
We talked about this at some length when the ActionContext was first
introduced. We also talked about having the base action implement
ActionCommand and/or some other options.
I think the only reason we didn't do it then was because it was still
new,
and we thought we'd let it settle in for a while. In fact, the idea you
suggest may at one point have been on the roadmap for 1.4.
Joe
On 3/7/07, Paul Benedict <[EMAIL PROTECTED]> wrote:
>
> Just gathering some opinions here...
>
> Would it be preferable to accept an ActionContext in execute() rather
> than the 4 parameters?
>
> public ActionForward execute(ActionContext context) throws Exception;
>
> Thanks,
> Paul
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Using Struts Validator framework
Hi, I am using Struts Validator framework and DynaActionForm for performing form data validations. The user input is taken and then corresponding record is fetched from the database. Depending on the query result, I need to display appropriate message to the user. How can I achieve this ? It will be of great help if you can provide me some related sample code. Thanks in advance for your help. Anubhav, India. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
missing default-class-ref in struts-2.0.dtd
Hi, i am using struts 2.0.6 and i noticed that in struts-2.0.dtd the element [code] default-class-ref [/code] is missing but in xwork-2.0.dtd this element is there Thanks & BR - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=71371&messageID=133472#133472 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven 2: Release Profile
The Maven 2 Super POM has a pre-installed profile identified as "release-profile", which packages the source and javadocs. I know we have this thing built into our own Struts POM, but you should know it's not needed. You can enable the pre-installed profile with parameter -DperformRelease=true You can find this all in the super POM in your maven-project-2.0.X.jar in file pom-4.0.0.xml Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Unittest - catch 22
Hi I have setup a local developer environment for Struts2 and clover to report on the unit tests. When the unit tests are executed they are setup to only log at WARN level (log4j.properties in core/test/resources folder). In clover there are some log output at DEBUG level that are not tested and I changed the log4j.properties to include this line: # set to lowest debug level to also execute debug code during unit testing to ensure it works also log4j.logger.org.apache.struts2=TRACE Now we have tests failing since some of the unit tests are using easymock or jmock and the predictions are now screwed due a different log4j level. What's the S2 developers point of view on this? Should we assume that debug logging just works and thus run unit tests at current WARN level? The current unit tests are failing since we are debugging some more info at DEBUG level at thus calls some methods that jmock did not expect. My own point is that the current unit tests are correct and that in an ideal world jmock would not fail just because we log some debug information. But it would be nice to run unit tests at TRACE level to run through all the code as possible. [surefire] Running org.apache.struts2.portlet.PortletRequestMapTest [surefire] Tests run: 6, Failures: 5, Errors: 0, Time elapsed: 0,016 sec FAILURE !! org.jmock.core.DynamicMockError: testPut: no match found Invoked: javax.portlet.PortletRequest.getParameterMap() Allowed: expected once: setAttribute( eq(), eq() ), is void expected once: getAttribute( eq() ), returns at org.jmock.core.AbstractDynamicMock.mockInvocation(Unknown Source) at org.jmock.core.CoreMock.invoke(Unknown Source) at $Proxy34.getParameterMap(Unknown Source) at org.apache.struts2.portlet.PortletRequestMap.(PortletRequestMap.java:54) at org.apache.struts2.portlet.PortletRequestMapTest.testPut(PortletRequestMapTest.java:64) - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=71345&messageID=133427#133427 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
