Hi,
Yeah, that's something i would like to see also. My initial plan is just
about extracting what's currently done in Trinidad into an independent
module and then be able to develop on it more, in smaller steps.
Regards,
Catalin
On 7/31/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Hello,
I would also like to see something like this. However, if we do, I would
encourage doing some reengineering work to write a public interfaces API
using factories and/or service providers (I think the engine already use a
provider, but I'm not sure) so that skinning become a pluggable module.
That way, the user could completely change the default skin functionality
with any skinning engine of his own to alter the whole application.
Regards,
Simon Lessard
Fujitsu Consulting
"Mike Kienenberger" <[EMAIL PROTECTED]>
2006-07-31 14:36
Please respond to adffaces-dev
To: [email protected]
cc:
Subject: Re: [Proposal] trinidad-skinning module
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
>
>
