[Opensource] Upgrading from 4.02 to 5.02 (some notes)

[Michael Rimov]

At 11:35 AM 6/16/2003 -0400, you wrote:

>Just continuing the discussion:
>
> > This shouldn't be the case.  If you define the view to use in the
> > struts-config.xml instance for your app, Expresso respects that without
> > explicitly setting setStyle().  Could it be that your app is
> > older than 4.0
> > and you're still using old 'view' terminology??  I'm interested in your
> > view of this.
>
>I'm not sure what 'old view' terminology is. In my config file, I use
>
><action path="/xyzzy"
>         type="...myController"
>         scope="request"
>         validate="false"
>           <forward name="default" 
> path="/WEB-INF/hiddenJsps/xyzzy/default.jsp"/>
>         <forward name="state1"
>path="/WEB-INF/hiddenJsps/xyzzy/state1.jsp"/>
>         <forward name="state2"
>path="/WEB-INF/hiddenJsps/xyzzy/state2.jsp"/>
>         <forward name="state3"
>path="/WEB-INF/hiddenJsps/xyzzy/state3.jsp"/>
></action>

Well, that should be working.  If in the controller's constructor you have:

         this.addState(new State("state3", "[description"));

Then unless you specifically set the style to something else [either via 
URL parameter or explicit code]... then Expresso automatically will forward 
to state3.jsp as defined in the forward you listed above.

This is highly tested behavior since DBMaint or nothing would be working 
without the behavior I'm describing... so something else must be going on 
in your code.  [Like you probably have figured that out already ;) ]

But I just wanted to reiterate that this design was as intended.


> > >         - Transitions behave differently enough that I had to write a
> > >           custom class to replace it. Because of the way I dispatch to
> > >           transitions, I need the same request to stick around. (Also,
> > >           subclassing doesn't work here).
> >
> > If you really know your transitions and know there won't be bugs
> > created by
> > dispatching Transitions across multiple controllers, you can call
> > Transition.setParams(request.getParameters());  to dump all the
> > controller
> > parameters into the transition.
>
>This looks nice but doesn't work for me. For starters, it won't copy over
>multi-valued
>parameters. This bit me once before which I fixed by accessing
>HttpServletRequest.getParameterMap. It also doesn't feel right. I really
>want the old
>request object and don't want a (possibly) sanitized copy. There is also an
>'old time programmer'
>part of me that asks why I should spend valuable CPU time on unnecessary
>object creation when
>there is a perfectly good object around :-).

I certainly sympathize with your ideology since I often feel the same 
way.  I'm mainly concerned with providing an environment where hard to 
track down bugs such as parameter name mismatching between controllers is 
more easily prevented.  I'm certainly willing to provide a new method for 
better transferring all parameters across.  But it should definitely IMO 
stay a 'poweruser' trick.  Not the 'best practices' way of doing things.


>My solution was to add a 'dispatch' method to (my version of) the Transition
>and Controller
>classes. That way I have consistent (and documented) custom behaviour and
>can still make use
>of the defined 'transition' behaviour.

That works.  You SHOULD be able to derive from Transition and have all the 
benefits of Transition object.  Did you ever try this and did it work??



> > >Other Comments:
> > >         * private vs. protected.
> > >
> > >             There have been three or four cases where I needed custom
> > >             behaviour from an Expresso class. In every instance, I was
> > >             thwarted from extending the class by a private attribute
> > >             or method that I needed to access. I didn't want to
> > >             change the Expresso source so I was left to the (?bad?)
> > >             solution of copying the source to a new class and editing
> > >             it (Example: Customizing "send" in EMailSender).
> > >
> > >             Question: In an open source environment, where one expects
> > >             developers to extend classes, shouldn't it be the
> > >             exception to use 'private'?
> >
> > Actually, one 'best practices' that I saw that I think made
> > excellent sense
> > was "member variables private.... protected or public getters()"  Saves
> > weird side affects when you refactor the base class.  One significant
> > example would have been that I made 'DBObject.myPool()' start
> > null and only
> > instantiate when needed.  Accessing it through the getter made
> > this have no
> > side affects.
> >
> > So the truth is yes and no.  If you want to extend things and
> > want to add a
> > protected get() method to the base class, feel free to submit a patch to
> > the class in particular.
>
>Sounds right. The natural next step is to insist that the various
>public/protected
>methods always make use of the protected get() methods. This would have
>taken care
>of my various situations.

I will add this to the list of things to check for with the Walkthrough 
committee.  That way, we at least start tracking this down.


>As for submitting patches, I may be able to start doing this but I have been
>quite a
>bit behind the development version and, as a result, largeley treat the
>framework as
>black box. My own code is enough of a moving target.

I hear you.  I just encourage everybody to pitch in.  Expresso is a large 
framework, and with everybody pitching in, it gets better; and some 
otherwise impossible tasks time-wise, become possible.

                                                 -Mike