I'm glad to hear that. I worry about that too :) how much will the skinning module provide.
My thinking is that at least a base and thiner Agent API would be needed, so agent detection will work just as it works right now in Trinidad (and defining styles based on that), but the actual detection maybe it shouldn't be part of the skinning module . The context API is about integration code already, right? some base classes for that would need to be provided by this module also, right? so how would the skinning be integrated into MyFaces or Trinidad is already a separate choise for each project, but integration shouldn't require too much work. How does this sound so far? Regards, Catalin On 8/2/06, Adam Winer <[EMAIL PROTECTED]> wrote:
An excellent idea - but I do worry about how it'll turn out in practice... I think there's a lot of dependencies, like the Agent API and (maybe) the RequestContext API, etc. If you start pulling those out into a skinning module, that module will end up having a lot more than just skinning in it. -- Adam On 8/1/06, Catalin Kormos <[EMAIL PROTECTED]> wrote: > 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 > > > > > > > > > >
