From: Ken Paulsen <Ken.Paulsen_at_Sun.COM>
Date: Tue, 22 Jan 2008 14:40:21 -0800

As discussed in the meeting, here are some options on how a integrator could specify these integration points (in all cases I will show tab and tree examples, although other types like help, button, text, custom java code, etc need to also work).

#1)  "annotate" a JSF page fragment:

id: myTab type: applicationTab priority: 22 parentId: webApplicationTab <sun:tab id="general" immediate="true" text="$resource{i18n.common.General}" >     <!command         setSessionAttribute(key="appGeneralTabs" value="general");             urlencode(value="#{name}", value=>$pageSession{name});             redirect(page="#{generalPage}?appName=#{name}");     /> </sun:tab>

  

id: jbiRootNode type: treeNode priority: 840 parentId: rootNode <sun:treeNode  id="JBIRoot"        expanded="true"        rendered="#{JBIHookBean.jbiJarsAvailable && JBIConfigBean.jbiEnabled}"        target="main"        text="$resource{i18n.tree.jbi.root}"        toolTip="$resource{i18n.tree.jbi.root.toolTip}"        url="jbi/pe/root.jsf">    <!facet image>        <sun:iconHyperlink id="image" icon="TREE_FOLDER" url="jbi/pe/root.jsf" target="main" border="0" immediate="true" toolTip="$resource{i18n.tree.jbi.root.toolTip}" />    </facet>    <dynamicTreeNode id="jbiDeployments"            childExpanded="false"            childImageURLbase="resource/images/jbi/"            childTarget="main"            childURLbase="/jbi/pe/showDeployment.jsf?"            expanded="false"            rendered="#{JBIHookBean.jbiJarsAvailable && JBIConfigBean.jbiEnabled}"            target="main"            text="$resource{i18n.tree.jbi.deployments}"            toolTip="$resource{i18n.tree.jbi.deployments.toolTip}"            treeAdaptorClass="com.sun.jbi.jsf.util.JBIHookTreeAdaptor"            treeAdaptorListType="deployments"            url="/jbi/pe/deployments.jsf">        <!facet image>            <sun:iconHyperlink id="saLink" icon="TREE_FOLDER" url="/jbi/pe/deployments.jsf" target="main" border="0" immediate="true" />        </facet>    </dynamicTreeNode>

Advantages:

• Cut/paste existing code (faster development from v2 -> v3)
  
• 1 file to add an integration into GUI

Disadvantages:

• Exposes JSF directly as integration mechanism (harder for non-jsf integrators)
  

Requires:

• Custom "ConfigParser"

#2) Separate Configuration, still use .jsf pages/fragments:

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE gui-config PUBLIC ...> <gui-config id="myIntegration">     <tab id="myTab" type="webApplicationTab" priority="22" parentId="webApplicationTab" uri="/myTab.jsf" />     <treeNode id="jbiRootNode" priority="840" parentId="rootNode" uri="/myTreeNode.jsf" /> </gui-config>

/myTab.jsf:

<sun:tab id="general" immediate="true" text="$resource{i18n.common.General}" >     <!command         setSessionAttribute(key="appGeneralTabs" value="general");             urlencode(value="#{name}", value=>$pageSession{name});             redirect(page="#{generalPage}?appName=#{name}");     /> </sun:tab>

/myTreeNode.jsf:

<sun:treeNode  id="JBIRoot"        expanded="true"        rendered="#{JBIHookBean.jbiJarsAvailable && JBIConfigBean.jbiEnabled}"        target="main"        text="$resource{i18n.tree.jbi.root}"        toolTip="$resource{i18n.tree.jbi.root.toolTip}"        url="jbi/pe/root.jsf">    <!facet image>        <sun:iconHyperlink id="image" icon="TREE_FOLDER" url="jbi/pe/root.jsf" target="main" border="0" immediate="true" toolTip="$resource{i18n.tree.jbi.root.toolTip}" />    </facet>    <dynamicTreeNode id="jbiDeployments"            childExpanded="false"            childImageURLbase="resource/images/jbi/"            childTarget="main"            childURLbase="/jbi/pe/showDeployment.jsf?"            expanded="false"            rendered="#{JBIHookBean.jbiJarsAvailable && JBIConfigBean.jbiEnabled}"            target="main"            text="$resource{i18n.tree.jbi.deployments}"            toolTip="$resource{i18n.tree.jbi.deployments.toolTip}"            treeAdaptorClass="com.sun.jbi.jsf.util.JBIHookTreeAdaptor"            treeAdaptorListType="deployments"            url="/jbi/pe/deployments.jsf">        <!facet image>            <sun:iconHyperlink id="saLink" icon="TREE_FOLDER" url="/jbi/pe/deployments.jsf" target="main" border="0" immediate="true" />        </facet>    </dynamicTreeNode>

Advantages:

• Cut/paste existing code (faster development from v2 -> v3)
  
• Separation of configuration makes re-use easier (i.e. includes)
  
