I think that what we'd want to provide, at least as a first pass is a Trinidad Core library, that provides shared services independent of the component set; so, skinning, agent detection, some core PPR APIs, pageFlowScope, the dialog framework, etc.
-- Adam On 8/3/06, Catalin Kormos <[EMAIL PROTECTED]> wrote:
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 > > > > > > > > > > > > > > > >
