new method on Skin class; new method on Icon class.

[Jeanne Waldman <je...@oracle.com>]

Actually, my question is, I need a new method on the Skin class, getIcons().
And in the Icon class, I need a new method, getContent().
This is for our client-side rendering, where we need to pass icon 
information to the client.

I need to get all icons that are on the skin, and get the content (<img 
src...> or TextIcon info)
to send to the client.

Also, I'm playing with the idea of generating the <img> markup in a way 
so that
the stuff the renderer specifies goes on a <span> and the stuff that 
comes from the
skinning definition goes on the <img>. This way we have a cleaner 
separation of what
came from the skin and what properties are from the skin's icon definition.
This will come in useful for our client-side rendering, as well. We'd 
only need to
pass the icon markup that came from the skin to the client.

Thoughts on this one?
(I'll probably need to add a getProperties() api as well, but one step 
at a time)

Thanks!
- Jeanne

Simon Lessard wrote:

> I will be all for a new Skin API, let make it an independant module!
>
> On 9/6/06, Jeanne Waldman <je...@oracle.com> wrote:
>
>>
>> I can see your point about ending with 'icon' being confusing, but I
>> prefer to leave this
>> alone for now.
>>
>> I'll go ahead and add support for the :hover/etc on the icon skinning
>> keys.
>>
>> (I have another issue that goes with this one (new Skin api), but I'll
>> start a new thread)
>>
>> - Jeanne
>>
>> Simon Lessard wrote:
>>
>> > +1 for the idea. However I have some concerns about it.
>> >
>> > 1) If we were earlier in the skinning design I would have preferred
>> > icon and
>> > aliases to be namespaces, for example:
>> >
>> > icon|af|train::stop:visited
>> > alias|SomeName
>> >
>> > Ok, the 2 namespaces thing in the first example does not look all that
>> > cool,
>> > but it's easier to standardise that way imho. As for the icon 
>> aliases I
>> > would not have treated it in a different way than other aliases. Any
>> > given
>> > icon selector would have included the alias and then after parsing, 
>> the
>> > content property value would have been resolved for the icon selector
>> > without needing any special processing. Even better would have been to
>> > use
>> > @namespace but that could mean too much changes to the parser. However
>> it
>> > will be hard to find something cleaner than the following
>> >
>> > @namespace rlt {
>> >    /* Add some selectors */
>> >    @namespace icon {
>> >        af|train::stop:visited {
>> >        }
>> >    }
>> > }
>> >
>> > 2) The "check if it has -icon:" might irritates some developers over
>> > time,
>> > they already have many special patterns to learn and adding more means
>> > more
>> > complexity. Also, if this is the solution we choose whenever a need 
>> for
>> a
>> > new feature show up, I believe it will look like a bad design in 
>> term of
>> > extensibility.
>> >
>> >
>> > Regards,
>> >
>> > ~ Simon
>> >
>> > On 9/6/06, Jeanne Waldman <je...@oracle.com> wrote:
>> >
>> >>
>> >> Hi there,
>> >>
>> >> Right now, as I know some of you are aware, you can't create an icon
>> >> skinning key like this:
>> >>
>> >> af|foo::some-icon:hover
>> >>
>> >> Since it doesn't end in "icon" or "Icon:alias", the parser will
>> consider
>> >> it a styleclass.
>> >>
>> >> I'd like to add the ability to add :hover and :active to the end 
>> of an
>> >> icon skinning key and keep it an icon. :)
>> >> (We have a requirement in our 'rich' renderers to change icons on 
>> mouse
>> >> over and on mouse down.)
>> >>
>> >> Since we 'pass through' all css-2 pseudo-classes, we pass through
>> :hover
>> >> and :active to the skinning key.
>> >>
>> >> The quick and easy change I was going to make is in the code where I
>> >> decide if something is an icon or not.
>> >> Right now I check for if it ends with -icon or Icon:alias.
>> >>
>> >> I can change it to
>> >> check if it ends with -icon - OR -
>> >> check if it has -icon: in it OR
>> >> check if it has Icon:alias: in it.
>> >>
>> >> Thoughts?
>> >>
>> >> - Jeanne
>> >>
>> >>
>> >
>>
>>
>

