PageSet or TabSet idea for Tapestry

Current project has a track of pages associated in tabular (html UI) format. Each page maintains it's own set of form/domain data. Each page has a controller (custom Border) component that facilitates navigation between pages, proper tab invocation, and track's save/cancel buttons (to save/cancel each tabs' data).

Idea is this:

• Update the Tapestry_3_0.dtd to allow additional attributes on Page elements in [application].application: linkText (CDATA), tabSet(CDATA).
• engine implementation parses all Pages for tabSet attributes
  
• engine creates unique HashMaps for all TabSets (identified from Page attribute)
  
• engine associates page.name and page.linkText key/value objects in HashMap
• engine provides method getTabSetMap(String) and returns appropriate HashMap of tabSet entries
• engine provides persistTabSet(String) to provide global scope for manipulation of specific TabSet's persist()--to avoid hardcoding String page identifiers and entries
  
• engine provides resetTabSet(String) to provide global scope for manipulation of specific TabSet's reset()--to avoid hardcoding String page identifiers and entries
• create SimpleTabNavigation component
• include SimpleTabNavigation on each tabbed page to avoid duplicate code across tabbed pages
  

The SimpleTabNavigation component creates a table with LinkSubmit elements and associated class (CSS) attributes. The component would require a HashMap and iterate through the keySet (page.name) as the LinkSubmit link and value(page.linkText) as the text of the link. HTML would include a ForEach to iterate through the keySet and generate the LinkSubmits in the table. Component would also require a "listener" binding (current implementation would associate controller component's listener moveToTab() ) and "selected" binding (also associated with controller as selectedTab). Thus, generating the links and table from one location, [appname].application and NOT relying on a copy/paste/edit methodology of the table for each page. This also eliminates possible code hoseups as it relies on one HashMap that could be used from the engine implementation aforementioned.

Principles in practice: KISS and DRY (Keep It Simple, Stupid & Don't Repeat Yourself).