A definite +1 to no more implementing of interfaces (already the
practice for XhtmlConstants, if not XhtmlLafConstants). I'd
also like to see constants that are referenced by code in
renderkit.core.xhtml moved out of XhtmlLafConstants or
UIConstants and out to XhtmlConstants. But -1 to any sort
of a wholesale move, since a lot of the stuff in UIConstants and
XhtmlLafConstants are just obsolete.
I'm +0 on having XhtmlElements or XhtmlAttributes constants.
I've just never felt the urge to type XhtmlElements.TABLE_DATA
instead of just "td". String constants aren't *always* evil; for
things that are well known and universal knowledge (like HTML
element names) there's little gained (and much ease-of-development
lost) in pushing the names into constants. People can use 'em if
they want, but I'd be -1 on requiring their use.
-1 to using the names of Trinidad component attribute names,
facets, or attribute values; these constants exist directly on the
generated components (or should), so it's unnecessary to
define extra constants. Most common JSF attribute names - like
"value" and "required" - are also unnecessary, as a cast to
ValueHolder or EditableValueHolder is usually a better approach
than using the names.
-- Adam
On 8/11/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Heya all,
I got another possible maintenance task I would like to discuss about.
Currently, most constants are concentrated in 2 interfaces located in ui
package structure, namely
org.apache.myfaces.trinidadinternal.ui.laf.base.xhtml.XhtmlLafConstants
and org.apache.myfaces.trinidadinternal.ui.UIConstants.
Considering those package are doomed, I think it would be a nice and not
so complicated task to start moving all the constants those two classes
contain in a better one no longer located under those directories. Also, I
think it would be better to use non-instanciable classes rather than
interface so that it's impossible to implements/extends them for easy
access to the constants. This would increase the complexity of the
refactoring but in the end I believe it would make the code easier to
read.
Of course, this could be done in 2 different tasks, first moving the
constants to new interfaces and make
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.XhtmlConstants
extends them to keep backward compatibility with the old structure, then
changing interfaces to classes one by one to reduce impact.
Anyway, the main question I see about it is what kind of structure should
be used. Personally I would like to see something like:
- SkinSelectors containing all and only skin selectors used by Trinidad
(cannot of course include selectors of user made components).
- XhtmlElements containing all valid xhtml tags.
- XhtmlAttributes containing all valid xhtml attributes.
- XhtmlAttributeValues containing all valid predefined attributes values
("middle", "left", "right", etc.)
- JsfAttributes containing most common jsf component attributes
("required", "value", "title", etc.)
- TrinidadAttributes containing most common Trinidad component attributes
("partialTriggers", "showRequired", "inlineStyle", etc.)
- TrinidadFacets containing most common Trinidad component facets ("help",
"nodeStamp", "branding", etc.)
Regards,
Simon Lessard
Fujitsu Consulting