Re: IconRenderer

[Adam Winer <aw...@gmail.com>]

A new shuttle renderer would be a biiiiig improvement...  I think
a lot of code is mostly still necessary because of that one renderer.

BTW, if you run the build in Maven after deleting something
like IconRenderer, you'll get a failure running the CoreRenderKitTest;
so even though this class is dynamically loaded, there's good
safeguards in place to make sure we won't delete anything that
is still used.

-- Adam


On 9/12/06, Simon Lessard <si...@gmail.com> wrote:
>
> Good to know, I'll add that renderer on the TODO list. I think there's
> also
> the processChoiceBar that need one.
>
> On 9/12/06, Jeanne Waldman <je...@oracle.com> wrote:
> >
> > I see now what the old IconRenderer is used for; the shuttle renderers
> > are not
> > yet faces-major and they use the old IconRenderer code.
> >
> > Simon Lessard wrote:
> >
> > > We have many old renderers in the ui package system that are not used
> > > anymore and could be cleared, but I don't know if adam want to do that
> > > already. I guess you could delete it if it prevents compilation, else
> it
> > > don't hurt to stay there until we kill the whole package tree, or at
> > > least
> > > until Adam is back.
> > >
> > >
> > > Regards,
> > >
> > > ~ Simon
> > >
> > > On 9/6/06, Jeanne Waldman <je...@oracle.com> wrote:
> > >
> > >>
> > >> Does anyone know why we have 2 IconRenderers... one in
> > >> org.apache.myfaces.trinidadinternal.ui.laf.base.xhtml; (non
> Faces-major
> > >> package)
> > >>
> > >> and one in
> > >> package org.apache.myfaces.trinidadinternal.renderkit.core.xhtml;
> > >> (Faces-major package)
> > >>
> > >> I can't tell if the non-Faces-major one is being used anywhere.
> > >>
> > >> Can I delete the non-Faces-major one?
> > >>
> > >> Thanks,
> > >> Jeanne
> > >>
> > >>
> > >>
> > >
> >
> >
>
>

Re: IconRenderer

[Simon Lessard <si...@gmail.com>]

Good to know, I'll add that renderer on the TODO list. I think there's also
the processChoiceBar that need one.

On 9/12/06, Jeanne Waldman <je...@oracle.com> wrote:
>
> I see now what the old IconRenderer is used for; the shuttle renderers
> are not
> yet faces-major and they use the old IconRenderer code.
>
> Simon Lessard wrote:
>
> > We have many old renderers in the ui package system that are not used
> > anymore and could be cleared, but I don't know if adam want to do that
> > already. I guess you could delete it if it prevents compilation, else it
> > don't hurt to stay there until we kill the whole package tree, or at
> > least
> > until Adam is back.
> >
> >
> > Regards,
> >
> > ~ Simon
> >
> > On 9/6/06, Jeanne Waldman <je...@oracle.com> wrote:
> >
> >>
> >> Does anyone know why we have 2 IconRenderers... one in
> >> org.apache.myfaces.trinidadinternal.ui.laf.base.xhtml; (non Faces-major
> >> package)
> >>
> >> and one in
> >> package org.apache.myfaces.trinidadinternal.renderkit.core.xhtml;
> >> (Faces-major package)
> >>
> >> I can't tell if the non-Faces-major one is being used anywhere.
> >>
> >> Can I delete the non-Faces-major one?
> >>
> >> Thanks,
> >> Jeanne
> >>
> >>
> >>
> >
>
>

Re: IconRenderer

[Jeanne Waldman <je...@oracle.com>]

I see now what the old IconRenderer is used for; the shuttle renderers 
are not
yet faces-major and they use the old IconRenderer code.

Simon Lessard wrote:

> We have many old renderers in the ui package system that are not used
> anymore and could be cleared, but I don't know if adam want to do that
> already. I guess you could delete it if it prevents compilation, else it
> don't hurt to stay there until we kill the whole package tree, or at 
> least
> until Adam is back.
>
>
> Regards,
>
> ~ Simon
>
> On 9/6/06, Jeanne Waldman <je...@oracle.com> wrote:
>
>>
>> Does anyone know why we have 2 IconRenderers... one in
>> org.apache.myfaces.trinidadinternal.ui.laf.base.xhtml; (non Faces-major
>> package)
>>
>> and one in
>> package org.apache.myfaces.trinidadinternal.renderkit.core.xhtml;
>> (Faces-major package)
>>
>> I can't tell if the non-Faces-major one is being used anywhere.
>>
>> Can I delete the non-Faces-major one?
>>
>> Thanks,
>> Jeanne
>>
>>
>>
>

