Ok, i might be jumping to another subject here, but how about modeling the trinidad selectors into objects?
If i understood correctly, the syntax is something like the following: namespace|component-selector::pseudo-element-selector:pseudo-class-selector:pseudo-class-selector:....:pseudo-class-selector This model could provide the string representation and the internal string representation. A list of such objects could end up beeing created by a configuration mechanism and registered in the Skin. I'm still thiking about an external configuration for the possible selectors and their internal representation :), cause i can't see any other way arround it for component authors beeing able to register additional styles. The Skin could provide the API methods to obtain and manage the list of possible selectors. Am i getting closer? :) Regards, Catalin On 8/4/06, Adam Winer <[EMAIL PROTECTED]> wrote:
But, your requirement #3: 3. allow components outside of the framework to provide their own mappings ... is a more general thing that's a major whole in skinning. There's no simple way for a component author to register additional styles to merge into skins. I think that's almost the #1 most important feature that could be added to skinning. -- Adam On 8/3/06, Adam Winer <[EMAIL PROTECTED]> wrote: > As a first pass, how about a plain Java API, provided by the > Skin? I think that architecturally it's important to first figure > out where the Java code lives, than think about XML configuration. > > I'm not totally convinced that your requirement #2 is necessary... > > -- Adam > > > On 8/3/06, Catalin Kormos <[EMAIL PROTECTED]> wrote: > > Hi there, > > > > It's been mentioned already that the mapping from public style selector > > names, which do not contain html, into trinidad's internal style selector > > names, would need to be moved outside of the FileSystemStyleCache class. I > > would like to ask you guys about this, as this is one of the main tasks that > > should be resolved for a more general skinning module. > > > > The requirements i can see are the following: > > > > 1. mapping should be transparent, preferably no changes on the > > StyleProvider API regarding this > > 2. mapping configuration made outside of the code > > 3. allow components outside of the framework to provide their own > > mappings > > > > On a short basis, my proposition is inspired by how Facelets taglibs are > > defined and loaded (for those who are familiar with this). > > > > Basicaly have a skinning selectors library file, in XML format, that will > > declare all the possible selector names and their internal names (internal > > names could be optional). Loading this type of files will be done > > automaticaly, by searching after files that have an extension like > > *.selectorslib.xm by scanning the /meta-inf folder in the jars. > > > > The format of a *selectorslib.xml file could be something like: > > <skinning-selectors> > > <namespace>af</namespace> > > <selector> > > <name>panelTabbed::tab-link</name> > > <internal-name>panelTabbed::tab A</internal-name> > > </selector> > > .............. > > </skinning-selectors> > > > > This will also allow more transparency on the possible selector names for a > > component, as there can be as many * selectorslib.xml files as components, > > or just one big file declaring them all. > > > > I'm more like scratching the surface for now, looking forward to your > > comments. > > > > Regards, > > Catalin > > > > >
