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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
>>
>>
>