Re: IconRenderer

[Simon Lessard <si...@gmail.com>]

We have many old renderers in the ui package system that are not used
anymore and could be cleared, but I don't know if adam want to do that
already. I guess you could delete it if it prevents compilation, else it
don't hurt to stay there until we kill the whole package tree, or at least
until Adam is back.


Regards,

~ Simon

On 9/6/06, Jeanne Waldman <je...@oracle.com> wrote:
>
> Does anyone know why we have 2 IconRenderers... one in
> org.apache.myfaces.trinidadinternal.ui.laf.base.xhtml; (non Faces-major
> package)
>
> and one in
> package org.apache.myfaces.trinidadinternal.renderkit.core.xhtml;
> (Faces-major package)
>
> I can't tell if the non-Faces-major one is being used anywhere.
>
> Can I delete the non-Faces-major one?
>
> Thanks,
> Jeanne
>
>
>

Re: embed key in Icon API - nix it?

[Jeanne Waldman <je...@oracle.com>]

I'm going to hold off on this. It seems to be used more than I thought, 
and it isn't necessary for my work
after all.
I do think we should get rid of the ALIGN constant, since the html align 
attribute is deprecated,
but this is a clean-up task.

- Jeanne

Simon Lessard wrote:

> +1
>
> On 9/6/06, Jeanne Waldman <je...@oracle.com> wrote:
>
>>
>> I really doubt that anyone is using the embed property that is in the
>> TextIcon code.
>> The only renderer I see that is using it is the IconRenderer.
>> As part of the work to create <span> with attributes from the renderer
>> and <img>/Text with attributes
>> from the skinning definition, I'd like to get rid of the embed property
>> that is in the TextIcon.
>> Any objections? This is a private API right now, which is why I doubt it
>> is being used.
>>
>> - Jeanne
>>
>> Jeanne Waldman wrote:
>>
>> > Does anyone know why we have 2 IconRenderers... one in
>> > org.apache.myfaces.trinidadinternal.ui.laf.base.xhtml; (non
>> > Faces-major package)
>> >
>> > and one in
>> > package org.apache.myfaces.trinidadinternal.renderkit.core.xhtml;
>> > (Faces-major package)
>> >
>> > I can't tell if the non-Faces-major one is being used anywhere.
>> >
>> > Can I delete the non-Faces-major one?
>> >
>> > Thanks,
>> > Jeanne
>> >
>> >
>> >
>>
>>
>

Re: embed key in Icon API - nix it?

[Simon Lessard <si...@gmail.com>]

+1

On 9/6/06, Jeanne Waldman <je...@oracle.com> wrote:
>
> I really doubt that anyone is using the embed property that is in the
> TextIcon code.
> The only renderer I see that is using it is the IconRenderer.
> As part of the work to create <span> with attributes from the renderer
> and <img>/Text with attributes
> from the skinning definition, I'd like to get rid of the embed property
> that is in the TextIcon.
> Any objections? This is a private API right now, which is why I doubt it
> is being used.
>
> - Jeanne
>
> Jeanne Waldman wrote:
>
> > Does anyone know why we have 2 IconRenderers... one in
> > org.apache.myfaces.trinidadinternal.ui.laf.base.xhtml; (non
> > Faces-major package)
> >
> > and one in
> > package org.apache.myfaces.trinidadinternal.renderkit.core.xhtml;
> > (Faces-major package)
> >
> > I can't tell if the non-Faces-major one is being used anywhere.
> >
> > Can I delete the non-Faces-major one?
> >
> > Thanks,
> > Jeanne
> >
> >
> >
>
>

embed key in Icon API - nix it?

[Jeanne Waldman <je...@oracle.com>]

