You need an interface like javax.swing.tree.TreeNode that all your
nested objects implement. This is what wicket uses for its tree
implementation (take a look in wicket-extensions for 1.x). The wicket
tree impl rocks, so you can do no better than look there for
inspiration. Also, take a look at DefaultMutableTreeNode for ideas on
how to implement.
best,
jim
On 3/23/07, Matt Welch <[EMAIL PROTECTED]> wrote:
> As the subject indicates, this isn't a question specific to Wicket (although
> it WILL eventually involve Wicket to display these objects), so if you feel
> I should post this elsewhere, feel free to tell me so, however it seemed
> like a pretty bright bunch of Java guys hang around here so I'm hoping for
> some insight.
>
> I've been tasked with implementing a rather curious (to me anyway)
> hierarchical object structure. Most of the objects in this structure serve
> no other purpose than to group the objects below them; it's only at the
> final leaf levels that there are some significant behavioral difference in
> the objects. For lack of a better example, I'll call these objects Grouper1,
> Grouper2, Grouper3, and Leaf. So I might have a structure that looks like:
>
> Grouper1
> --Grouper2
> ----Grouper3
> ------Leaf
> ------Leaf
> ------Leaf
> ----Grouper3
> ------Leaf
> ------Leaf
> ------Leaf
>
> It can also look like this:
>
> Grouper1
> --Grouper3
> ----Leaf
> ----Leaf
> ----Leaf
> --Grouper3
> ----Leaf
> ----Leaf
> ----Leaf
>
> Or like this:
>
> Grouper1
> --Leaf
> --Leaf
> --Grouper2
> ----Grouper3
> ------Leaf
> ------Leaf
> ------Leaf
> ----Grouper3
> ------Leaf
> ------Leaf
> ------Leaf
>
> Or even like this:
>
> Grouper3
> --Leaf
> --Leaf
> --Leaf
>
> Although I'm willing to exclude that last example (with something other than
> a Grouper1 at the top) if it helps simplify things any.
>
> As you can see almost all objects in the hierarchy can exist at any level.
> Only the leaf node has any properties beyond those shared by all of the
> other objects. And before you ask, despite the fact that the branch items
> are so similar, they do have different labels that are important to the
> people using the hierarchy. I'm just trying to determine if those labels are
> important to the domain model.
>
> I started to model this using simple inheritance. Something like the
> following:
>
> public abstract class MyHierarchyObject{
> private String commonAttribute1;
> private boolean commonAttribute2 = false;
> private List<MyHierarchyObject> children = new
> ArrayList<MyHierarchyObject>;
> private MyHierarchyObject parent; //the association needs to be
> bidirectional for up and down navigation
> ...
> }
>
> public class Grouper1 extends MyHierarchyObject{
> }
>
> etc. etc.
>
> Of course, I realized after just a few seconds that this seemed a little
> silly since I was going to end up with at least three classes with either no
> behavior or properties or only extremely minor changes to the abstract
> class's properties like setting commonAttribute2 to true by default.
>
> So does using inheritance like this still make sense or should I do
> something like make the MyHierarchyObject not abstract and add a Type
> property that can be populated from an enum with elements like Grouper1,
> Grouper2, and Grouper3? What about the leaf node. It's not allowed to have
> children but because it can be a child of any of the Groupers, it seems like
> it needs to extend MyHierarchyObject in order to fit into the child parent
> model. Should I put the children related methods into an interface that only
> the Grouper classes implement? Of course that only works if I use the
> inheritance model; maybe that's a good reason to use it? Or is there a
> design pattern I'm missing in all of this that might help me.
>
> I've been thinking about this for so long now that I'm afraid I'm too deep
> into it and not thinking clearly about the best approaches. That's why I'm
> posting here. Unfortunately, the hierarchy is quite a bit more complex than
> this example, but I think if I can solve this level of complexity, I can
> apply similar logic to the rest of the hierarchy that I didn't represent
> here.
>
> Thanks for reading such a long post.
>
> Matt
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Wicket-user mailing list
> Wicket-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
