bklough (7) [Avatar] Offline
#1
I would love to see an example. I've got half of it, but the Composite part is driving me nuts. If I get it, I'll post it. In the meantime though, it'd make a kicking example for the next edition of "Hibernate in Action", assuming the ddl is there to support it.

Think about it, you've got a web app, you'd to define a dynamic menu system for a left nav . . . you access your little app to define the menus for your template app, hit build, deploy, and villa! Your stubs already there. You're looking at it and realize, "Ah, man. Approve User Role shouldn't be under Admin directly...it should be under User Admin". You use your app to tweak the link, refresh the page, then, villa! "Approve User Role" is right where you put it. That'd be so cool . . .
bklough (7) [Avatar] Offline
#2
Re: Has anyone implemented a true GOF Composite Pattern?
Okay, so here's the gist of what I've got so far:
Domain class hierarchy:

                        Menu
                           |
           +-------------+-------------+
            |                             |
      MenuItem             CompositeMenu
Menu:         // can't exist without an item, may/may not contain submenus
   name string

MenuItem:
   link    string // it's a url

CompositeMenu
   menuItems  Collecton


Table per class implementation (I think)


Menu is abstract, requires implementation of Visitor Pattern "accept(...)".


HtmlMenuVisitor instance beebops through instance tree generating HTML to generate the left nav code (I leave that code to the reader):






Apply some css styles, and villa! Menus.



createTables.sql

-- Postgresql v8
--
-- Represents the following Inheritance:
--
--             Menu
--              |
--    +---------+--------+
-- MenuItem        CompositeMenu
--

drop table COMPOSITE_MENU cascade;
drop table MENU_ITEM cascade;
drop table MENU cascade;

drop sequence menu_menu_id_seq cascade;
create sequence menu_menu_id_seq;
create table MENU (
   MENU_ID            integer not null primary key default nextval('menu_menu_id_seq'),
   NAME varchar(64)
);

-- Shares a (PK)(FK) relationship with MENU on MENU_ID
create table MENU_ITEM (
   menu_id            integer references menu,
   LINK               varchar(128) default '#' not null
);

drop sequence composite_menu_submenu_id_seq cascade;
create sequence composite_menu_submenu_id_seq;
create table COMPOSITE_MENU (
   menu_id            integer references menu,
   submenu_id         integer not null primary key default nextval('composite_menu_submenu_id_seq')
);

create table COMPOSITE_MENU_MENU_ITEMS (
  submenu_id          integer references composite_menu(submenu_id),
  menu_item_id        integer references menu_item(menu_id),
  primary key (submenu_id, menu_item_id)
);




Menu.hbm.xml
<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
>
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<!-- Generated Nov 1, 2006 9:37:14 AM by Hibernate Tools 3.2.0.beta8 -->

<hibernate-mapping
>
	package="com.strutstestapp.navigation">
	
    <class name="Menu" table="MENU">
        <id column="MENU_ID" type="integer" name="menuId">
            <generator class="sequence">
                <param name="sequence">menu_menu_id_seq</param>
            </generator>
        </id>

        <property name="name" type="string">
            <column name="NAME" not-null="true"/>
        </property>
        
        <joined-subclass name="MenuItem" table="MENU_ITEM">
          <key column="MENU_ID" not-null="true"/>  <!-- primary key/foreign key -->
          
          <property name="link" type="string">
              <column name="LINK" not-null="true"/>
          </property>
          
        </joined-subclass>
     </class>
</hibernate-mapping>
bklough (7) [Avatar] Offline
#3
Re: Has anyone implemented a true GOF Composite Pattern?
You've got to be kidding me -- the order of the individual joinclass mappings in the hbm.xml file (s) matters?!? Unbelievable. One superclass, two subclasses of that superclass, and the order in which they're defined in a goofy .xml file matters. Yep. That's exactly how an Object Oriented solution should be implemented.

Again. Unbelievable.

And, good for you folks: it is "documented". Apparently the decision was made not to highlight the imperfect, rather key, implementation decision, but rather leave it as an offhand remark buried amidst a gazillion sentences of the reference doc.

Best of luck to you all. This forum appears to be dead anyway . . .