Hi Mike, Thanks! stay tuned, more to come...
On 7/31/06, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
Catalin, Sounds great! That's definitely part of the task of merging Tomahawk and Trinidad. On 7/31/06, Catalin Kormos <[EMAIL PROTECTED]> wrote: > Hi there, > > Following the idea that it would be great if the skinning features currently > available in Trinidad, would be available to the overall MyFaces world also, > i would like to discuss with you guys what would it take to make this > happen. I would like to propose, the creation of a new module in Trinidad, > called "trinidad-skinning" in which the packages/classes that are > implementing the skinning features could be separated; the goal would be to > end up having both Trinidad and MyFaces able to declare a dependency on this > new module and with some (minimal) integration code to use those features in > their own components sets. > > There are tree main packages that would need to go into the new module > (taken from trinidad-impl module): > > 1. org.apache.myfaces.trinidadinternal.share (or this could be maybe > extracted in its own module, like trinidad-commons?, although not realy > necesary as impl would depend on skinning) > 2. org.apache.myfaces.trinidadinternal.skin > 3. org.apache.myfaces.trinidadinternal.style > > Besides these, there are other small utility and context classes from api > and impl used by classes from the above packages, which could be moved into > the new module (or maybe duplicated into the module, at least some of them > which can't be moved). One interface in particular, from the api, would > neeed to be moved to the new module, > org.apache.myfaces.trinidadinternal.style.Agent. This interface is just > declared in the api and used by the impl, but as impl will declare a > dependency on the skinning module, i think it's safe to be moved there or > have a base interface in the new module. > > This would the general idea, I can come up with more, and willing to do the > work to make this happen. What i would like to start with is make some > refactorings on some of the classes that have direct dependencies on > trinidad, like FileSystemStyleCache, which has an inner field _STYLE_KEY_MAP > that holds the mappings between public style selectors names to internal > style selectors names. (this is actualy on your todo list already, from the > comments i found in the code). Of course, more questions/propositions are on > their way, as before opening an issue and providing a patch, i'll need to > make sure the solution is the right one. Another goal is also to make sure > trinidad works just as before changing something. > > Regards, > Catalin > >
