> I have at times used factories and then found that they made some
simply things more complicated
I agree... you will loose the feature to sub-class and override
onConfigure() or onBeforeRender() of your components.
And what I also encountered using factories, when having sub-classed
model-objects and you want to choose as specific component depending on
the model-objects subclass, you run into the "unpack on construction
time" issue, which is also not that good.
And if you want to use shared models for your components and forward
your model to your via factory constructed component, you will get type
safety warnings.
e.g. factoryMethod(IModel<Person> personModel){
if(personModel.getObject() instanceof Employee){
return new EmployeePanel((IModel<Employee>)personModel);//type safety
warning
}else{
...
}
}
All this points are somehow "code smells" to me and from the experience
of the last years I more and more agree with the "bad practice" not to
use factories for components.
But I never used Spring / SpringFactories... maybe you wont run into the
described issues... not sure here.
best regards
Patrick
Am 18.02.2016 um 10:12 schrieb Urbani, Edmund:
Hello,
I have at times used factories and then found that they made some simply
things more complicated. Eg. I could no longer simply override
isEnabled() or isVisible() methods to suit the page I was added the
component to. So I try to avoid factories for Wicket components now
unless I see a real advantage.
Kind regards,
Edmund
On 02/18/2016 09:53 AM, Sven Meier wrote:
Hi,
I wouldn't use a factory for each and every component (e.g. label).
But any sufficiently large Wicket project will benefit from separating
it into separate parts which very light interdependencies only: a
plugin-based architecture.
If you're using Spring factories, you just have to take care that no
references to Spring beans leak into the components - something you
have easily with inner classes (as in the example listing 15 in the
Wicket guide).
Have fun
Sven
On 18.02.2016 09:01, Martin Grigorov wrote:
Hi,
I don't share the option in the guide.
Using factories when needed is perfectly fine.
Apache Isis uses factories to provide custom UI for almost any part
of the
Wicket viewer.
BrixCMS also uses factories to create tiles.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Thu, Feb 18, 2016 at 7:21 AM, Arjun Dhar <[email protected]> wrote:
Hi,
I have a bunch of Admin panels but i want to be able to override
them. The
issue is the pages obviously use "add(new SomeAdminPanel(....))";
To overcome this I was thinking or writing a Factory, that via can
create
the desired instance of the Panel and pass it to the Page. The factory
internally can use Spring to make this highly configurable.
however, I came across
https://ci.apache.org/projects/wicket/guide/6.x/guide/bestpractices.html#bestpractices_12
(Do not use factories for components)
... can anyone validate if I should let that stop me from doing what I
intend? Maybe Panels are an exception to this rule?!
thanks
-----
Software documentation is like sex: when it is good, it is very, very
good; and when it is bad, it is still better than nothing!
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Use-a-Factory-to-create-a-Panel-Yay-or-Nay-tp4673622.html
Sent from the Users forum 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]
--
Mit freundlichen Grüßen
Edmund Urbani
Liland IT Team
Email: <mailto:[email protected]>[email protected]
Liland IT GmbH ...does IT better
Tel: +43 463 220111
Fax: +43 463 220111-33
Tel(GER): +49 221 65028588
Find us at Facebook http://facebook.com/Lilandit
http://green-badges.com
http://iventcloud.com
http://Lilandit.com
<http://www.LilandIT.com> <http://www.LilandIT.com>
Copyright © 2016, Liland IT GmbH
Diese Mail enthaelt vertrauliche und/oder rechtlich geschuetzte
Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese Email irrtuemlich
erhalten haben, informieren Sie bitte sofort den Absender und vernichten
Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe
dieser Mail ist nicht gestattet.
This email may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this email in
error) please notify the sender immediately and destroy this email. Any
unauthorised copying, disclosure or distribution of the material in this
email is strictly forbidden.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
