My personal feeling (as primary author of Struts) is that I only care about supporting Struts on J2EE-compatible platforms (currently J2EE 1.3), or on a web container supporting Servlet 2.2 and JSP 1.1 if you don't need EJBs directly. I'm not at all interested in supporting bastardized versions -- although BroadVision (or anyone else) is of course free to fork it and maintain their own copy.
If BroadVision doesn't support the standard capabilities of Servlet 2.2 and JSP 1.1 so that standard Struts runs on it, I wouldn't ever willingly use it for anything. It's not just Struts and all of the innovation there that you give up -- you also give up the ability to utilize any other technology based on standard servlet and JSP APIs. You're basically stuck with a proprietary infrastructure that is going to get increasingly farther from the future standards of J2EE. If unmodified Struts will run on BroadVision and they still prefer a "roll your own" MVC framework -- well, everyone likes to recommend what they are familiar with. You might find yourself though, being one of the many people who started down the road of building their own framework and coming back to Struts because it was costing too much effort that was spent on the framework instead of the application :-). Craig McClanahan On Sat, 10 Nov 2001, Sandeep Takhar wrote: > Date: Sat, 10 Nov 2001 07:36:36 -0800 (PST) > From: Sandeep Takhar <[EMAIL PROTECTED]> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > To: Struts Mailing List <[EMAIL PROTECTED]> > Subject: architecture question > > hello! need your help again... > > The bank I work at has semi-finalized it's plans for > employee facing and customer facing applications. The > problem I am having is for customer facing > applications. The application is the banks main > customer web site. This web site will be maintained > by many different groups, each group having a link > from the home page. Also note that since this web > site will go a long way towards promising what our > current CEO wants -- there are a lot of groups and a > lot of "important" people affected by any > architectural decision, which means that any change to > a recommendation will have to be clearly justified and > better work properly. > > The problem stems from the architecture to use when > there are all these different groups. > > We hired some expensive consultants and what they > recommended was as follows: > > The bank is already decided to use Broadvision so they > have not told us to use anything different than this > for the servlet container and the 1:1 > publishing/content management. WebLogic will be used > for EJB's. Because of the many different groups and > because they are rolling out with 5.5 of broadvision > (which does not contain any J2EE services yet) and > also because of the "update" problem associated with > having many different groups maintaining their own > code they recommended: Use J2EE framework with the > different tiers and specifically a MVC Model II > approach for the web-tier. Because of the > "bastardized" version of Struts and some particular > problem of Broadvision needing the session (not sure > how) -- they don't recommend going with Struts, but > have recommended "including a servlet in a jsp" where > the servlet acts identically to an "action" class > where it redirects to the appropriate page. I believe > there is a also a strong use of web-services. > > So if you followed all of that, here is my dilemna: > While I understand the need to set up an environment > for maintenance with the "common denominator" approach > -- the recommendation does not do anything towards > addressing my concerns about reusability. The reason > why I like Struts and all the add-ons is all the > common problems solved. The recommendation we have > been given implies that we need to solve all the > common problems and re-invent a new framework and I am > not happy about that. The approach would be -- solve > your problem in your own groups common area and then > have meetings with a steering committee to discuss the > use of this framework for everyone. > > The arguments that I have been given about not using > Struts include Broadvision's bastardized version of > Struts, maintenance of code when something goes wrong > with the main web site -- i.e. the user maintaining it > will have to be a bit more savvy and understand struts > and not just J2EE. Updating one part of the web-site > will become a problem because all of the groups may be > impacted. (Actually if we use Struts -- the jar file > cannot be held in common for all the web applications > and there will be one necessary for each > application?). As the years go by Struts may be > outdated? (the architect implied this). > > My own take on it: I understand the issues raised > above and feel that it will be very hard to > standardize on a framework like Struts. For our own > group however -- we will either use the "bastardized" > version or will "copy and paste" large parts of struts > code to get the features we want. Also, if we each > eventually agree to a framework -- than the same > problems as mentioned above will be found anyways? > > Hopefully you understand what I am trying to say. > What would you do? > > Sandeep > > > > > > __________________________________________________ > Do You Yahoo!? > Find a job, post your resume. > http://careers.yahoo.com > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
