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 <[email protected]> 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: [email protected]
> For additional commands, e-mail: [email protected]
>
>
