Struts Jericho DTD

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

I've been looking at the current proposal for Strut's 2.0 config.  I think
it's a little too complex and the "extends" concept could be simplified
while gaining the same advantages as breaking your app into modules.

The struts config has many of a single element type of "mapping".  Mappings
would have a single attribute of URI and would run under the same rules as
the Servlet Filter Mapping.

<mapping uri="/*">
	<action execute="#{applicationController.validateLogin}" />
	<catch exception="com.mckesson.smo.AuthorizationException" />
	<form id="C" />
</mapping>

<mapping uri="/ordering/*">
	<bean id="orderController" class="com.mckesson.smo.OrderController"
scope="session">
		<property name="application">
			<value>#{applicationController}</value>
		</property>
	</bean>
	<action execute="#{orderController.validateUser}" />
	<catch exception="com.mckesson.smo.AuthorizationException" />
</mapping>

<mapping uri="/ordering/startOrder.jspx">
	<action execute="#{orderController.startOrder}" />
</mapping>


Mappings would be fired like filters and actions would/could be chained.
Child elements of the mapping element could be overridden then based on the
requested URI.

In the example above, the "/ordering/*" mapping would override the catch
from the "/*" mapping.  Also, actions would be executed in the order least
specific to most specific URI mapping.

ActionForwards could also be overridden also in this same manor to allow
generic mappings to look for a "badAuthorization" forward, but it can be
overridden in a more specific mapping.

The bean element would allow you to scope beans within
request|session|application, but also take care of cleaning up the beans
when they leave one of those mappings.  This could help with wizard type
flows where if the bean was of XXListenerType, it could receive create and
destroy events and enforce users to stick within a flow.

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

Thanks

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

Re: Struts Jericho DTD

["Craig R. McClanahan" <cr...@apache.org>]

Quoting Greg Reddin <gr...@fnf.com>:

> Ted Husted wrote:
> > On Fri, 12 Mar 2004 10:30:08 -0600, Hookom, Jacob wrote:
> > 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. 
> 
> I like this idea and would love to help.  I'm not highly experienced in 
> test-first design and think this would be a great way to get acclimated. 
>   Plus, I'm very interested in the Struts 2.0 approach.
> 

+1 on test-first.  We used that approach to build the JavaServer Faces RI, and
were basically able to keep up with a fairly rapid-fire set of changes as the
expert group evolved the design, while catching regressions before they turned
in to bugs.

I also need to catch back up on the recent design thinking for Struts futures
:-).

> Greg
>

Craig


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

Re: Struts Jericho DTD

[Greg Reddin <gr...@fnf.com>]

Ted Husted wrote:
> On Fri, 12 Mar 2004 10:30:08 -0600, Hookom, Jacob wrote:
> 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. 

I like this idea and would love to help.  I'm not highly experienced in 
test-first design and think this would be a great way to get acclimated. 
  Plus, I'm very interested in the Struts 2.0 approach.

Greg


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

Re: Struts Jericho DTD

[Ted Husted <hu...@apache.org>]

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