If that's what you want, why not do something simple like this?

public interface IComponentFactory {

   Button createButton(MarkupContainer parent, String id);
}

class YuiComponentFactory implements IComponentFactory {

  public Button createButton(MarkupContainer parent, String id) {
    return new YuiButton(parent, id);
  }
}

I think the framework is flexible enough to be able to do without the
added complexity of having things like renderers. I think if we'd use
such patterns too much, it will only confuse people. The cases where
it does make sense, like with choice renderers, request cycle
processor etc, we use that pattern. What concrete delegates did you
have in mind?

Eelco




On 7/5/06, Ittay Dror <[EMAIL PROTECTED]> wrote:
> everything is doable, the question is about design (not if i can make it 
> work, but if i can make it work reusing code, easy to change etc.)
>
> say i have YuiButton and YuiMenu, both need to contribute the same js to the 
> header. now i want to reuse the code that adds this header contribution. I 
> can have YuiButton and YuiMenu both extend YuiComponent. But, what if I also 
> want my Page to be unaware of the toolkit I'm using? I would like the page to 
> use instances of Button, Menu etc. So YuiButton can extend Button, but then 
> it can't share code with YuiMenu through extending. I can have YuiUtils that 
> both of them use, which means, in fact, that I'm implementing the bridge 
> pattern.
>
> what would be good, i think, for the framework, is to use the bridge pattern 
> for all components. Then, different kinds of toolkit can provide the 
> implementation.
>
> Button: has methods like onClick, uses model for labels.
> YuiButton (used by Button): has methods like render(), can add headers, and 
> probably doesn't use the model, but gets explicitely the attributes to use 
> (e.g., label)
>
> ittay
>
> Eelco Hillenius wrote:
> > Maybe you could be more explicit in what you mean?
> >
> > The differences between those versions would primarily be in the
> > different javascript/ css dependencies they use, which is easy to
> > configure using header contributors. And they would need some
> > different initializations, which you could maybe do with attribute
> > modifiers. If that wouldn't work, you can always fall back on
> > abstracting parts of the component into plug-gable pieces  so that you
> > configure a component using composition.
> >
> > Eelco
> >
> >
> > On 7/4/06, Ittay Dror <[EMAIL PROTECTED]> wrote:
> >> maybe wicket 2.0 can refactor the components hierarchy to use the bridge 
> >> pattern?
> >>
> >> for example, i want a Calendar component that will be implemented with 
> >> jscalendar, yui calendar etc. making Calendar abstract and extending it 
> >> with YuiCalendar is not efficient if there are other implementations using 
> >> Yui, since there is probably a lot of code they share.
> >>
> >> of course i can add the bridge pattern my self, but it will be easier if 
> >> wicket already has that, since then all the wicket technical stuff is 
> >> taken care of, and the only thing required is understanding the library i 
> >> want to integrate with.
> >>
> >> thanx,
> >> ittay
> >>
> >> --
> >> ===================================
> >> Ittay Dror,
> >> Chief architect, openQRM TL,
> >> R&D, Qlusters Inc.
> >> [EMAIL PROTECTED]
> >> +972-3-6081994 Fax: +972-3-6081841
> >>
> >> http://www.openQRM.org
> >> - Keeps your Data-Center Up and Running
> >>
> >> Using Tomcat but need to do more? Need to support web services, security?
> >> Get stuff done quickly with pre-integrated technology to make your job 
> >> easier
> >> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> >> _______________________________________________
> >> Wicket-develop mailing list
> >> Wicket-develop@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/wicket-develop
> >>
> >
> > Using Tomcat but need to do more? Need to support web services, security?
> > Get stuff done quickly with pre-integrated technology to make your job 
> > easier
> > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> > _______________________________________________
> > Wicket-develop mailing list
> > Wicket-develop@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wicket-develop
> >
>
>
> --
> ===================================
> Ittay Dror,
> Chief architect, openQRM TL,
> R&D, Qlusters Inc.
> [EMAIL PROTECTED]
> +972-3-6081994 Fax: +972-3-6081841
>
> http://www.openQRM.org
> - Keeps your Data-Center Up and Running
>
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Wicket-develop mailing list
> Wicket-develop@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
>

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Wicket-develop mailing list
Wicket-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-develop

Reply via email to