I really doubt that anyone is using the embed property that is in the 
TextIcon code.
The only renderer I see that is using it is the IconRenderer.
As part of the work to create <span> with attributes from the renderer 
and <img>/Text with attributes
from the skinning definition, I'd like to get rid of the embed property 
that is in the TextIcon.
Any objections? This is a private API right now, which is why I doubt it 
is being used.

- Jeanne

Jeanne Waldman wrote:

> Does anyone know why we have 2 IconRenderers... one in
> org.apache.myfaces.trinidadinternal.ui.laf.base.xhtml; (non 
> Faces-major package)
>
> and one in
> package org.apache.myfaces.trinidadinternal.renderkit.core.xhtml; 
> (Faces-major package)
>
> I can't tell if the non-Faces-major one is being used anywhere.
>
> Can I delete the non-Faces-major one?
>
> Thanks,
> Jeanne
>
>
>

IconRenderer

[Jeanne Waldman <je...@oracle.com>]

Does anyone know why we have 2 IconRenderers... one in
org.apache.myfaces.trinidadinternal.ui.laf.base.xhtml; (non Faces-major 
package)

and one in
package org.apache.myfaces.trinidadinternal.renderkit.core.xhtml; 
(Faces-major package)

I can't tell if the non-Faces-major one is being used anywhere.

Can I delete the non-Faces-major one?

Thanks,
Jeanne

Re: new method on Skin class; new method on Icon class.

[Simon Lessard <si...@gmail.com>]

Oh well, I was thinking about bigger changes. Those are not too hard to
implements and should not affect the performance at all.

So +1.


Regards,

~ Simon

On 9/6/06, Jeanne Waldman <je...@oracle.com> wrote:
>
> Actually, my question is, I need a new method on the Skin class,
> getIcons().
> And in the Icon class, I need a new method, getContent().
> This is for our client-side rendering, where we need to pass icon
> information to the client.
>
> I need to get all icons that are on the skin, and get the content (<img
> src...> or TextIcon info)
> to send to the client.
>
> Also, I'm playing with the idea of generating the <img> markup in a way
> so that
> the stuff the renderer specifies goes on a <span> and the stuff that
> comes from the
> skinning definition goes on the <img>. This way we have a cleaner
> separation of what
> came from the skin and what properties are from the skin's icon
> definition.
> This will come in useful for our client-side rendering, as well. We'd
> only need to
> pass the icon markup that came from the skin to the client.
>
> Thoughts on this one?
> (I'll probably need to add a getProperties() api as well, but one step
> at a time)
>
> Thanks!
> - Jeanne
>
> Simon Lessard wrote:
>
> > I will be all for a new Skin API, let make it an independant module!
> >
> > On 9/6/06, Jeanne Waldman <je...@oracle.com> wrote:
> >
> >>
> >> I can see your point about ending with 'icon' being confusing, but I
> >> prefer to leave this
> >> alone for now.
> >>
> >> I'll go ahead and add support for the :hover/etc on the icon skinning
> >> keys.
> >>
> >> (I have another issue that goes with this one (new Skin api), but I'll
> >> start a new thread)
> >>
> >> - Jeanne
> >>
> >> Simon Lessard wrote:
> >>
> >> > +1 for the idea. However I have some concerns about it.
> >> >
> >> > 1) If we were earlier in the skinning design I would have preferred
> >> > icon and
> >> > aliases to be namespaces, for example:
> >> >
> >> > icon|af|train::stop:visited
> >> > alias|SomeName
> >> >
> >> > Ok, the 2 namespaces thing in the first example does not look all
> that
> >> > cool,
> >> > but it's easier to standardise that way imho. As for the icon
> >> aliases I
> >> > would not have treated it in a different way than other aliases. Any
> >> > given
> >> > icon selector would have included the alias and then after parsing,
> >> the
> >> > content property value would have been resolved for the icon selector
> >> > without needing any special processing. Even better would have been
> to
> >> > use
> >> > @namespace but that could mean too much changes to the parser.
> However
> >> it
> >> > will be hard to find something cleaner than the following
> >> >
> >> > @namespace rlt {
> >> >    /* Add some selectors */
> >> >    @namespace icon {
> >> >        af|train::stop:visited {
> >> >        }
> >> >    }
> >> > }
> >> >
> >> > 2) The "check if it has -icon:" might irritates some developers over
> >> > time,
> >> > they already have many special patterns to learn and adding more
> means
> >> > more
> >> > complexity. Also, if this is the solution we choose whenever a need
> >> for
> >> a
> >> > new feature show up, I believe it will look like a bad design in
> >> term of
> >> > extensibility.
> >> >
> >> >
> >> > Regards,
> >> >
> >> > ~ Simon
> >> >
> >> > On 9/6/06, Jeanne Waldman <je...@oracle.com> wrote:
> >> >
> >> >>
> >> >> Hi there,
> >> >>
> >> >> Right now, as I know some of you are aware, you can't create an icon
> >> >> skinning key like this:
> >> >>
> >> >> af|foo::some-icon:hover
> >> >>
> >> >> Since it doesn't end in "icon" or "Icon:alias", the parser will
> >> consider
> >> >> it a styleclass.
> >> >>
> >> >> I'd like to add the ability to add :hover and :active to the end
> >> of an
> >> >> icon skinning key and keep it an icon. :)
> >> >> (We have a requirement in our 'rich' renderers to change icons on
> >> mouse
> >> >> over and on mouse down.)
> >> >>
> >> >> Since we 'pass through' all css-2 pseudo-classes, we pass through
> >> :hover
> >> >> and :active to the skinning key.
> >> >>
> >> >> The quick and easy change I was going to make is in the code where I
> >> >> decide if something is an icon or not.
> >> >> Right now I check for if it ends with -icon or Icon:alias.
> >> >>
> >> >> I can change it to
> >> >> check if it ends with -icon - OR -
> >> >> check if it has -icon: in it OR
> >> >> check if it has Icon:alias: in it.
> >> >>
> >> >> Thoughts?
> >> >>
> >> >> - Jeanne
> >> >>
> >> >>
> >> >
> >>
> >>
> >
>
>

