On Wed, 16 Oct 2002, Martin Cooper wrote:
> Date: Wed, 16 Oct 2002 12:36:34 -0700
> From: Martin Cooper <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: 'Struts Developers List' <[EMAIL PROTECTED]>
> Subject: Modules in Struts 1.1 (was RE: Tiles Refactorings for 1.1
> compata bility)
>
> What Eddie said (mostly). ;-)
>
> We've gone most of the way down the road with modules the way Craig
> originally envisioned them, and we're almost there. There are just a few
> more cleanup tasks to go, such as fixing Tiles to not trip over itself.
>
> I would really like to see us finish what we've started, as soon as we can,
> and then go back and look at the "sharing" thing once 1.1 is final. Maybe
> that comes in a 1.2 that doesn't take us so long to complete as 1.1 has
> taken us. But let's not try to squeeze it in to 1.1, and perhaps later
> regret that we didn't think through all the issues.
>
+1. I was about to write something pretty similar.
> --
> Martin Cooper
>
Craig
>
> > -----Original Message-----
> > From: Eddie Bush [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, October 16, 2002 11:44 AM
> > To: Struts Developers List
> > Subject: Re: Tiles Refactorings for 1.1 compatability
> >
> >
> > Ted Husted wrote:
> >
> > >>From an API perspective, a big issue may be being able to
> > also refer to tile locations using both module-
> > >relative AND application-relative URIs. In a large
> > application, we will want to share tiles between modules to
> > >establish a common look and feel.
> > >
> > Yes - saw that coming. I want to share too, but is it
> > appropriate to do
> > so now and skip the "seperatism" phase? If each module is, in fact,
> > it's own little world, then that should apply to everything.
> > This goes
> > along with previous arguments I've voiced and been told "post
> > 1.1" on.
> > Would it be best to, as I suggested, have Tiles be "stupid" this
> > release (no "chaining"/sharing), and then refactor for
> > sharing once we
> > have a better idea of how sub-apps will be used?
> >
> > >I have a beast in front of me now with 8 logical application
> > "segments" that could become modules in 1.1. But,
> > >there is only one library of tiles, which they all happily
> > share. Each module has its own set of pages, but
> > >being the same application, these pages all use the same
> > layouts and tiles. I could use a separate tiles-def.xml
> > >for each but we need to also be able to share tiles and
> > layouts somehow.
> > >
> > :-/ Well, there's nothing to stop you from referencing the
> > same physical
> > pages that I can think of - but the definitions would be duplicated I
> > suppose. This could be solved by the same concatenation
> > tricks used for
> > previous versions of Struts. I know it's not ideal - but I
> > don't think
> > 1.1F *is* going to be (IMHO - because of the way I feel they
> > should be
> > implemented) ideal. 1.1.1 or 1.2 - that's where we'll whip it into
> > shape. Is this not the direction we are headed? If not, I'd like to
> > know now.
> >
> > >In practice, all a lot of teams really want is multiple
> > configuration files. Right now, the modules seem to be
> > >doing double-duty. You can subdivide a large application
> > into modules to gain multiple configurations, but there
> > >is a corresponding gain in complication unless the modules
> > are very loosely coupled. (The sharing world-view.)
> > >
> > >Now that we have modules in play, would anyone VETO adding
> > the capability to have a delimited list of struts-
> > >configs (for each module) -- to match what we do with the
> > tiles and validator configurations? If for no other
> > >reason, than because we should be providing a consistent
> > approach across components.
> > >
> > >Then, if there is something in the module implementation
> > that classes with a team's world-view, they can
> > >simulate modules usng multiple configuration files. They
> > would end up embedding the module directory in the
> > >URIs, but some people might consider that a fair trade-off
> > to the sharing issues.
> > >
> > Yeah - maybe so.
> >
> > You know (I think) where I stand on the duplication. I don't like it
> > either. The idea I've had impressed upon me (by both Martin
> > and Craig,
> > I believe) is that we should implement 1.1 with each module being in
> > it's "own little world" - and then follow up with discussions
> > on how we
> > can make them work more ideally. That is the exact
> > impression guiding
> > what I am doing to "fix" things that are "not 1.1 compliant".
> >
> > No matter what we do in the future, we need to have each module not
> > being trampled on by the others, so refactoring to allow each app the
> > ability to use a plugin without affecting the others is (I think) a
> > necessary step. Whether we go one further and implement
> > chaining is an
> > option I would certainly be open to, but I was under the
> > impression this
> > shouldn't be done until "later" (post 1.1). I hope others will share
> > their feelings. Bear in mind there are folks looking heavily at 1.1
> > that can't use it because of it's "beta" status. It's a time/feature
> > trade-off :-)
> >
> > I don't see it being necessary to rework the config
> > instantiation/acquisition beyond 1.1. The thing that will have to
> > change is how the lookups are done. I really think we can
> > break these
> > out into two releases without having to do rework, if that is
> > the way it
> > needs to go. We could go ahead and refactor the lookups now too, if
> > that's the appropriate course, but there's obviously going to be
> > additional delay for doing so.
> >
> > Do we need a proposal maybe?
> >
> > >-Ted.
> > >
> >
> > --
> > Eddie Bush
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> >
> >
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
