I agree with Jeremy. We have just recently changed all of the appearance of our UI to be as the company's standard (we were bought a few months ago by a large company). The guy who made this re-branding refactored everything using eclipse IDE. For example, he changed every FormComponentLabel to CustomFormComponentLabel, which has its own classes and behaviors. So he did for almost any type of component we use.
That went very easy. Eyal Golan [email protected] Visit: http://jvdrums.sourceforge.net/ LinkedIn: http://www.linkedin.com/in/egolan74 P Save a tree. Please don't print this e-mail unless it's really necessary On Fri, Apr 24, 2009 at 8:22 PM, Jeremy Thomerson <[email protected] > wrote: > That's a very insignificant advantage compared to the amount of work > you will go through to use a factory. Sounds like premature > (non-)optimization. Especially when every IDE out there can easily > accomplish that refactor for you by telling you every place that new > Foo() is called. > > -- > Jeremy Thomerson > http://www.wickettraining.com > > > > > On Fri, Apr 24, 2009 at 9:00 AM, cretzel <[email protected]> > wrote: > > > > My primary reason is to be able to substitute another (improved) version > for > > this component. > > > > For example, if we have a simple custom DropDown and we instantiate it by > > calling new DropDown() all over in the code it might be difficult, to > > replace that by a new version, e.g. DropDownWithCrazyAjaxEffects. If we > have > > a factory, we'd have just one place where the component is created. > > > > > > Andreas Petersson wrote: > >> > >> > >> > >> On Fri, 24 Apr 2009 13:39:35 +0200, Martijn Dashorst > >> <[email protected]> wrote: > >>> In what way is MyConvolutedComponentFactory.createNewMyComponent() > >>> better than "new MyComponent()"? > >>> > >> > >> ideas that come to my mind why to use this: > >> 0) you might be able to reduce generics cluttering by using > >> TextField<String> = MyConvolutedComponentFactory.createTextField(model); > >> with public static <T> TextField<T> createTextField(IModel<T> model); > >> 1) be able to use AOP on components (guice). for example use > >> @Transactional > >> on onClick method to tightly specify transaction boundaries. > >> 2) you might be able to reuse (immutable,stateless) components > >> 3) you might be able to chose any subtype of component depending on the > >> provided parameters > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > >> > > > > -- > > View this message in context: > http://www.nabble.com/Factory-for-Components-tp23212875p23217029.html > > Sent from the Wicket - User mailing list archive at Nabble.com. > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
