On 2/21/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > > On 2/19/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > On 2/19/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > > > In Struts Classic prior to 1.3 a client calls a concrete action (which > > > is why I consider Struts Classic to *not* be an implementation of > > > Front Controller pattern). > > > > Almost, but not quite ... there was always processng going on before and > > after the call to the action, and you couldn't bypass it except where > Struts > > allowed you to explictly configure bypassing it (like turning off > > validation). For someone who doesn't use form beans (like you, Michael? > :-) > > there isn't a lot actually done there, but it does exist. > > I know that I cannot bypass it. And I think it sucks big time. This is > the ultimate flaw of Struts. I value the framework, it does job for > me. But let me push the buttons, switch the levers and pull the > strings, ok? I appreciate, for example, a chunk of code that populates > form bean from the request. But let me call populate() myself. I > appreciate validator, but let me call validate() myself (this I can > do, thank you). It is not a big deal for me to write couple of lines > of code, but the code looks simpler, I can immediately see what > happens without looking into deployment descriptor... I mean, into > struts-config.xml. > > I do use form beans. I use them in session scope. > > > The primary change in 1.3 is to re-implement the standard request > processor > > pipeline as a chain instead of a monolithic single class (in other > words, > > promoting the sandbox CoR implementation into the mainstream). So, the > use > > of a chain is just an *implementation detail* that does not change the > > "Front Controller" nature of the original framework. But it's now much > > easier to customize the framework's behavior for all requests, by > adjusting > > the definition of the standard chain and/or utilizing optional call-outs > to > > applicaton defined chains. > > > > The next step would be to provide customizable chains per Action > (becoming > > even more like how you configure actions in WebWork) -- but you can even > do > > that today by using an Action that itself executed a chain. > > Why is it always like this? Either everything is done for me (and I > can do little about changing what's happening), or it is super-duper > configurable system? I do not need super-duper. There comes request > with arguments. There is my action (or command, or chain, does not > matter) which is *an endpoint of the request*, because this is how it > is defined in struts-config.xml file. Great. Now just call this > endpoint, and provide me with dozen or so lifecycle methods, that I > can call myself. This would be so much easier than bolting on the > whole CoR pattern and then customizing it.
I would suggest that your preferred approach is certainly legitimate, but is *not* the most common set of preferences. Indeed, things like dependency injection are popular, at least in part, because they do *not* require "lifecycle methods that I can call myself" ... instead, many people *like* an environment where the framework employs the Hollywood Principle (don't call us, we'll call you). Is it possible to have something both extremely simple *and* extremely > flexible? It sounds like you might want to forgo frameworks completely, like Simon Brown is blogging about on java.net :-). Pure servlets and JSP anyone (perhaps with filters thrown in for extra spice)? Or, if you want an itsy bitsy bit of structure, you could think about starting from something like ChainServlet (part of Commons Chain), and implement a service() method that mapped from an incoming URL to the name of a chain to execute. About 5 lines of code, and TOTAL control over what happens for each individual request, because you can compose the chain for each request individually ... or share them when you have common requirements. You could do something similar with almost any favorite paradigm for mapping incoming requests to the corresponding processing logic -- but if frameworks get in your way, why in the heck are you using them in the first place? Guess this is just a Tuesday rant... > > Michael. Craig --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
