struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Jesse <alexander.je...@csfs.com>
Subject RE: Multi-App Struts App
Date Mon, 05 Nov 2001 09:17:53 GMT
Hi,

have you checked out Ted Husted's web-page (http://www.husted.com/struts/)? 
In one of his sub-pages (http://husted.com/about/scaffolding/catalog.htm) 
he describes a way to hierarchical organize actions  (search for 
"Organize ActionMappings into a command structure"). This might help you...

By the way: the catalog is usefull in all points...

hope this helps
Alexander

-----Original Message-----
From: mark@talios.com [mailto:mark@talios.com]
Sent: Monday, November 05, 2001 9:48 AM
To: struts-user@jakarta.apache.org
Subject: Multi-App Struts App


Hi, I'm currently working on a multi-(module|app) project using Struts, and 
was wondering the best way to structure it.  I know Struts doesn't  support 
multiple action servlets (or so I've read), so this is what I've currently 
got working:

I have 1 action servlet, and (currently) 4-5 Actions listed in 
struts-config.xml.  These Actions comprise of the top-level modules in the 
application.

Utilising multiple frames, I have a navigation frame that walks through the 
list of actions, building up a menu for the user to select which app they 
want.  This is all working quite nicely, each module has a corresponding 
directory in the jsp tree, so I have the following action/directory 
structure:

  /jtime/login.do (login/authentication module, this is where you start)
  /jtime/billing.do
  /jtime/summary.do
  /jtime/project.do

and

  /jtime/billing/default.jsp
  /jtime/summary/default.jsp
  /jtime/project/default.jsp

Now, because each of these modules, have there own little 
sub-module/sections, I was utilising what I used to do with normal CGI/PHP 
stuff, and pass in on the URL something like 
/jtime/billing.do?action=updateBillingEntry and in the Action I would have 
code like:

  if (request.getParameter("action").equals("updateBillingEntry")) {
    blah; blah;
  }

For some of the bigger modules, this leads to a large messy action handler, 
what I'm thinking of doing, is to break this down to sub actions, and have 
a custom super-action that looks up the action parameter, and passes it 
onto these sub ones.  So that I would have say:

  com.talios.billing.BillingAction
  com.talios.billing.actions.UpdateBillingEntry

As well as processing these actions, I have the "special" action called 
"getPage", which takes an additional parameter called "page" and for the 
request /jtime/billing?action=getPage&page=foo the action will return 
/jtime/billing/foo.jsp.  This will all be encompassed by this super-action 
class, that the developers working on the system won't actually modify.

Has anyone here done anything similiar?  Is it a good way to handle the 
problem?  Any pitfalls I might fall into?

Mark



--mark


--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>

--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message