Hmmm....
that could work.
the question is if it is any better than letting the component extend
from a marker interface and implement the functionality itself.
Thoughts?
regards,
Martin
On 1/20/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
> Hi
> > ad 1) no - not even protected is allowed. The problem is that you
> > don't want an application to rely on a certain implementation of the
> > api - you change the api, and nothing works anymore ;)
> >
> Ok, thats bad.
> > ad 2) yes, well, instanceof to UIData is bad. There I'm completely
> > d'accord with Simon. But an instanceof to an interface defining some
> > generic behaviour is pretty ok in my opinion. not marker interface
> > instead of instanceof, but instanceof to marker interface instead of
> > to UIData.
> >
> Ok, I understand.
>
> There is still one last idea, a little bit complicated, but this avoids
> this marker interface too.
> You could have a TraversePolicyProvider.
>
> Lets speak code:
>
> TraversePolicyFactroy.register(UIComponent.class, new
> TraverseComponentChildren());
> TraversePolicyFactroy.register(UIData.class, new TraverseDataChildren());
>
> Then on TraversePolicyFactroy:
> TraversePolicy create(UIComponent component)
> {
> find a TraversePolicy for component.getClass() or one of its super
> classes.
> return it;
> }
>
> Somewhat complicated, but hey it works. Is extensible and didnt need any
> change on the api and no marker interface.
>
>
> Ciao,
> Mario
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
