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

[Vincent Gogan]

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>


> >         - 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 :-).

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.

> >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.

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.

Vincent