[Struts 2.0] RE: Struts Jericho DTD

["Hookom, Jacob" <Ja...@redline.mckhboc.com>]

One of the main drives for the model I'm describing is to remove the concept
of stateless actions and stateful form beans and combine the two.

I really like this concept:
http://today.java.net/pub/n/StrutsDelegate

And if we take the path of JSF, and remove the classification of an Action
Class and have an Action Method, then we can go through cycles like such:

<mapping uri="/ordering/resumeOrder.jsp">
  <bean id="resumeOrder" class="com.mckesson.smo.ResumeOrder"
scope="request">
    <property
name="orderController"><value>#{orderController}</value></property>
  </bean>
  <input id="orderId" update="#{resumeOrder.id}" value="#{param.orderId}"
alias="Order Id" required="true" />
  <action execute="#{resumeOrder.execute}" />
  <catch exception="com.mckesson.smo.OrderNotFoundException"
view-id="suspendedOrders" msg-id="error" />
  <view id="suspendedOrders" uri="/ordering/suspendedOrders.jsp"
redirect="true" />
</mapping>

Where our FormBean is now a POJO called ResumeOrder that has reference to
the OrderController, the properties of ResumeOrder get updated via "Input"
element definitions and finally to execute the transaction, we call
"resumeOrder.execute".

We can say an Action is a method fitting the following:
public void xxxxx()
public String xxxxx()
public String xxxxx(StrutsContext context)
public void xxxxx(StrutsContext context)

So in the Action element of the config, it would match any of the above
method signatures, if it returns a String, then set it as the view id.

More Random babblings.....

Thanks!


-----Original Message-----
From: Ted Husted [mailto:husted@apache.org] 
Sent: Sunday, March 14, 2004 8:45 PM
To: Struts Developers List
Subject: Re: Struts Jericho DTD

On Fri, 12 Mar 2004 10:30:08 -0600, Hookom, Jacob wrote:
> <mapping uri="/*">
> <action execute="#{applicationController.validateLogin}" /> <catch
> exception="com.mckesson.smo.AuthorizationException" /> <form id="C"
> /> </mapping>

This reminds me of the Maverick approach, which is both simple and
effective. 

> Just some ideas... I've been working on developing a mock version
> of this between projects at work.

What I would like to do is develop Struts 2.0 test-first. The idea being we
cold start with a simple application and write just enough of 2.0 to develop
the first page (or story). Then just enough to develop the second page, and
so forth. Each component developed would have to be fully testable outside
of a servlet/portlet/soap environment. 

Of  course, no one application can represent all of the use cases a
framework like Struts must support, so after an initial sample
application,we could start on the Struts Cookbook application Steve Raeburn
suggested. A very important point being that no feature would be added
without conventional unit tests and a working example use case. 

In doing this, I wouldn't feel constrained to anything we put on the
whiteboard, so we could try this or that in the context of working examples.


Right now, I'm refactoring the MailReader application in hope of using it as
the test-first foundation for Struts 2.0, and also exploring how other
frameworks are solving similar problems. 

-Ted.



---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org