On 4/20/05, Joe Germuska <[EMAIL PROTECTED]> wrote:
> At 7:04 PM -0700 4/20/05, Martin Cooper wrote:
> >On 4/20/05, Joe Germuska <[EMAIL PROTECTED]> wrote:
> >> I just happened to notice that there's a method on ActionMapping,
> >> "getInputForward()" which applies some config logic, while there's no
> >> corresponding method on ActionConfig. I could see where we might not
> >> directly reproduce it, since ActionConfig shouldn't depend on
> >> ActionForward -- but why is there method like
> >>
> >> public ForwardConfig getInputForwardConfig(){}
> >
> >Can you clarify where you found this? I can't find any method with
> >this name, so I'm missing your point, I'm afraid. ;-(
>
> ActionMapping has
>
> public ActionForward getInputForward();
>
> ActionConfig has no corresponding method. Thus, when one has an
> ActionConfig and validation has failed, and one wants to send the
> view back to the input, one has to either
>
> (1) cast the ActionConfig to ActionMapping (and hope that you have
> one; of course in Struts these days you always do, but why have
> ActionConfig if we aren't going to steer towards using it instead of
> ActionMapping?)
>
> or
>
> (2) perform the logic oneself which is currently done in
> Actionmapping.getInputForward():
>
> if (getModuleConfig().getControllerConfig().getInputForward()) {
> return (findForward(getInput()));
> } else {
> return (new ActionForward(getInput()));
> }
Ah, that. I see.
So this brings us back to the reason for the split between
ActionConfig and ActionMapping, and the other such pairs, I think. I
could easily be mistaken here (Craig, please correct me if I'm wrong),
but I thought the original idea was that ActionConfig and its kin in
o.a.s.config were the pure config JavaBean classes, while the
extensions of those classes added the necessary logic. The lack of
getInputForward() in the ActionConfig class seems to reinforce that.
However, ActionConfig now seems to be far from a simple config bean,
so I'm not sure where we want to go from here. Ideally, I'd like to
see us have an internal configuration representation that's not tied
to either the XML file format we use or the logic we apply on top of
the config, but which most accurately reflects the intent of the
configuration itself. Then we would be in a better position to
separate the logic from the configuration, as well as allow for
entirely different ways of loading the configuration.
I have to say that, with some of the changes we've been making
recently, I feel like we might want to take a step back and see where
we really want to be at the end of (this chapter of) the journey.
(That's really where my earlier comment was going, in another thread
on config complexity.)
--
Martin Cooper
> Joe
>
> --
> Joe Germuska
> [EMAIL PROTECTED]
> http://blog.germuska.com
> "Narrow minds are weapons made for mass destruction" -The Ex
>
> ---------------------------------------------------------------------
> 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]
