This sounds good. I already have a registry where i can register services in a
decoupled way. With spring and @PostConstruct no Problem :-). I would ASK then
every factory if it is responsible for my entity type. But i still see a
problem here. How to prioritize factory if i have more than one factory for a
Person type. For instance if a boss is a manager. Then i can't use instanceof
in the manager factory because boss entity would match twice.
Am 03.07.2015 3:14 nachm. schrieb Rob Audenaerde <rob.audenae...@gmail.com>:
>
> Hi Per,
>
> You can do something like this:
>
> Create a set of compontents that will be your panels to display specific
> Persons.
>
> Let's call them PersonPanels.
>
> You can introduce a PersonPanelFactory, which might give you the
> appropriate PersonPanel based on the class of the Person (
> person.getClass() ) . This is however not yet nicely extensible, but you
> decoupled the logic for creating panels from your list-code.
>
> Next step: you need to register the classes somehow so you can provide
> panels for in the factory, so the factory can for example use a map to
> provide the proper PersonPanel. You can use reflection to call the
> constructors, which will need to have the same arguments for their
> constructors. This is the biggest disadvantage I think in this approach.
>
> Somewhat like this:
>
> class PersonPanelFactory
> {
> public PersonPanel getPanelFor( Class<T extends> personClass) ...
> public registerPanelFor ( Class<T extends Person> personClass, Class<T
> extends PersonPanel> personPanelClass ...
> }
>
>
>
> On Fri, Jul 3, 2015 at 2:32 PM, Per Newgro <per.new...@gmx.ch> wrote:
>
> > Hi,
> >
> > i think about that problem for some time now. Maybe someone alrady has a
> > good solution.
> >
> > Let's assume we have a Manager entity and a Tainee entity. Both are Person
> > entities.
> > In Model we ask for all persons. So we get a mix from Managers and
> > Trainees in a list.
> >
> > Both concrete entity types shall be displayed in their own component (a
> > custom panel for every1).
> >
> > I would ask for simple, decoupled (extendible) solution of this problem.
> > So far i've tried the obvious "instance of" approach. But this is not
> > extendible.
> > Maybe someone can send me some ideas.
> >
> > Thanks for your support
> > Per
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> >
