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 Si...@DMR.CA on 2006/07/27 15:45:15 UTC

Skin selectors naming conventions

Hello,

During the various exchanges I had with Jeanne about skins in the past she 
mentionned that now the synthax for skin selectors is something like:

af|myComponent:disabled, with ":state" synthax

However, I found out that navigation level uses selectors looking like:
af|navigationLevel:list-active-enabled
and
af|navigationLevel:list-active-disabled

Shouldn't that be renamed to something like (assuming we respect the 
convention followed by most component):
af|navigationLevel:selected::list
and
af|navigationLevel:disabled:selected::list

While we're in process of renaming many things, I think it would be a 
great time to define a truly strict naming convention for skin selectors 
as well. That way it could be possible to alter the skin engine in the 
future to include more automated features. One thing I could se for 
example is something like: getStyleClass(String rootStyleClass, String[] 
states). Such method would make easier to reuse renderStyle code by having 
children define a getRootStyleClass and getStates methods and 
automatically obtain the right skin style class. More importantly, a 
strict selector synthax will make it easier for new users to understand 
and use skin selectors.

Personnally, I would suggest the following synthax (a bit different than 
the one already used by most components):
<namespace>|<component>(::<renderOption>)?(::<componentPart>)?(:<state>)*

<namespace> ::= "af" only for now
<component> ::= component tag
<renderOption> ::= used when the component can be rendered in many ways, 
like "list", "tabs" and such for navigationLevel component
<componentPart> ::= used when the component is rendered as more than one 
html element, the most common would probably be "content"
<state> ::= disabled | required | selected | active | ... States should 
always be sorted alphabetically (or another fixed order) so there's no 
confusion possible on the order to use when the selector contains more 
than one state. A future improvement to the skin engine would be to make 
it unsensitive to order.

For navigationLevel, the selector would become something like : 
af|navigationLevel::list::content:disabled:selected

The main difference between the synthax I propose and the one used by some 
components already is placing the states at the end, rather than right 
after <component>. Semantically, both synthaxes can be read quite easily, 
but still have pros and cons. For example:

What is disabled and selected?
My proposal:
af|navigationLevel::list::content:disabled:selected (looks like the 
content is selected and disabled which is the case)
af|inputText::content:required (looks like the content is required, but in 
fact it's the inputText)

Other way:
af|navigationLevel:disabled:selected::list::content (looks like the 
navigationLevel is selected and disabled which is not the case)
af|inputText:required::content (perfectly understandable)


Still, I prefer placing the state at the end, but because of a very 
subjective reason. When I work, I tend to think first about what I want to 
change and then about its specific contextual state. Like, for the content 
of a required field, I'll first think about what I want to alter (the 
field's content) then I'll focus in what specific circumstance I want to 
apply the change (when the field is required).

Comments, suggestions, approbation, flame war =P ?


Regards,

Simon Lessard
Fujitsu Consulting