We probably wouldn't be able to rename it per se. We'd have to deprecate one class and bring another up using the new name. (The one we deprecating being a shell that calls the new one.) Tyranny of the installed base, and all that :)
A lot of the naming in the Tiles package is inconsistence and does need to be addressed. One reason for this was that Tiles had a name change late in the cycle, so sometimes the older name is used. What would be helpful would be a proposal that presented an new API with al the changes, as well as what bridge classes would be needed to get there from here. -Ted. On Fri, 02 Jan 2004 07:25:16 -0500, [EMAIL PROTECTED] wrote: > > Hi all, I was recently poking around in the source and API docs for > some of the Tiles classes, and noticed there is an interface > org.apache.struts.tiles.DefinitionsFactory, and a concrete class > org.apache.struts.tiles.xmlDefinition.DefinitionsFactory. Now, > this isn't a problem in any objective sense, and granted, they are > in different packages... > > But, to a developer new to the Tiles source, it makes things just a > tad bit confusing. Actually, a lot of the naming conventions in > Tiles are confusing to me, and maybe I'll throw some other > suggestions out later.. but for now, I wonder if there's any > possibility of renaming one of the DefinitionsFactory types? > > I'm afraid I'm not familiar enough with the code (yet) to have a > full understanding of what all the ramifications of this would be, > and maybe it's a dumb idea... but I thought I'd mention it and see > what the experienced Struts / Tiles folks had to say. > > > Thanks, > > > Phillip Rhodes > Application Designer > Voice Data Solutions > 919-571-4300 x225 > [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