• Content is kept out of configuration
• May be able to leverage existing ConfigParser

Disadvantages:

• Exposes JSF directly as integration mechanism (harder for non-jsf integrators)
  

Requires:

• 
  

#3) Abstract JSF, use "@Configured" beans for meta-data

NOTE: XML syntax of ".gui" files would need to be defined.  It could be extensible via the hk2 ConfigParser.  It may be able to generalize gui concepts such as tabs/trees/menus more easily and could adapt to different technologies besides JSF.  Some of the JSF concepts (i.e. "immediate") may have to be removed, or be renamed to abstract them.

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE gui-config PUBLIC ...> <gui-config id="myIntegration">     <tab id="myTab" type="webApplicationTab" priority="22" parentId="webApplicationTab" uri="/myTab.gui" />     <treeNode id="jbiRootNode" priority="840" parentId="rootNode" uri="/myTreeNode.gui" /> </gui-config>

/myTab.gui:

<tab id="general" immediate="true" text="#{i18n.common.General}" >     <event type="command">         setSessionAttribute(key="appGeneralTabs" value="general");             urlencode(value="#{name}", value=>$pageSession{name});             redirect(page="#{generalPage}?appName=#{name}");     </event> </tab>

/myTreeNode.jsf:

<treeNode  id="JBIRoot"        expanded="true"        rendered="#{JBIHookBean.jbiJarsAvailable && JBIConfigBean.jbiEnabled}"        target="main"        text="#{i18n.tree.jbi.root}"        toolTip="#{i18n.tree.jbi.root.toolTip}"        url="jbi/pe/root.jsf">    <facet name="image">        <iconHyperlink id="image" icon="TREE_FOLDER" url="jbi/pe/root.jsf" target="main" border="0" immediate="true" toolTip="#{i18n.tree.jbi.root.toolTip}" />    </facet>    <dynamicTreeNode id="jbiDeployments"            childExpanded="false"            childImageURLbase="resource/images/jbi/"            childTarget="main"            childURLbase="/jbi/pe/showDeployment.jsf?"            expanded="false"            rendered="#{JBIHookBean.jbiJarsAvailable && JBIConfigBean.jbiEnabled}"            target="main"            text="$resource{i18n.tree.jbi.deployments}"            toolTip="$resource{i18n.tree.jbi.deployments.toolTip}"            treeAdaptorClass="com.sun.jbi.jsf.util.JBIHookTreeAdaptor"            treeAdaptorListType="deployments"            url="/jbi/pe/deployments.jsf">        <facet name="image">            <iconHyperlink id="saLink" icon="TREE_FOLDER" url="/jbi/pe/deployments.jsf" target="main" border="0" immediate="true" />        </facet>    </dynamicTreeNode>

Advantages:

• JSF is abstracted (easier for non-jsf developers)
  
• Abstraction allows different UI / Themes to be rendered w/o too much difficulty
• Code generation necessary will help effort to dynamically generate UI
  
• Content is kept out of configuration
• Leverage existing ConfigParser + other HK2 concepts
  

Disadvantages:

• Much slower to migrate existing GUI application from v2 -> v3
• Many design details need to be solved before significant development can begin (xml format, etc)
• Cannot leverage existing JSF user-base to extend admin console
  

Requires:

• Converting significant (possibly all) of current GUI application

#4) Java-based integration

I won't show examples here... but this would use @annotations in java files to define the same data as above (like @TreeNode annotations, etc.).  All meta-data would need to exist in java code or annotations.

Advantages:

• Easy for non-gui developers
• Perhaps is a basis for code-gen'd approach
• May be possible to combine this approach with any of the above solutions.
• JSF is abstracted (easier for non-jsf developers)
• Abstraction allows different UI / Themes to be rendered w/o too much difficulty
• Leverage existing @Service / @Contract annotations that developers are familiar with.
  

Disadvantages:

• Much slower to migrate existing GUI application from v2 -> v3
• Unnatural to GUI developers
• GUI-specific content may be needed in source code where it doesn't really belong (image names, etc)
  
• Many design details need to be solved before significant development can begin
  

Requires:

• Would almost certainly require a combination of one of the other options to be feasible.  Disadvantages mostly go away if combined with another option b/c developers have choices.
  

I'm sure there are countless other ways to approach this, these are just the ones that come to mind right now.  If anyone has other suggestions, now is the time for us to consider them. :)  We need to be mindful of the amount of development time we have an the other features we'd like to implement as well.

Thanks!

Ken


Kohsuke Kawaguchi wrote:

Nazrul Islam wrote:

We will meet tomorrow (Tuesday, 1/22) at 11 am PST. Kohsuke will talk about HK2 and how it relates to administration. Slides will be sent out before the meeting.

Slides attached.

Agenda
  HK2

Conf Number
 Toll Free: (866) 230-6968
 Int'l Access: (865) 544-7856
 Access Code: 3846234

Conf Room  Peter Pan's Flight
  SCA 12 Room 3130