I agree with most of these statements, but I would start even higher than
that, like defining the base interfaces and access classes.
For instance, I think it's safe to assume that a Skin class or interface
should exists. Let assume all interfaces for now as it takes less
characters. Now, from where and how should the Skin be available for a given
FacesContext. Personally I believe a Skin should be linked to a RenderKit
(or a common base RenderKit class for all MyFaces extensions if not in the
standard), but let assume work on the API for now for the sake of the
discussion.
So for now we have:
public interface Skin
{
public String getResourceBundle();
}
public abstract class RenderKit
{
public abstract Skin getSkin(FacesContext context);
}
So far so good, but now that opens some issues that will themselves explode
into more:
1. Should the way the RenderKit locates the current Skin standardized?
2. How do we define the contract ensuring that the Skin get rendered on
the page?
3. What other functionalities should be standarized in the Skin
interface?
*Issue 1: Current skin localization*
Personally I chose yes to that question since it allow a standardized way to
define skins. Let use Trinidad's skin-family notion here, but with the way
renderKitId is defined, that's the view root and a factory implementing
decorator pattern. So we add
public class UIViewRoot
{
public String getSkinFamily();
public void setSkinFamily(String skinFamily);
}
public abstract class SkinFactory implements FacesWrapper<SkinFactory>
{
public abstract void addSkin(String skinFamily, String renderKitId, Skin
skin);
public abstract Skin getSkin(String skinFamily, String renderKitId);
public abstract Collection<String> getSkinFamilies();
public SkinFactory getWrapped()
{
return null;
}
}
*Sub-issue 1.1: Default SkinFactory implementation behavior*
Additional Exceptions
public class SkinException extends FacesException
{
// Provides all 4 common Exception constructors
}
public class SkinInitializationException extends SkinException
{
// Provides all 4 common Exception constructors
}
Additional interface
/**
* Implementations of this interface are in charge of creating Skin
instances in an implementation specific manner.
*/
public interface SkinLoader
{
/**
* Creates a new <code>Skin</code> instance the specified skinFamily and
parameters. There's no garanteed as of what
* parameters will be present in the Map argument and the creation
should fails if those parameters are not correct
* for the specific implementation.
*
* @throws SkinInitializationException if the provided parameter are not
enough to create the <code>Skin</code> instance
*/
public Skin loadSkin(String skinFamily, String resourceBundle,
Map<String, String> parameters);
}
Addition to faces-config.xml:
<application>
<default-skin-family/>
</application>
<skin>
<skin-family/>
<render-kit-id/>
<description/>
<skin-loader-class/>
<resource-bundle/>
<skin-loader-parameters>
<map-entries/>
</skin-loader-parameters>
</skin>
Note that this solution makes RenderKit.getSkin more an utility method than
anything, except if an extension decides to override it (would probably be
the casew ith Trinidad, at least to start to use trinidad-config.xml, or
later to add .pda or .desktop to the current skinFamily).
Also, the framework should probably provide some implementations of
SkinLoader out-of-the-box, most likely ClassSkinLoader expecting a skinClass
parameter and a CSSSkinLoader receiving a cssResourcePath parameter.
(Trinidad would mostl ikely provide an XSSSkinLoader for example)
*Issue 2: Skin content rendering*
How should rendering be handled? Should it be handled as an added
ResourceDependency just before rendering or as an additional contract for
the default HtmlRenderer for HtmlHead? The latter sounds better, but how
should it be implemented? target would obviously be "head", but then a
public Resource Skin.getContentResource() method could be required and this
might imply some changes to the ResourceHandler specification so that it can
locate the Skin instance in order to be able to serve the Resource's content
(effective CSS content) to the agent. I like the Resource version, but I
have more thinking to do about how to implement this, maybe involving a
reserved resourceIdentifier structure/syntax
*Issue 3: Skin features*
Additional class
public abstract class Icon extends Resource
{
/**
* Gets the key within the skin's ResourceBundle to the description of
this icon. The description can be used
* as an alternate text for the icon to improve accessibility for
example.
*/
public abstract String getDescriptionKey();
/**
* Gets the name of this icon.
*/
public abstract String getName();
/**
* Gets the effective style class of this icon within the skin.
*/
public abstract String getStyleClass();
}
public interface Skin
{
public Icon getIcon(String iconName);
public String getProperty(String propertyKey);
public String getResourceBundle();
public String getStyleClass(String selectorKey);
}
*Sub-issue 3.1: style class / property / icon access strategy*
Trinidad uses String keys to access style classes within the skin. That
strategy is very flexible, but alas very slow, thanks to String.hashCode()
being linear and uncached. So, even if String.intern() is called on all
selectors within a given skin, the gain will only be on String.equals,
making it O(1) instead of O(n). Even if this is better than nothing,
especially it there's a collision, the overall complexity of looking up a
selector remains O(n) with the length of the key. So, the overall cost of
skinning with this strategy is averageLengthOfKey *
averageAmountOfComponentPerPage * averageAmountOfHtmlElementPerComponent
(assuming each element gets its own style class which is required for
maximum customizability). Another, but a little bit more complex, solution
is also possible using a "dynamic enum" alike to PropertyKey in Trinidad. So
I'd like something like:
public abstract class SkinKeyPart
{
public String name();
public int ordinal();
}
public class Namespace extends SkinKeyPart
{
/**
* Find or create the Namespace instance with the specified name.
*/
public static Namespace getInstance(String name);
}
public class ComponentKey extends SkinKeyPart
{
/**
* Find or create the ComponentKey instance with the specified name.
*/
public static ComponentKey getInstance(String name);
}
public class ComponentPartKey extends SkinKeyPart
{
/**
* Find or create the ComponentPartKey instance with the specified name.
*/
public static ComponentPartKey getInstance(String name);
}
public class ComponentStateKey extends SkinKeyPart
{
/**
* Find or create the ComponentStateKey instance with the specified
name.
*/
public static ComponentPartKey getInstance(String name);
}
public abstract class SkinNode
{
public abstract String[] getStyleClasses();
public abstract String getProperty(String propertyName);
public abstract Icon getIcon(String iconName);
public abstract SkinNode getSubPart(ComponentPartKey partKey);
}
public interface Skin
{
/**
* Still exists to get properties global to the whole skin if someone
ever need that feature
*/
public String getProperty(String propertyName);
/**
* No change here
*/
public String getResourceBundle();
public String getSkinNode(Namespace ns, ComponentKey component);
public String getSkinNode(Namespace ns, ComponentKey component,
ComponentStateKey state);
public String getSkinNode(Namespace ns, ComponentKey component,
ComponentStateKey... states);
}
That solution has the advantage of being very fast, actually a real O(1) for
every node access assuming the Renderer gathers the keys it needs during
instanciation. Then the "root" SkinNode could probably be located using a
base Renderer class and passed to a custom encoding method (Trinidad's
encodeAll for example). Of course, the skin loaders would have to create
skin instances structuring the selectors accordingly. A base class for Skin
with such feature should probably be provided if this solution is wanted in
order to make new implementation of Skin easier to create.
*PENDIND issues:*
PENDING: Should the path leverage the Resource API instead and receive a
library-name, library-version, resource-name and resource-version instead?
PENDING: A CompositeSkin class should probably be provided and most likely
usable from the configuration, should it be using a specific loader with
parameters or have a fully-fledged tag like <composite-skin> for example?
The use of such skin implementation would be for users using multiple
libraries, each with very different RenderKit implementations. A composite
RenderKit class could also be useful here.
PENDING: Should Trinidad's SkinAddition notion be considered? SkinAddition
provides a way to add skin elements to an existing skin based on its id. It
would be possible to leverage that by using the skin-family/render-kit-id
tuple instead. Another option would be to simply have the default
SkinFactory implementation to automatically agreggate the Skin instances
with the same skin-family and render-kit-id into a CompositeSkin instance.
PENDING: Should additional metadata be added to <renderer> tag to define the
supported skin selector for tooling purpose? This point is dependant on the
content of the Skin interface and the strategy chosen to access the
properties/style class of a given component and/or one of its sub-element.
PENDING: Should the effective CSS properties stay accessible in memory or
otherwise from the Skin instance? If so, should they be modifiable? I tend
toward no for both for performance issues. Of course this could be also left
as an optional operation of the interface, throwing
UnsupportedOperationException in most case but at least leaving the
possibility for special implementations requiring it. This point also impact
issue 2 in some ways.
PENDING: About Icon, it should probably also leverage the Resource API, how
should that be implemented?
PENDING: Icon's styleClass, should the instance directly return an effective
class or should it rather return a selector that would then be looked up
from the Skin? I prefer the latter, but then there's the Stirng issue so
maybe the icon would have to return an optimized selector key as mentioned
in 3.1
PENDING: Solution to issue 3.1, although very fast and flexible, can be an
linkage nightmare. For example, a node for component "inputText" with states
"disabled" and "required" should be able to link to the component part node
for part "label" of "inputText" without any state defined if needed. The
performance gain of 3.1 is great, the implementation complexity isn't.
Still, personally I don't have any problem throwing complexity at
implementor's head if the users can feel the difference. Another option
would be to remove the "state" complexity part and have a predefined style
class syntax for those. That solution is what Trinidad does. However, this
solution is not as flexible as it doesn't allow to switch Icon dynamically
depending on the component's state.
PENDING: Solution 3.1 don't allow state to be applied on the component's sub
parts. Most of the time it's not an issue, but we have one such use case
with Trinidad's train component where the train itself doesn't have a state,
but each of its station (sub-part) can be visited/unvisited and/or selected
and/or disabled. If 3.1 is kept, should it be tweaked even more to allow a
sub-part state on a per part basis as well? This makes the linkage a
nightmare on Elm Street candidate, althoguh adding more potential to the
Skin
PENDING: Trinidad supports a "selector redirect" feature that is used with
the delegate renderer architecture to have specified selectorKeys
transformed into a different one. This is implemented as a Map<String
oldName, String newName> redirection map. Should such feature be
standardized? If so and 3.1 is adressed then it will have to be well thought
about. Also, trinidad support a single of those map applied as a set on the
skin instance, I believe it should be a push / pop instead if standardized.
PENDING: Should there be any inheritance/cascading behavior defined by
default? I tend toward no here.
PENDING: Should the skin have a getTranslatedResource(FacesContext context,
String resourceKey) instead of the getResourceBundle method?
That's about it for now. My main blocker is 3.1 and I'd like to come up with
something better for it before presenting it to the EG, same holds true with
various links to the Resource API (icons, the skin itself, etc)
Regards,
~ Simon
On Fri, Dec 5, 2008 at 10:33 AM, Andrew Robinson <
[EMAIL PROTECTED]> wrote:
> > All other frameworks use
> > component attributes for this, but Trinidad puts it in these
> > non-intuitive skinning keys.
>
> Sorry, had one more comment right after I hit send again. Maybe just
> having default component attributes for a web app would satisfy the
> need. Like a way to say 'partialSumbit' should be defaulted to true on
> all tr:commandLink. Then all the skin properties could be converted to
> attributes and have their defaults set in a common location (like what
> the skin does).
>
> This would be much more useful and flexible as then page developers
> can make exceptions to the rule.
>
