Ken Paulsen wrote:
>
> 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:*
Ah, yes, if people would have to write XML files anyway, annotating
those make a lot of sense. Now, when you write like:
>
> 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>
The first 4 lines are not well-formed XML. This must be very dumb
question, but JSF page fragments don't have to be XML?
> Disadvantages:
>
> * Exposes JSF directly as integration mechanism (harder for non-jsf
> integrators)
I believe you had the idea of auto-generating some basic stuff, so I
guess that could mitigate this.
> Requires:
>
> * Custom "ConfigParser"
This is probably not too hard. We can also parse JSF page fragments at
build time to generate something that can be read quickly at runtime.
> *#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>
This is essentially a "deployment descriptor", and I kind of thought
that the industry is moving away from this kind of XML usage.
<snip />
> *#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.
My 2 cents is that unless you can substantially simplify the DSL that
you are defining, this looks like too much work for the admin team
without too much gain to the users.
> *#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.
I was thinking about this more from the perspective of something like
this <
https://stapler.dev.java.net/> (so that there are some models that
are rather GUI independent, with views that render the model), but you
are right that it's very foreign to how the existing code works, and I
agree with your evaluation that the overhead of migration is an
important factor.
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com