struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Yu <j...@scioworks.com>
Subject Re: [Design Discussion] Multiple Controllers Per Web App
Date Sun, 06 Jan 2002 15:09:10 GMT
I have followed this thread for some time. I can finally collect some of my 
thoughts after the effect of all the New Year wines and champagnes have 
eventually died away. ;-)

This (multi-controller idea) definitely looks exciting and promising. It 
should solve the team development management issue most of us are currently 
facing.

However, let me play devil's advocate. I have these observations:

Stepping back and pondering on the proposed architecture, I can see it 
resembles the Servlet architecture: Multiple loadable "apps", context 
paths, default/root app, ActionServlet looks like a web container, Action 
looks like a servlet, struts-config.xml looks like web.xml...

The way I see it, to provide a proper, comprehensive and complete solution 
(a framework), one will end up with something like, as observed by Ted, 
Jetspeed or Websphere which overlaps significantly with the Servlet spec. 
(Remark: I don't have much experience with either software.) With the 
proposal, I can see Struts TNG is going down that path.

Let's put aside practicality. In an ideal world, does it make more sense if 
the Struts architecture *is* the Servlet architecture and vice versa? 
Should all the MVC mechanisms introduced by Struts be part of the Servlet 
spec? Could Servlet 3.0 (or whatever version) absorb Struts?

Sorry that this is a far cry from the original intention of the discussion. 
But I feel a bit unsure and uneasy seeing that we're building a 
partitioning framework on the top of an existing partitioning framework 
with significant duplications...

-- 
John Yu                       Scioworks Technologies
e: john@scioworks.com         w: +(65) 873 5989
w: http://www.scioworks.com m: +(65) 9782 9610

Scioworks Camino - "Rapid WebApp Assembly for Struts"


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


Mime
View raw message