Re: new method on Skin class; new method on Icon class.

[Simon Lessard <si...@gmail.com>]

I think getIcons would still be nice in the future, especially if we make
the API public. It's far from critical though.


Regards,

~ Simon

On 9/21/06, Jeanne Waldman <je...@oracle.com> wrote:
>
> Thanks Adam, I realized that after sending this initial email, and now I
> have no need to get all the icons because I plan to go a different route
> to getting the icons to the client, so I am not planning to implement
> this api now.
>
> - Jeanne
>
> Adam Winer wrote:
>
> > getIcons() makes sense.  But getContent() - it'd be sufficient to
> > clone the current ResponseWriter with a StringWriter, and get the
> > contents that way.
> >
> > -- Adam
> >
> >
> > On 9/6/06, Jeanne Waldman <je...@oracle.com> wrote:
> >
> >>
> >> Actually, my question is, I need a new method on the Skin class,
> >> getIcons().
> >> And in the Icon class, I need a new method, getContent().
> >> This is for our client-side rendering, where we need to pass icon
> >> information to the client.
> >>
> >> I need to get all icons that are on the skin, and get the content (<img
> >> src...> or TextIcon info)
> >> to send to the client.
> >>
> >> Also, I'm playing with the idea of generating the <img> markup in a way
> >> so that
> >> the stuff the renderer specifies goes on a <span> and the stuff that
> >> comes from the
> >> skinning definition goes on the <img>. This way we have a cleaner
> >> separation of what
> >> came from the skin and what properties are from the skin's icon
> >> definition.
> >> This will come in useful for our client-side rendering, as well. We'd
> >> only need to
> >> pass the icon markup that came from the skin to the client.
> >>
> >> Thoughts on this one?
> >> (I'll probably need to add a getProperties() api as well, but one step
> >> at a time)
> >>
> >> Thanks!
> >> - Jeanne
> >>
> >> Simon Lessard wrote:
> >>
> >> > I will be all for a new Skin API, let make it an independant module!
> >> >
> >> > On 9/6/06, Jeanne Waldman <je...@oracle.com> wrote:
> >> >
> >> >>
> >> >> I can see your point about ending with 'icon' being confusing, but I
> >> >> prefer to leave this
> >> >> alone for now.
> >> >>
> >> >> I'll go ahead and add support for the :hover/etc on the icon
> skinning
> >> >> keys.
> >> >>
> >> >> (I have another issue that goes with this one (new Skin api), but
> >> I'll
> >> >> start a new thread)
> >> >>
> >> >> - Jeanne
> >>
> >>
> >
>
>

