On 8/25/05, Greg Reddin <[EMAIL PROTECTED]> wrote: > On Aug 25, 2005, at 1:55 PM, David Geary wrote: > > I'm +1 for this, but should we make plugging standalone Tiles back > > into Struts > > a priority and tackle this once that's done? Perhaps it's unfounded, > > but I'm > > concerned that the current Tiles will change if we don't act quickly. > > If Tiles needs more changes wouldn't it be easier to implement them > while it's still in the Sandbox than when it becomes a sub-project or > whatever? Once something is published it will be more difficult to > change it. So, what are the changes? In addition to Craig's idea of > externalizing the Servlet API I'd like to further refine the > ComponentDefinition class. xmlDefinition extends ComponentDefinition > and does some stuff that, it seems to me, should be moved up to the > base level. Possibly, the whole xmlDefinitiion package could go away > and be merged up. Right now I think it's a bit of a mess b/c I merged > some of it up but not the rest. OTOH, that wouldn't affect users > unless they are subclassing DefinitionsFactory or ComponentDefinitions > or something. > > Either way, because Standalone Tiles has changed so much internally > from the integrated version we should probably be real careful about > how it's brought back in. I guess we could deprecate > org.apache.struts.tiles and bring in org.apache.tiles. > > Sorry, this is kinda random. As Craig said once, we have one shot at > changing things while Tiles is in the sandbox. I'd hate for us to wrap > that up prematurely. >
Sandbox or subproject doesn't really make any difference on being able to refine APIs, until standalone Tiles does a 1.0 release. From that point on is where you'd want the APIs to be stable. > Greg Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
