Michael Gerdau wrote:
> >I hope I've been able to present my concerns and arguments in
> >at least a partially understandable way. I am open to discussion
> >on this, but unfortunately, I feel at this time that the end result
> >should be that struts not impose the ONE controller solution on us.
>
> Let me rephrase what I understood of ypur concerns to see wether I
> got your focal point:
> Your main issue is that you want to be able to build large modular
> webapps with each sub-webapp being separately maintain-/develop-/deployable
> rather than providing one large monolithic webapp.
>
in a gross sense, this is correct. unfortunately, it doesn't completely
cover the picture and i may not have expressed myself well on this.
my situation requires a master controller -- the great mediator, if
you will, between the various sub-applications. in the end, all URLs
that the user gets redirected to for results land on the master
controller
which then acts as an app-state redraw agent. (the master controller
is also the "app-switcher" used by the user for making gross shifts
from one sub-app to another).
i also failed to mention that this application lives in a lively dynamic
frameset that requires careful control to maintain its integrity. This
is difficult, if not impossible to do if i'm constantly handing off
control to different webapps which share _nothing_ of the the servlet
or session context containing my state.
separate WEBAPPs == shared _nothing_
one webapp/one controller == [large] monolithic shared _everything_
(i need something in the middle)
> Assuming my above rephrasing does correctly capture your concerns here
> are my comments on it:
> I agree with that requirement.
>
> I also believe it should be possibly to achieve that using the current
> design without too much additional hazzle.
>
> How about the following quick and dirty idea:
> Make all your separate sub-webapps independend webapps. Each of these
> does need some "gate" to be entered from one of the other apps. Also
> add "transition points" into your sub-webapps to act as stepping stones.
>
> AFAICT you'll need such "gates" anyway since you have to define
> interfaces between your sub-webapps even when allowing for different
> controllers, set of action-mappings etc.
the "gate" concept is interesting and, to some extent, already
handled in my prototype through the use of a pagestack/state manager
and the master shell controller. keep in mind that many of the
interfaces in question involve UI presentation through JSP that
generate result data to be used by another sub-app. this data needs
to be squirreled away in a shared area -- the session or
request context (which isn't available if i am forced to use
separate webapps).
(also, production isn't too keen on quick and dirty tricks :)
>
> You may have to add a custom taglib like the 'app' taglib from the
> example application to handle the transition but I believe it could
> be done.
>
but how can a taglib help different webapps communicate across
separate servlet and session contexts???
> At a later point in time this may be further supported by struts
> by allowing dynamically reloading the action-mapping of a webapp.
> By means of this we could modularize action-mappings which might
> help to achieve the above design goal.
dynamic reloading of action-mappings is not my highest concern
right now. the reality of the situation is that production code
updates (unless they only involve presentation issues or
inherently dynamic data) usually require the system to come down.
although dynamic reloading would be real nice in the future,
right now i find it to be just too glitchy and unreliable to be
of any practical use in a critical production environment.
> >Although others may disagree, I cannot say that struts 1.0 is
> >ready for final release until the single-controller limitation is
> >removed. Removing the limitation *may* require some changes that
> >are not backward compatible and therefore should be made sooner
> >rather than later.
>
> I do disagree.
>
> I do this mostly on the basis that I don't value the restrictions
> you point out as being that important. After all your requirements
> seem to be rather complex and way beyond what most current webapps
> need (don't get me wrong - that doesn't make these requirements
> invalid).
>
IYHO/IMHO :)
question -- what is struts intended for? simple [toy] webapps?
was there/is there a hope that it can be used in a
significant way in significant applications in real
world deployment?
don't get me wrong, i'm rather happy with what i've used so far
and the things it allows me to accomplish. if i didn't respect
struts accomplishments to date, then i wouldn't be bothering with
it all right now. but struts shouldn't also sell itself short --
adjusting its aim just a little higher opens up a world of
possibilities.
> Second I'm not yet convinced your requirements can't be satiesfied
> (to an acceptable degree) by the design as it is just now.
as it stands right now, all i can do is disagree. :]
>
> Third I do believe it just is about time to release a (basic)
> framework that does solve most users needs to have a solid platform
> to continue further development (i.e. toward 1.1, 1.2, ...2.0)
>
i do agree with this point to an extent. unfortunately, the
modifications that may be required for multi-controller support
may break backward compatibility in rather insidious ways. so if
the mods are done at all, it would be best done sooner rather
than later.
> My thoughts, best,
> Michael
e
_______________________________________________________________________
Elod Horvath ('e')