Re: new method on Skin class; new method on Icon class.

[Jeanne Waldman <je...@oracle.com>]

Thanks Adam, I realized that after sending this initial email, and now I 
have no need to get all the icons because I plan to go a different route 
to getting the icons to the client, so I am not planning to implement 
this api now.

- Jeanne

Adam Winer wrote:

> getIcons() makes sense.  But getContent() - it'd be sufficient to
> clone the current ResponseWriter with a StringWriter, and get the
> contents that way.
>
> -- Adam
>
>
> On 9/6/06, Jeanne Waldman <je...@oracle.com> wrote:
>
>>
>> Actually, my question is, I need a new method on the Skin class,
>> getIcons().
>> And in the Icon class, I need a new method, getContent().
>> This is for our client-side rendering, where we need to pass icon
>> information to the client.
>>
>> I need to get all icons that are on the skin, and get the content (<img
>> src...> or TextIcon info)
>> to send to the client.
>>
>> Also, I'm playing with the idea of generating the <img> markup in a way
>> so that
>> the stuff the renderer specifies goes on a <span> and the stuff that
>> comes from the
>> skinning definition goes on the <img>. This way we have a cleaner
>> separation of what
>> came from the skin and what properties are from the skin's icon
>> definition.
>> This will come in useful for our client-side rendering, as well. We'd
>> only need to
>> pass the icon markup that came from the skin to the client.
>>
>> Thoughts on this one?
>> (I'll probably need to add a getProperties() api as well, but one step
>> at a time)
>>
>> Thanks!
>> - Jeanne
>>
>> Simon Lessard wrote:
>>
>> > I will be all for a new Skin API, let make it an independant module!
>> >
>> > On 9/6/06, Jeanne Waldman <je...@oracle.com> wrote:
>> >
>> >>
>> >> I can see your point about ending with 'icon' being confusing, but I
>> >> prefer to leave this
>> >> alone for now.
>> >>
>> >> I'll go ahead and add support for the :hover/etc on the icon skinning
>> >> keys.
>> >>
>> >> (I have another issue that goes with this one (new Skin api), but 
>> I'll
>> >> start a new thread)
>> >>
>> >> - Jeanne
>>
>>
>

Re: new method on Skin class; new method on Icon class.

[Adam Winer <aw...@gmail.com>]

getIcons() makes sense.  But getContent() - it'd be sufficient to
clone the current ResponseWriter with a StringWriter, and get the
contents that way.

-- Adam


On 9/6/06, Jeanne Waldman <je...@oracle.com> wrote:
>
> Actually, my question is, I need a new method on the Skin class,
> getIcons().
> And in the Icon class, I need a new method, getContent().
> This is for our client-side rendering, where we need to pass icon
> information to the client.
>
> I need to get all icons that are on the skin, and get the content (<img
> src...> or TextIcon info)
> to send to the client.
>
> Also, I'm playing with the idea of generating the <img> markup in a way
> so that
> the stuff the renderer specifies goes on a <span> and the stuff that
> comes from the
> skinning definition goes on the <img>. This way we have a cleaner
> separation of what
> came from the skin and what properties are from the skin's icon
> definition.
> This will come in useful for our client-side rendering, as well. We'd
> only need to
> pass the icon markup that came from the skin to the client.
>
> Thoughts on this one?
> (I'll probably need to add a getProperties() api as well, but one step
> at a time)
>
> Thanks!
> - Jeanne
>
> Simon Lessard wrote:
>
> > I will be all for a new Skin API, let make it an independant module!
> >
> > On 9/6/06, Jeanne Waldman <je...@oracle.com> wrote:
> >
> >>
> >> I can see your point about ending with 'icon' being confusing, but I
> >> prefer to leave this
> >> alone for now.
> >>
> >> I'll go ahead and add support for the :hover/etc on the icon skinning
> >> keys.
> >>
> >> (I have another issue that goes with this one (new Skin api), but I'll
> >> start a new thread)
> >>
> >> - Jeanne
>
>