You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Nick Wiedenbrück <ma...@googlemail.com> on 2009/04/24 10:25:42 UTC
Factory for Components
Hi,
I'm having many Components (DropDowns, ChoiceRenderers, ...) that are reused
in different places in my application. For example I have one
ChoiceRenderer for persons, one for accounts and so on. I want to
centralize the creation of these components in a factory in order to decople
the clients. For example I'm thinking about a ChoiceRendererFactory with
methods createPersonChoiceRenderer() and createAccountChoiceRenderer().
Now, my question is where to put this factory. I need a central place, where
the can find the factory. Is it a good idea to have a method
createChoiceRendererFactory() on my Application class?
Regards,
Nick
Re: Factory for Components
Posted by Martijn Dashorst <ma...@gmail.com>.
On Fri, Apr 24, 2009 at 8:27 PM, James Carman
<jc...@carmanconsulting.com> wrote:
> We'll just have to agree to disagree here.
I agree :-P
Martijn
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Factory for Components
Posted by James Carman <jc...@carmanconsulting.com>.
On Fri, Apr 24, 2009 at 1:28 PM, Igor Vaynberg <ig...@gmail.com> wrote:
> lies! all lies!
>
> it makes perfect sense to put transactional boundaries on the ui
> events. user "clicking a button" is an action that the user perceives
> as being a unit of work which is where the transaction boundary should
> be.
>
> it is also not uncommon to put transaction boundaries on the request -
> which is also a ui artifact.
>
> dont get me wrong, you should still have transactional boundaries on
> the domain object, but you should have a higher one on a
> button.onsubmit() so that it combines whatever transactions the domain
> calls will start into a single one.
We'll just have to agree to disagree here.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Factory for Components
Posted by Igor Vaynberg <ig...@gmail.com>.
lies! all lies!
it makes perfect sense to put transactional boundaries on the ui
events. user "clicking a button" is an action that the user perceives
as being a unit of work which is where the transaction boundary should
be.
it is also not uncommon to put transaction boundaries on the request -
which is also a ui artifact.
dont get me wrong, you should still have transactional boundaries on
the domain object, but you should have a higher one on a
button.onsubmit() so that it combines whatever transactions the domain
calls will start into a single one.
just my two cents :)
-igor
On Fri, Apr 24, 2009 at 7:39 AM, James Carman
<jc...@carmanconsulting.com> wrote:
> On Fri, Apr 24, 2009 at 9:07 AM, Andreas Petersson <an...@petersson.at> wrote:
>> 1) be able to use AOP on components (guice). for example use @Transactional
>> on onClick method to tightly specify transaction boundaries.
>
> I wouldn't recommend that. Putting transactional boundaries on user
> interface methods is not a good idea, IMHO. If the "stuff" logically
> belongs in a transaction, then it should be part of the "domain"
> model. The UI would then use the domain model to get to the logic.
> This would also make it much easier to unit test the logic.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Factory for Components
Posted by James Carman <jc...@carmanconsulting.com>.
On Fri, Apr 24, 2009 at 9:07 AM, Andreas Petersson <an...@petersson.at> wrote:
> 1) be able to use AOP on components (guice). for example use @Transactional
> on onClick method to tightly specify transaction boundaries.
I wouldn't recommend that. Putting transactional boundaries on user
interface methods is not a good idea, IMHO. If the "stuff" logically
belongs in a transaction, then it should be part of the "domain"
model. The UI would then use the domain model to get to the logic.
This would also make it much easier to unit test the logic.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Factory for Components
Posted by Eyal Golan <eg...@gmail.com>.
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
egolan74@gmail.com
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 <jeremy@wickettraining.com
> 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 <ma...@gmail.com>
> 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
> >> <ma...@gmail.com> 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: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >>
> >
> > --
> > 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: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Factory for Components
Posted by Jeremy Thomerson <je...@wickettraining.com>.
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 <ma...@gmail.com> 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
>> <ma...@gmail.com> 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: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
> --
> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Factory for Components
Posted by cretzel <ma...@gmail.com>.
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
> <ma...@gmail.com> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Factory for Components
Posted by Andreas Petersson <an...@petersson.at>.
On Fri, 24 Apr 2009 13:39:35 +0200, Martijn Dashorst
<ma...@gmail.com> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Factory for Components
Posted by Martijn Dashorst <ma...@gmail.com>.
In what way is MyConvolutedComponentFactory.createNewMyComponent()
better than "new MyComponent()"?
Martijn
2009/4/24 Nick Wiedenbrück <ma...@googlemail.com>:
> Hi,
>
> I'm having many Components (DropDowns, ChoiceRenderers, ...) that are reused
> in different places in my application. For example I have one
> ChoiceRenderer for persons, one for accounts and so on. I want to
> centralize the creation of these components in a factory in order to decople
> the clients. For example I'm thinking about a ChoiceRendererFactory with
> methods createPersonChoiceRenderer() and createAccountChoiceRenderer().
>
> Now, my question is where to put this factory. I need a central place, where
> the can find the factory. Is it a good idea to have a method
> createChoiceRendererFactory() on my Application class?
>
> Regards,
> Nick
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.5 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Factory for Components
Posted by Marcelo Morales <ma...@gmail.com>.
Use it then. Inject the factory via @SpringBean.
On Fri, Apr 24, 2009 at 9:56 AM, cretzel <ma...@gmail.com> wrote:
>
> We are using Spring.
>
>
> Liam Clarke-Hutchinson-3 wrote:
>>
>> Are you using an IoC container at all?
>>
>> On 4/24/09, Nick Wiedenbrück <ma...@googlemail.com> wrote:
>>> Hi,
>>>
>>> I'm having many Components (DropDowns, ChoiceRenderers, ...) that are
>>> reused
>>> in different places in my application. For example I have one
>>> ChoiceRenderer for persons, one for accounts and so on. I want to
>>> centralize the creation of these components in a factory in order to
>>> decople
>>> the clients. For example I'm thinking about a ChoiceRendererFactory with
>>> methods createPersonChoiceRenderer() and createAccountChoiceRenderer().
>>>
>>> Now, my question is where to put this factory. I need a central place,
>>> where
>>> the can find the factory. Is it a good idea to have a method
>>> createChoiceRendererFactory() on my Application class?
>>>
>>> Regards,
>>> Nick
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Factory-for-Components-tp23212875p23216937.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Marcelo Morales
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Factory for Components
Posted by cretzel <ma...@gmail.com>.
We are using Spring.
Liam Clarke-Hutchinson-3 wrote:
>
> Are you using an IoC container at all?
>
> On 4/24/09, Nick Wiedenbrück <ma...@googlemail.com> wrote:
>> Hi,
>>
>> I'm having many Components (DropDowns, ChoiceRenderers, ...) that are
>> reused
>> in different places in my application. For example I have one
>> ChoiceRenderer for persons, one for accounts and so on. I want to
>> centralize the creation of these components in a factory in order to
>> decople
>> the clients. For example I'm thinking about a ChoiceRendererFactory with
>> methods createPersonChoiceRenderer() and createAccountChoiceRenderer().
>>
>> Now, my question is where to put this factory. I need a central place,
>> where
>> the can find the factory. Is it a good idea to have a method
>> createChoiceRendererFactory() on my Application class?
>>
>> Regards,
>> Nick
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Factory-for-Components-tp23212875p23216937.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Factory for Components
Posted by Liam Clarke-Hutchinson <li...@steelsky.co.nz>.
Are you using an IoC container at all?
On 4/24/09, Nick Wiedenbrück <ma...@googlemail.com> wrote:
> Hi,
>
> I'm having many Components (DropDowns, ChoiceRenderers, ...) that are reused
> in different places in my application. For example I have one
> ChoiceRenderer for persons, one for accounts and so on. I want to
> centralize the creation of these components in a factory in order to decople
> the clients. For example I'm thinking about a ChoiceRendererFactory with
> methods createPersonChoiceRenderer() and createAccountChoiceRenderer().
>
> Now, my question is where to put this factory. I need a central place, where
> the can find the factory. Is it a good idea to have a method
> createChoiceRendererFactory() on my Application class?
>
> Regards,
> Nick
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org