One thing I thought of, but didn't mention is that your TaskActions seems to remind me of scaffolding which has Business Helper Beans which are auto-created based on action-mapping parameter attribute and they do the work of accessing business logic.
So in case you were wondering if struts has this sort of functionality... thanks for the insight... It seems like Craig and others are positioning struts to still handle what you mentioned. I haven't looked in depth into faces, but it would seem like a good time to do so... sandeep --- Ranko Bijelonic <[EMAIL PROTECTED]> wrote: > yes, Java Server Faces provides a different > programing model from that of > Struts. Its also an MVC framework, but is more Swing > like (or ASP.NET like > :)). This kind of programing might win over a lots > of developers. But in > "map a request to a handler a dispatch the request > to it" point of view, we > still have Struts and the servlet container itself > :). > > -----Original Message----- > From: Sandeep Takhar > [mailto:[EMAIL PROTECTED] > Sent: Monday, July 21, 2003 2:39 PM > To: Struts Users Mailing List > Subject: RE: Struts MVC framework similar to that of > a servlet > container? > > > If you've built it already, then you've defeated > part > of the purpose of adopting it, but not all. > > I don't understand when you say you want to re-write > the servlet spec. > > Maybe you meant, why isn't it in the servlet spec? > > Java Server Faces may very well replace (now I'm in > trouble...) struts in the long run. And this is a > standard. > > Struts addresses a shortcoming and continues to do > so. > > sandeep > --- Ranko Bijelonic <[EMAIL PROTECTED]> wrote: > > ok. assume i go through the process below. now i > > have RANKo framework :) > > (which I did actually). Then I learn about Struts > > and say, hey this serves > > the same function as my framework, let me switch > to > > that cause everybody > > uses that so its standardized in some way. Then, > > some time later you > > realize (perhaps wrongly) that it duplicates a lot > > of servlet container > > functionality and that the MVC part of this > > framework is already there. > > That's why I'm asking myself how is writing a > > Servlet different from writing > > an Action. For every Action in a Struts > application > > I can write a Servlet. > > Instead of putting my mappings in > struts-config.xml, > > I will put them in > > web.xml. Now, I know there is some other common > > code that is currently not > > in the servlet spec, but is in Struts. My > question > > was is it better to add > > some of those to the servlet spec, rahter than > > rewriting part of it. > > > > Or, second scenario. Let say I'm using Struts. > > Then I write an Action that > > manages these Task objects. I have a > configuration > > file for different Task > > objects. I write an abstract Task class which > > different Tasks can extend. > > My Action is the controller for all the Tasks. I > > figure out which task to > > call examining the URL. Over time, I add to this > > framework to make it > > easier to use. So now i have a task-config.xml > > where I specify all my > > Tasks. I have TaskAction (a controller). And > bunch > > of 'utility code'. > > Then I ask myself, is this that much different > from > > the Actions Struts > > provides? > > > > Note that I'm not necessarily saying this is the > > case, just asking for some > > reasons why that is not the case. General > > information about frameworks and > > how they come about does not address the specific > > question of wheter this > > particular framework duplicates a lot of > > functionality of its parent > > environment. > > > > Either way, thanks for trying :). > > > > ranko > > > > -----Original Message----- > > From: Navjot Singh [mailto:[EMAIL PROTECTED] > > Sent: Monday, July 21, 2003 10:28 AM > > To: Struts Users Mailing List > > Subject: RE: Struts MVC framework similar to that > of > > a servlet > > container? > > > > > > hi ranko, > > > > Assume you don't use struts. You start writing > your > > first app for your > > requirements. Being an expert programmer, you have > > done with first one by > > wriitng lots of utility classes and base code. > > > > Now you start with second. You will realize that > the > > second app can use most > > of the functionality (except business logic) from > > the first app. NOW WHAT? > > You will dig out some code from first app that can > > be RE-USED in second app. > > That code can be called a framework(;et's call it > > RANKo framework ;-) and > > that's precisely what STRUTS intends to provide. > > > > Anyway, it's your viewpoint. Being a creator of > one > > servlet/xml/xslt based > > framework myself(almost 18 months back), I know > what > > is *common code* > > required for *most of the apps* and the > efforts/time > > needed to create that > > framework. So, when starting with an app, i can > find > > and USE as good > > framework as STRUTS, nothing like that. > > > > I don't say STRUTS is good enough, you may have > diff > > requirements altogether > > so struts may not be the best choice for you. You > > write on your own but it's > > always good to look around for good frameworks and > > build ON TOP OF THEM. > > > > hope it clears. still i am trying to give answers > to > > few of the individual > > points below. > > -navjot > > > > |> 1. solid code > > |so does the container i guess. > > > > true but container gives you world of choice. > Struts > > gives you the base code > > for *common* requirements. > > So, you save time writing on *that common* code. > > > > |>2. validation framework > > |This is one of those changes that could be added > by > > way of utility classes. > > |Have that Filter that autopopulates, check for > > correct types like Struts. > > > > Agreed. > > > > |>3. tile framework > > |You can use it without Struts > > > > Struts also does not enforce any fix presentation > > model. > > Could be xslt/velocity/jsp any. > > > > |> 4. auto-population framework > > |It should be easy to add a Filter that > > autopopulates a configured form (not > > |every time but as a standard). > > | > > |> 5. role based actions > > |I'm not sure what this is. > > > > Same as roles in servlet specs but checking is > > deferred per action. > > > > |>6. xml configuration of all the links or actions > > of > > |your application So does web.xml i guess. > > > > but here it is module based config. easy of > > maintenance ;-) > > > > |>7. best practices framework bundling > > (scaffolding)complete with examples > > (many years of experience went > > |into this one). > > |Same thing as above. There are tutorials, > > examples, etc... > > | > > | > > |> 8. ease of use > > |If you think of a Servlet as an Action its kind > of > > as easy. > > |Except for some > > |repetative tasks that I would include to complete > > the servlet spec (rather > > |than rewrite some of the container functionality > to > > add those utils). > > | > > > > > > > > > > |-----Original Message----- > > |From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] > > |Sent: Monday, July 21, 2003 8:42 AM > > |To: Struts Users Mailing List > > |Subject: Re: Struts MVC framework similar to that > > of a servlet > > |container? > > | > > | > > | > > |Sandeep, > > |You mentioned role based actions in your list... > > which has caught my eye. > > |Can you please elaborate on this ? Or point me to > > some documentation ? > > | > > |thanks > > |-raj > > | > > | > > | > > | > > | "Sandeep Takhar" > > | <[EMAIL PROTECTED] > To: > > "Struts Users > > |Mailing List" <[EMAIL PROTECTED]> > > | ahoo.com> > cc: > > | > > Subject: Re: Struts MVC > > |framework similar to that of a servlet container? > > | 21/07/2003 06:08 > > | PM > > | Please respond to > > | "Struts Users > > | Mailing List" > > | > > | > > | > > | > > | > > | > > |there's a lot of stuff it gives you out of the > box. > > | > > |1. solid code > > |2. validation framework > > |3. tile framework > > |4. auto-population framework > > |5. role based actions > > |6. xml configuration of all the links or actions > of > > |your application > > |7. best practices framework bundling > (scaffolding) > > |complete with examples (many years of experience > > went > > |into this one). > > |8. ease of use > > | > > |I am missing about twice as many things from this > > list > > |I am sure... > > | > > |the servlet container is sun's way of making sure > > that > > |what you build is timeless (and works on their > > |servers...) > > | > > |Struts solves common problems across every > typical > > |application. The servlet container does not > solve > > |these typical problems. Struts is really a > > pattern... > > | > > |sandeep > > |--- Ranko Bijelonic <[EMAIL PROTECTED]> wrote: > > |> > > |> Hi. I've been using Struts for a long time, > and > > |> I've been very happy with > > |> the framework. However, a recent discussion on > > |> Sun's Java forums has left > > |> me wondering if Struts is necessary. It seems > > that > > |> the servlet container > > |> itself provides an MVC framework very similar > to > > |> that of Struts. All that > > |> is missing is some utilities and > standardization. > > I > > |> was wondering if there > > |> is a flaw in my logic below, and if anyone had > > any > > |> comments. > > |> > > |> > > |> In comparing these two MVC frameworks, the > > servlet > > |> container would be the > > |> equivalent of the ActionServlet. They both > read > > |> their configuration files, > > |> examine the incoming URL, and then forward the > > |> request to the configured > > |> handler. In the case of the servlet container > > the > > |> handlers are Servlet > > |> classes, and in the case of Struts its the > Action > > |> classes. Both the > > |> container and the ActionServlet will create an > > |> instance of their handler > > |> when its requested the first time. The > Servlet's > > |> service method and the > > |> Action's execute method will call some domain > > logic > > |> and then select a view > > |> to display to the user. The Servlet can use > > |> RequestDispatchers to > > |> encapsulate information about the view, and the > > |> Action will use an > > |> ActionForward. Doesn't this sound very > similar? > > |> > > |> It seems like we are adding a lot of complexity > > on > > |> top of the servlet spec > > |> in order to get some common tasks done for us. > > But > > |> that could probably be > > |> better done by the servlet container itself. > For > > |> example, Struts > > |> automatically populates the form class the > > developer > > |> specifies for a > > |> particular Action. But Sun could provide a > > standard > > |> Filter implementation > > |> which does the same thing. You can declare > > handlers > > |> for your exceptions in > > |> the Struts configuration file, but you can also > > do > > |> it in the web.xml. If > > |> the functionality there is not quite the same, > > Sun > > |> can add a little to the > > |> spec and we would get it. > > |> > > |> My question is, is an application built in > Struts > > |> really that much more > > |> maintainable than one built with servlets? Or > if > > |> some common utilities > > |> provided by the Struts container were provided > by > > |> the servlet container, > > |> would there be much difference? It seems that > > would > > |> even be simpler. Or > > |> not? > > |> > > |> ranko > > |> > > |> > > |> > > > |--------------------------------------------------------------------- > > |> To unsubscribe, e-mail: > > |> [EMAIL PROTECTED] > > |> For additional commands, e-mail: > > |> [EMAIL PROTECTED] > > |> > > | > > | > > |__________________________________ > > |Do you Yahoo!? > > |SBC Yahoo! DSL - Now only $29.95 per month! > > |http://sbc.yahoo.com > > | > > > |--------------------------------------------------------------------- > > |To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > |For additional commands, e-mail: > > [EMAIL PROTECTED] > > | > > | > > | > > | > > | > > | > > | > > | > > > |--------------------------------------------------------------------- > > |To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > |For additional commands, e-mail: > > [EMAIL PROTECTED] > > | > > | > > > |--------------------------------------------------------------------- > > |To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > |For additional commands, e-mail: > > [EMAIL PROTECTED] > > | > > | > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > __________________________________ > Do you Yahoo!? > SBC Yahoo! DSL - Now only $29.95 per month! > http://sbc.yahoo.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
