You are viewing a plain text version of this content. The canonical link for it is here.
Posted to adffaces-dev@incubator.apache.org by Catalin Kormos <ca...@gmail.com> on 2006/07/31 09:05:13 UTC
[Proposal] trinidad-skinning module
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
Re: Re: Re: [Proposal] trinidad-skinning module
Posted by Adam Winer <aw...@gmail.com>.
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 <ca...@gmail.com> 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 <awiner@gmail.com > 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 < catalin.kormos@gmail.com> 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 < awiner@gmail.com > 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 < catalin.kormos@gmail.com> wrote:
> > > > > Hi Mike,
> > > > >
> > > > > Thanks! stay tuned, more to come...
> > > > >
> > > > > On 7/31/06, Mike Kienenberger < mkienenb@gmail.com> wrote:
> > > > > >
> > > > > > Catalin,
> > > > > >
> > > > > > Sounds great! That's definitely part of the task of merging
> > Tomahawk
> > > > > > and Trinidad.
> > > > > >
> > > > > > On 7/31/06, Catalin Kormos < catalin.kormos@gmail.com > 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
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>
Re: Re: Re: [Proposal] trinidad-skinning module
Posted by Catalin Kormos <ca...@gmail.com>.
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 <awiner@gmail.com > 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 < catalin.kormos@gmail.com> 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 < awiner@gmail.com > 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 < catalin.kormos@gmail.com> wrote:
> > > > Hi Mike,
> > > >
> > > > Thanks! stay tuned, more to come...
> > > >
> > > > On 7/31/06, Mike Kienenberger < mkienenb@gmail.com> wrote:
> > > > >
> > > > > Catalin,
> > > > >
> > > > > Sounds great! That's definitely part of the task of merging
> Tomahawk
> > > > > and Trinidad.
> > > > >
> > > > > On 7/31/06, Catalin Kormos < catalin.kormos@gmail.com > 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
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> >
> >
>
Re: Re: Re: [Proposal] trinidad-skinning module
Posted by Adam Winer <aw...@gmail.com>.
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 <ca...@gmail.com> 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 <aw...@gmail.com> 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 <ca...@gmail.com> wrote:
> > > Hi Mike,
> > >
> > > Thanks! stay tuned, more to come...
> > >
> > > On 7/31/06, Mike Kienenberger <mk...@gmail.com> wrote:
> > > >
> > > > Catalin,
> > > >
> > > > Sounds great! That's definitely part of the task of merging Tomahawk
> > > > and Trinidad.
> > > >
> > > > On 7/31/06, Catalin Kormos <catalin.kormos@gmail.com > 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
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>
Re: Re: [Proposal] trinidad-skinning module
Posted by Catalin Kormos <ca...@gmail.com>.
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 <aw...@gmail.com> 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 <ca...@gmail.com> wrote:
> > Hi Mike,
> >
> > Thanks! stay tuned, more to come...
> >
> > On 7/31/06, Mike Kienenberger <mk...@gmail.com> wrote:
> > >
> > > Catalin,
> > >
> > > Sounds great! That's definitely part of the task of merging Tomahawk
> > > and Trinidad.
> > >
> > > On 7/31/06, Catalin Kormos <catalin.kormos@gmail.com > 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
> > > >
> > > >
> > >
> >
> >
>
Re: [Question] Is there a list of missing "faces-major" renderer anywhere?
Posted by Matthias Wessendorf <ma...@apache.org>.
ok, I need this list too, because that task is on my "todo" list here ... ;-)
On 8/3/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
> Will be great, thanks.
>
> Simon Lessard
> Fujitsu Consulting
>
>
>
>
> "Matthias Wessendorf" <ma...@apache.org>
> Sent by: mwessendorf@gmail.com
> 2006-08-03 14:30
> Please respond to adffaces-dev
>
> To: adffaces-dev@incubator.apache.org
> cc:
> Subject: Re: [Question] Is there a list of missing
> "faces-major" renderer anywhere?
>
>
> That task starts soon :)
> Train has been made "faces_major" during the renaming of the components;
> some are still missing; I hope to provide a complete list by the end
> of this week
>
> -Matthias
>
> On 8/3/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
> > Yeah, but checking the hierarchy won't tell which are missing, only
> which
> > are existing so comparing with renderers existing within .renderkit
> > package system will be still needed , hence why I asked if someone had
> > already done something like this or not.
> >
> >
> > Regards,
> >
> > Simon Lessard
> > Fujitsu Consulting
> >
> >
> >
> >
> > "Matthias Wessendorf" <ma...@apache.org>
> > Sent by: mwessendorf@gmail.com
> > 2006-08-03 14:08
> > Please respond to adffaces-dev
> >
> > To: adffaces-dev@incubator.apache.org
> > cc:
> > Subject: Re: [Question] Is there a list of missing
> > "faces-major" renderer anywhere?
> >
> >
> > All of them extend in a way from "UINodeRendererBase"
> >
> > -Matthias
> >
> > On 8/3/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
> > > Sure, np.
> > >
> > > Simon Lessard
> > > Fujitsu Consulting
> > >
> > >
> > >
> > >
> > > "Matthias Wessendorf" <ma...@apache.org>
> > > Sent by: mwessendorf@gmail.com
> > > 2006-08-03 13:51
> > > Please respond to adffaces-dev
> > >
> > > To: adffaces-dev@incubator.apache.org
> > > cc:
> > > Subject: Re: [Question] Is there a list of missing
> > > "faces-major" renderer anywhere?
> > >
> > >
> > > Yes, I started one. but it's incomplete.
> > > Lemme make an update during the rest of this week.
> > >
> > > ok?
> > >
> > > On 8/3/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
> > > > Hello,
> > > >
> > > > The topic prety much say it all. Do we have a list of all missing
> > > > renderers? And also, once we aren't missing any, are we planning to
> > > delete
> > > > ui and uinode packages? If so, I won't bother adding 5.0 standard to
> > > > those.
> > > >
> > > >
> > > > Regards,
> > > >
> > > > Simon Lessard
> > > > Fujitsu Consulting
> > > >
> > >
> > >
> > > --
> > > Matthias Wessendorf
> > >
> > > further stuff:
> > > blog: http://jroller.com/page/mwessendorf
> > > mail: mwessendorf-at-gmail-dot-com
> > >
> > >
> > >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > further stuff:
> > blog: http://jroller.com/page/mwessendorf
> > mail: mwessendorf-at-gmail-dot-com
> >
> >
> >
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>
>
>
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: [Question] Is there a list of missing "faces-major" renderer anywhere?
Posted by Si...@DMR.CA.
Will be great, thanks.
Simon Lessard
Fujitsu Consulting
"Matthias Wessendorf" <ma...@apache.org>
Sent by: mwessendorf@gmail.com
2006-08-03 14:30
Please respond to adffaces-dev
To: adffaces-dev@incubator.apache.org
cc:
Subject: Re: [Question] Is there a list of missing
"faces-major" renderer anywhere?
That task starts soon :)
Train has been made "faces_major" during the renaming of the components;
some are still missing; I hope to provide a complete list by the end
of this week
-Matthias
On 8/3/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
> Yeah, but checking the hierarchy won't tell which are missing, only
which
> are existing so comparing with renderers existing within .renderkit
> package system will be still needed , hence why I asked if someone had
> already done something like this or not.
>
>
> Regards,
>
> Simon Lessard
> Fujitsu Consulting
>
>
>
>
> "Matthias Wessendorf" <ma...@apache.org>
> Sent by: mwessendorf@gmail.com
> 2006-08-03 14:08
> Please respond to adffaces-dev
>
> To: adffaces-dev@incubator.apache.org
> cc:
> Subject: Re: [Question] Is there a list of missing
> "faces-major" renderer anywhere?
>
>
> All of them extend in a way from "UINodeRendererBase"
>
> -Matthias
>
> On 8/3/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
> > Sure, np.
> >
> > Simon Lessard
> > Fujitsu Consulting
> >
> >
> >
> >
> > "Matthias Wessendorf" <ma...@apache.org>
> > Sent by: mwessendorf@gmail.com
> > 2006-08-03 13:51
> > Please respond to adffaces-dev
> >
> > To: adffaces-dev@incubator.apache.org
> > cc:
> > Subject: Re: [Question] Is there a list of missing
> > "faces-major" renderer anywhere?
> >
> >
> > Yes, I started one. but it's incomplete.
> > Lemme make an update during the rest of this week.
> >
> > ok?
> >
> > On 8/3/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
> > > Hello,
> > >
> > > The topic prety much say it all. Do we have a list of all missing
> > > renderers? And also, once we aren't missing any, are we planning to
> > delete
> > > ui and uinode packages? If so, I won't bother adding 5.0 standard to
> > > those.
> > >
> > >
> > > Regards,
> > >
> > > Simon Lessard
> > > Fujitsu Consulting
> > >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > further stuff:
> > blog: http://jroller.com/page/mwessendorf
> > mail: mwessendorf-at-gmail-dot-com
> >
> >
> >
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>
>
>
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: [Question] Is there a list of missing "faces-major" renderer anywhere?
Posted by Matthias Wessendorf <ma...@apache.org>.
That task starts soon :)
Train has been made "faces_major" during the renaming of the components;
some are still missing; I hope to provide a complete list by the end
of this week
-Matthias
On 8/3/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
> Yeah, but checking the hierarchy won't tell which are missing, only which
> are existing so comparing with renderers existing within .renderkit
> package system will be still needed , hence why I asked if someone had
> already done something like this or not.
>
>
> Regards,
>
> Simon Lessard
> Fujitsu Consulting
>
>
>
>
> "Matthias Wessendorf" <ma...@apache.org>
> Sent by: mwessendorf@gmail.com
> 2006-08-03 14:08
> Please respond to adffaces-dev
>
> To: adffaces-dev@incubator.apache.org
> cc:
> Subject: Re: [Question] Is there a list of missing
> "faces-major" renderer anywhere?
>
>
> All of them extend in a way from "UINodeRendererBase"
>
> -Matthias
>
> On 8/3/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
> > Sure, np.
> >
> > Simon Lessard
> > Fujitsu Consulting
> >
> >
> >
> >
> > "Matthias Wessendorf" <ma...@apache.org>
> > Sent by: mwessendorf@gmail.com
> > 2006-08-03 13:51
> > Please respond to adffaces-dev
> >
> > To: adffaces-dev@incubator.apache.org
> > cc:
> > Subject: Re: [Question] Is there a list of missing
> > "faces-major" renderer anywhere?
> >
> >
> > Yes, I started one. but it's incomplete.
> > Lemme make an update during the rest of this week.
> >
> > ok?
> >
> > On 8/3/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
> > > Hello,
> > >
> > > The topic prety much say it all. Do we have a list of all missing
> > > renderers? And also, once we aren't missing any, are we planning to
> > delete
> > > ui and uinode packages? If so, I won't bother adding 5.0 standard to
> > > those.
> > >
> > >
> > > Regards,
> > >
> > > Simon Lessard
> > > Fujitsu Consulting
> > >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > further stuff:
> > blog: http://jroller.com/page/mwessendorf
> > mail: mwessendorf-at-gmail-dot-com
> >
> >
> >
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>
>
>
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: [Question] Is there a list of missing "faces-major" renderer anywhere?
Posted by Si...@DMR.CA.
Yeah, but checking the hierarchy won't tell which are missing, only which
are existing so comparing with renderers existing within .renderkit
package system will be still needed , hence why I asked if someone had
already done something like this or not.
Regards,
Simon Lessard
Fujitsu Consulting
"Matthias Wessendorf" <ma...@apache.org>
Sent by: mwessendorf@gmail.com
2006-08-03 14:08
Please respond to adffaces-dev
To: adffaces-dev@incubator.apache.org
cc:
Subject: Re: [Question] Is there a list of missing
"faces-major" renderer anywhere?
All of them extend in a way from "UINodeRendererBase"
-Matthias
On 8/3/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
> Sure, np.
>
> Simon Lessard
> Fujitsu Consulting
>
>
>
>
> "Matthias Wessendorf" <ma...@apache.org>
> Sent by: mwessendorf@gmail.com
> 2006-08-03 13:51
> Please respond to adffaces-dev
>
> To: adffaces-dev@incubator.apache.org
> cc:
> Subject: Re: [Question] Is there a list of missing
> "faces-major" renderer anywhere?
>
>
> Yes, I started one. but it's incomplete.
> Lemme make an update during the rest of this week.
>
> ok?
>
> On 8/3/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
> > Hello,
> >
> > The topic prety much say it all. Do we have a list of all missing
> > renderers? And also, once we aren't missing any, are we planning to
> delete
> > ui and uinode packages? If so, I won't bother adding 5.0 standard to
> > those.
> >
> >
> > Regards,
> >
> > Simon Lessard
> > Fujitsu Consulting
> >
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>
>
>
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: [Question] Is there a list of missing "faces-major" renderer anywhere?
Posted by Matthias Wessendorf <ma...@apache.org>.
All of them extend in a way from "UINodeRendererBase"
-Matthias
On 8/3/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
> Sure, np.
>
> Simon Lessard
> Fujitsu Consulting
>
>
>
>
> "Matthias Wessendorf" <ma...@apache.org>
> Sent by: mwessendorf@gmail.com
> 2006-08-03 13:51
> Please respond to adffaces-dev
>
> To: adffaces-dev@incubator.apache.org
> cc:
> Subject: Re: [Question] Is there a list of missing
> "faces-major" renderer anywhere?
>
>
> Yes, I started one. but it's incomplete.
> Lemme make an update during the rest of this week.
>
> ok?
>
> On 8/3/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
> > Hello,
> >
> > The topic prety much say it all. Do we have a list of all missing
> > renderers? And also, once we aren't missing any, are we planning to
> delete
> > ui and uinode packages? If so, I won't bother adding 5.0 standard to
> > those.
> >
> >
> > Regards,
> >
> > Simon Lessard
> > Fujitsu Consulting
> >
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>
>
>
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: [Question] Is there a list of missing "faces-major" renderer anywhere?
Posted by Si...@DMR.CA.
Sure, np.
Simon Lessard
Fujitsu Consulting
"Matthias Wessendorf" <ma...@apache.org>
Sent by: mwessendorf@gmail.com
2006-08-03 13:51
Please respond to adffaces-dev
To: adffaces-dev@incubator.apache.org
cc:
Subject: Re: [Question] Is there a list of missing
"faces-major" renderer anywhere?
Yes, I started one. but it's incomplete.
Lemme make an update during the rest of this week.
ok?
On 8/3/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
> Hello,
>
> The topic prety much say it all. Do we have a list of all missing
> renderers? And also, once we aren't missing any, are we planning to
delete
> ui and uinode packages? If so, I won't bother adding 5.0 standard to
> those.
>
>
> Regards,
>
> Simon Lessard
> Fujitsu Consulting
>
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: [Question] Is there a list of missing "faces-major" renderer anywhere?
Posted by Matthias Wessendorf <ma...@apache.org>.
Yes, I started one. but it's incomplete.
Lemme make an update during the rest of this week.
ok?
On 8/3/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
> Hello,
>
> The topic prety much say it all. Do we have a list of all missing
> renderers? And also, once we aren't missing any, are we planning to delete
> ui and uinode packages? If so, I won't bother adding 5.0 standard to
> those.
>
>
> Regards,
>
> Simon Lessard
> Fujitsu Consulting
>
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
[Question] Is there a list of missing "faces-major" renderer anywhere?
Posted by Si...@DMR.CA.
Hello,
The topic prety much say it all. Do we have a list of all missing
renderers? And also, once we aren't missing any, are we planning to delete
ui and uinode packages? If so, I won't bother adding 5.0 standard to
those.
Regards,
Simon Lessard
Fujitsu Consulting
Re: Re: Re: JSF 1.2 vs. RequestMap, SessionMap, ApplicationMap and AttributeMap
Posted by Adam Winer <aw...@gmail.com>.
maxPathKey sounds like just a bug.
UIXComponentBase shouldn't allow PropertyKeys in its ValueMap;
seemed like a good idea at the time, but I don't think anyone is using
it, and it causes API problems.
-- Adam
On 8/2/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
> Errrr,
>
> Actually it's the maxPathKey, that is an object, not the rowKey.
>
> Simon Lessard
> Fujitsu Consulting
>
>
>
>
> Simon_Lessard@DMR.CA
> 2006-08-02 12:55
> Please respond to adffaces-dev
>
> To: adffaces-dev@incubator.apache.org
> cc:
> Subject: Re: Re: JSF 1.2 vs. RequestMap, SessionMap,
> ApplicationMap and AttributeMap
>
>
> Hello,
>
> For the attribute map, UIXComponentBase uses a ValueMap class that allows
> String and PropertyKey keys. I didn't find any place using that feature
> yet however.
>
> As for the scope maps, Trinidad does use Object keys when saving some
> DataModel rowkeys information. An example is ProcessUtils.clearMaxPath. An
>
> easy fix would be to change the DataModel to allow only String rowKeys
> since I think all the internal ones already use String only.
>
>
> Regards,
>
> Simon Lessard
> Fujitsu Consulting
>
>
>
>
>
> "Adam Winer" <aw...@gmail.com>
> 2006-08-02 12:05
> Please respond to adffaces-dev
>
> To: adffaces-dev@incubator.apache.org
> cc:
> Subject: Re: Re: JSF 1.2 vs. RequestMap, SessionMap,
> ApplicationMap and AttributeMap
>
>
> If Trinidad *is* using any non-String keys, that'd actually
> be a pretty bad bug. So, I'd definitely like to keep track
> of this.
>
> -- Adam
>
>
> On 8/2/06, Matthias Wessendorf <ma...@apache.org> wrote:
> > Hi Simon,
> >
> > I think it is not a bad idea to keep track of issues like that. As you
> > already notice it's not a blocker but maybe a "major". The earlier we
> > know what needs to be done; the better.
> >
> > -Matthias
> >
> > On 8/2/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
> > > Hello,
> > >
> > > Sould I post a trivial priority issue on JIRA about what Trinidad put
> in
> > > the following map: RequestMap, SessionMap, ApplicationMap and
> > > AttributeMap? JSF 1.2 specifies <String, Object> for all of them while
> > > Trinidad uses <Object, Object>. Since we don't plan to switch to 1.2
> soon
> > > it's not a big deal yet, but I think we should keep it in mind so we
> know
> > > some changes will be required to conform to 1.2 spec.
> > >
> > >
> > > Simon Lessard
> > > Fujitsu Consulting
> > >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > further stuff:
> > blog: http://jroller.com/page/mwessendorf
> > mail: mwessendorf-at-gmail-dot-com
> >
>
>
>
>
Re: Re: JSF 1.2 vs. RequestMap, SessionMap, ApplicationMap and AttributeMap
Posted by Si...@DMR.CA.
Errrr,
Actually it's the maxPathKey, that is an object, not the rowKey.
Simon Lessard
Fujitsu Consulting
Simon_Lessard@DMR.CA
2006-08-02 12:55
Please respond to adffaces-dev
To: adffaces-dev@incubator.apache.org
cc:
Subject: Re: Re: JSF 1.2 vs. RequestMap, SessionMap,
ApplicationMap and AttributeMap
Hello,
For the attribute map, UIXComponentBase uses a ValueMap class that allows
String and PropertyKey keys. I didn't find any place using that feature
yet however.
As for the scope maps, Trinidad does use Object keys when saving some
DataModel rowkeys information. An example is ProcessUtils.clearMaxPath. An
easy fix would be to change the DataModel to allow only String rowKeys
since I think all the internal ones already use String only.
Regards,
Simon Lessard
Fujitsu Consulting
"Adam Winer" <aw...@gmail.com>
2006-08-02 12:05
Please respond to adffaces-dev
To: adffaces-dev@incubator.apache.org
cc:
Subject: Re: Re: JSF 1.2 vs. RequestMap, SessionMap,
ApplicationMap and AttributeMap
If Trinidad *is* using any non-String keys, that'd actually
be a pretty bad bug. So, I'd definitely like to keep track
of this.
-- Adam
On 8/2/06, Matthias Wessendorf <ma...@apache.org> wrote:
> Hi Simon,
>
> I think it is not a bad idea to keep track of issues like that. As you
> already notice it's not a blocker but maybe a "major". The earlier we
> know what needs to be done; the better.
>
> -Matthias
>
> On 8/2/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
> > Hello,
> >
> > Sould I post a trivial priority issue on JIRA about what Trinidad put
in
> > the following map: RequestMap, SessionMap, ApplicationMap and
> > AttributeMap? JSF 1.2 specifies <String, Object> for all of them while
> > Trinidad uses <Object, Object>. Since we don't plan to switch to 1.2
soon
> > it's not a big deal yet, but I think we should keep it in mind so we
know
> > some changes will be required to conform to 1.2 spec.
> >
> >
> > Simon Lessard
> > Fujitsu Consulting
> >
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>
Re: Re: JSF 1.2 vs. RequestMap, SessionMap, ApplicationMap and AttributeMap
Posted by Si...@DMR.CA.
Hello,
For the attribute map, UIXComponentBase uses a ValueMap class that allows
String and PropertyKey keys. I didn't find any place using that feature
yet however.
As for the scope maps, Trinidad does use Object keys when saving some
DataModel rowkeys information. An example is ProcessUtils.clearMaxPath. An
easy fix would be to change the DataModel to allow only String rowKeys
since I think all the internal ones already use String only.
Regards,
Simon Lessard
Fujitsu Consulting
"Adam Winer" <aw...@gmail.com>
2006-08-02 12:05
Please respond to adffaces-dev
To: adffaces-dev@incubator.apache.org
cc:
Subject: Re: Re: JSF 1.2 vs. RequestMap, SessionMap,
ApplicationMap and AttributeMap
If Trinidad *is* using any non-String keys, that'd actually
be a pretty bad bug. So, I'd definitely like to keep track
of this.
-- Adam
On 8/2/06, Matthias Wessendorf <ma...@apache.org> wrote:
> Hi Simon,
>
> I think it is not a bad idea to keep track of issues like that. As you
> already notice it's not a blocker but maybe a "major". The earlier we
> know what needs to be done; the better.
>
> -Matthias
>
> On 8/2/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
> > Hello,
> >
> > Sould I post a trivial priority issue on JIRA about what Trinidad put
in
> > the following map: RequestMap, SessionMap, ApplicationMap and
> > AttributeMap? JSF 1.2 specifies <String, Object> for all of them while
> > Trinidad uses <Object, Object>. Since we don't plan to switch to 1.2
soon
> > it's not a big deal yet, but I think we should keep it in mind so we
know
> > some changes will be required to conform to 1.2 spec.
> >
> >
> > Simon Lessard
> > Fujitsu Consulting
> >
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>
Re: Re: JSF 1.2 vs. RequestMap, SessionMap, ApplicationMap and AttributeMap
Posted by Adam Winer <aw...@gmail.com>.
If Trinidad *is* using any non-String keys, that'd actually
be a pretty bad bug. So, I'd definitely like to keep track
of this.
-- Adam
On 8/2/06, Matthias Wessendorf <ma...@apache.org> wrote:
> Hi Simon,
>
> I think it is not a bad idea to keep track of issues like that. As you
> already notice it's not a blocker but maybe a "major". The earlier we
> know what needs to be done; the better.
>
> -Matthias
>
> On 8/2/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
> > Hello,
> >
> > Sould I post a trivial priority issue on JIRA about what Trinidad put in
> > the following map: RequestMap, SessionMap, ApplicationMap and
> > AttributeMap? JSF 1.2 specifies <String, Object> for all of them while
> > Trinidad uses <Object, Object>. Since we don't plan to switch to 1.2 soon
> > it's not a big deal yet, but I think we should keep it in mind so we know
> > some changes will be required to conform to 1.2 spec.
> >
> >
> > Simon Lessard
> > Fujitsu Consulting
> >
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>
Re: JSF 1.2 vs. RequestMap, SessionMap, ApplicationMap and AttributeMap
Posted by Matthias Wessendorf <ma...@apache.org>.
Hi Simon,
I think it is not a bad idea to keep track of issues like that. As you
already notice it's not a blocker but maybe a "major". The earlier we
know what needs to be done; the better.
-Matthias
On 8/2/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
> Hello,
>
> Sould I post a trivial priority issue on JIRA about what Trinidad put in
> the following map: RequestMap, SessionMap, ApplicationMap and
> AttributeMap? JSF 1.2 specifies <String, Object> for all of them while
> Trinidad uses <Object, Object>. Since we don't plan to switch to 1.2 soon
> it's not a big deal yet, but I think we should keep it in mind so we know
> some changes will be required to conform to 1.2 spec.
>
>
> Simon Lessard
> Fujitsu Consulting
>
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
JSF 1.2 vs. RequestMap, SessionMap, ApplicationMap and AttributeMap
Posted by Si...@DMR.CA.
Hello,
Sould I post a trivial priority issue on JIRA about what Trinidad put in
the following map: RequestMap, SessionMap, ApplicationMap and
AttributeMap? JSF 1.2 specifies <String, Object> for all of them while
Trinidad uses <Object, Object>. Since we don't plan to switch to 1.2 soon
it's not a big deal yet, but I think we should keep it in mind so we know
some changes will be required to conform to 1.2 spec.
Simon Lessard
Fujitsu Consulting
Re: Re: [Proposal] trinidad-skinning module
Posted by Adam Winer <aw...@gmail.com>.
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 <ca...@gmail.com> wrote:
> Hi Mike,
>
> Thanks! stay tuned, more to come...
>
> On 7/31/06, Mike Kienenberger <mk...@gmail.com> wrote:
> >
> > Catalin,
> >
> > Sounds great! That's definitely part of the task of merging Tomahawk
> > and Trinidad.
> >
> > On 7/31/06, Catalin Kormos <ca...@gmail.com> 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
> > >
> > >
> >
>
>
Re: [Proposal] trinidad-skinning module
Posted by Catalin Kormos <ca...@gmail.com>.
Hi Mike,
Thanks! stay tuned, more to come...
On 7/31/06, Mike Kienenberger <mk...@gmail.com> wrote:
>
> Catalin,
>
> Sounds great! That's definitely part of the task of merging Tomahawk
> and Trinidad.
>
> On 7/31/06, Catalin Kormos <ca...@gmail.com> 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
> >
> >
>
Re: [Proposal] trinidad-skinning module
Posted by Catalin Kormos <ca...@gmail.com>.
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, Simon_Lessard@dmr.ca <Si...@dmr.ca> 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" <mk...@gmail.com>
> 2006-07-31 14:36
> Please respond to adffaces-dev
>
> To: adffaces-dev@incubator.apache.org
> 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 <ca...@gmail.com> 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
> >
> >
>
>
>
Re: [Proposal] trinidad-skinning module
Posted by Si...@DMR.CA.
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" <mk...@gmail.com>
2006-07-31 14:36
Please respond to adffaces-dev
To: adffaces-dev@incubator.apache.org
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 <ca...@gmail.com> 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
>
>
Re: [Proposal] trinidad-skinning module
Posted by Mike Kienenberger <mk...@gmail.com>.
Catalin,
Sounds great! That's definitely part of the task of merging Tomahawk
and Trinidad.
On 7/31/06, Catalin Kormos <ca...@gmail.com> 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
>
>