RequestContext is an important part of it, yeah, but Skin and SkinFactory (which aren't yet fully public, but probably need to be) too, probably other stuff.
-- Adam On 8/4/06, Catalin Kormos <[EMAIL PROTECTED]> wrote:
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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
