This core library could then be called "trinidad-core" or better "trinidad-shared" and would include the skinning features that i wanted to extract in its own library, among other services that you enumerated. I guess MyFaces would probably end up using at least some of those shared services, besides skinning on which was trying to focus mainly :) , so seems like a more bigger task that i initialy thought about.
The request context API (specificaly, the RequestContext base class) is the one that brings all these services togheter, right? Regards, Catalin On 8/4/06, Adam Winer <[EMAIL PROTECTED] > wrote:
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 > > > > > > > > > > > > > > > > > > > > > > > >
