Jerome Velociter wrote: As far as I see, this set of icons has a couple of emoticons, too.

On Feb 19, 2009, at 4:28 PM, Dan Miron wrote: IMO the mapping between names and resources is the role of the macro itself, so it can have a map to do whatever mapping it needs. Of course it means users cannot add new resources without changing the macro but I think simplicity is better than genericity here in this case. We could make it generic too by doing the following: * Create a {{image}} macro that takes a "location" parameter. This location is relative to the resources directory in the webapp. For example: {{image location="icons/silk/arrow_out.gif"/}} * Create a {{icon}} macro that extends the image macro but only offers a "name" parameter. This macro will do the mapping between names and image resources. WDYT? Thanks -Vincent

On Feb 19, 2009, at 4:55 PM, Sergiu Dumitriu wrote: Yes true. We have an api to get resources inside the resources/ dir but it's an internal api and it should stay internal. I agree that it's a bit too open and thus dangerous. I thus remove this proposal. Thanks -Vincent http://xwiki.com http://xwiki.org http://massol.net

Vincent Massol wrote: I was referring to image: arrow_out.gif, or just image: arrow_out (although this second one would be even more complicated). Of course is not core, but I don't see why two, and, as a user, I think I'd find it hard to grasp when {{icon}} and when image: and why not only one of them. This shouldn't be a stopper anyway, it's not that that important... Happy coding, Anca Luca

Guys, this is what I'm thinking of after reading your proposals: - the macro to look like {{icon name="smile" /}}, thus having a mapping between the name parameter and the image file - having a base set of icons from the silk icon set - allowing plugging in other icon sets, too So, there you have a sketch on how the macro would look like: class IconMacro implements Macro { List<Block> execute(IconMacroParameters parameters) { Map resources = getResourcesMap(); return new ImageBlock(resources.get(parameters.getName())); } Map getResourcesMap() { // uses IconResourceDiscoverer to dinamically build the icon set and the mapping between names / icon URLs } } class AbstractIconResource { public abstract Map<String, URL> getResourcesMap(); } class DefaultIconResource extends AbstractIconResource { // gets the the default icon set from silk // ..................... } //singleton class class IconResourceDiscoverer { public Map<String, URL> loadIcons() { foreach (Class c which extends AbstractIconResource) { c.getResourcesMap(); } return all the grabbed resources; } } - optionally, we can put the IconResourceDiscoverer and the DefaultIconResource in a component if we're going to need using icons in other features too. - if we want to take care of the ambiguities (e.g. multiple icons with the same name located in different icon sets) we can add an optional parameter to the macro called "iconSet" or how else you prefer which to allow explicitly specifying the icon set (the default one being Silk) Please tell me what you think, 'cause i'm keen on starting working on it :-) Tnx, Dan

Vincent Massol wrote: Yes, sounds good. "silk" should be the default value for the "set" parameter of the macro. The resource set implementation can be responsible to add the correct file extension too, so that you call {{icon name="cog"}} and not {{icon name="cog.gif"}} Jerome.

Vincent Massol wrote: Shouldn't the implementation rather be DefaultSkinIconResourceSet and we configure the path and extension for silk in the component description ? I don't see what can be specific to silk here. Jerome