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: [EMAIL PROTECTED] 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
