Hello again Jeanne,
I see... It does less than I was thinking, but I think the issue I was
seeing can still happen if the renderer you want to use also uses the
resourceKeyMap. Let say that menuBar has "af|menuBar" and
"af|menuBar::something" classes. However, the something is actually
rendered
by another renderer, so I would map "somethingOriginalKey" to
"af|menuBar::something" right? Let say that I want to create XYZ
component
and use menuBar renderer. I would have to map "af|XYZ" and
"af|XYZ::something" with the equivalent menuBar classes right?
However, with
the current pattern would it not end with:
"af|XYZ" and "af|menuBar::something" being used while "af|XYZ" and
"af|XYZ::something" should be what we wanted?
Thanks for the nice explanation, it cleared some gray zones,
~ Simon
On 8/21/06, Jeanne Waldman <[EMAIL PROTECTED]> wrote:
Hi Simon,
This pattern was introduced to handle the case where we are using the
same renderer to render different components, but we want to make sure
the style classes that get rendered are for the correct component. If
I'm writing a renderer for the XYZ component, and I want to use the
menuBar renderer code, then I would map the menuBar style classes to XYZ
style classes. That way I'll get XYZ style classes for my XYZ component.
If a renderer doesn't share rendering code, then they don't need to do
this.
Another thing the renderer could do is to use renderer delegation. Then,
the renderer could have a inner class that overrides the MenuBar
renderer, for example, and overrides the methods which return style
classes (this assumes there are appropriate hooks for this in the
renderer you are overriding, which probably isn't the case)
I don't understand your grandparent example well enough to comment on
it. First I wanted to be sure you understand what the purpose of this
map is.
- Jeanne
Simon Lessard wrote:
> Hello all,
>
> It seems that most renderers use
> RenderingContext.setSkinResourceKeyMap to
> temporarily alter the skin selectors used by their children. The use
> case is
> almost always :
>
> Map original = RenderingContext.getSkinResourceKeyMap();
> RenderingContext.setSkinResourceKeyMap(newMap);
> // do some work
> RenderingContext.setSkinResourceKeyMap(original);
>
> I see three problems with that pattern.
> First, there's no way to enforce it.
>
> Secondly, it can lead to some unworking case. Imagine we have
something
> like:
>
> <grand-parent>
> <parent>
> <child/>
> </parent>
> </grand-parent>
>
> Now let say child uses "af|component", "af|component::part" and
> "af|component::part:state" selectors. Let assume that grand-parent
> redirects
> "af|component" to "GrandParentReplacement" and parent redirects
> "af|component::part" to "ParentReplacement" and
> "af|component::part:state"
> to "af|component". The above pattern will result in the following
> redirections:
> - "af|component" --> not redirected
> - "af|component::part" --> "ParentReplacement"
> - "af|component::part:state" --> "af|component"
>
> However, the above result is most likely not what was wanted. I
> believe it
> should be more like:
> - "af|component" --> "GrandParentReplacement"
> - "af|component::part" --> "ParentReplacement"
> - "af|component::part:state" --> "GrandParentReplacement"
>
> So I would suggest to change setSkinResourceKeyMap to
> pushSkinResourceKeyMap
> and add a popSkinResourceKeyMap as well as a
peekSkinResourceKeyMap. The
> selector resolution could then move through the whole redirection
> chain as
> well as simplify the code required inside renderer. The above code
would
> become:
>
> RenderingContext.pushSkinResourceKeyMap(newMap);
> // do some work
> RenderingContext.popSkinResourceKeyMap();
>
> The third problem I see with this pattern is that parents has to know
> what
> kind of children they will contain, which is really bad for the
component
> developers working outside Trinidad project but wanting to use its
> internal
> feature (yes I know, that API is not currently public). I don't see
any
> solution to this problem yet, but I believe we should find a
standardized
> way to handle children selector redirection because some Trinidad
> components
> seem a bit too strongly coupled together imho.
>
>
> Regards,
>
> ~ Simon
>
