Kohsuke Kawaguchi wrote:
> 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?
Well... I was anticipating using a custom ConfigParser which would be
aware of this "header" and then pass the body back to me as a black box
(from the ConfigParser's perspective). JSFTemplating would then use the
content of the page fragment.
And no... our current pages are not XML, although they look similar. We
may move some or all of our pages to the Facelets syntax which is xhtml,
but I'm not sure. And it wouldn't help to parse this content unless we
do option #3 which abstracts the gui concepts away from the
implementation (jsf) altogether.
>
>
>> 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.
True.
>
>> 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.
Agreed.
>
>
>
>> *#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.
Agreed. Give me a better way. ;)
>
> <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.
We agree.
>> *#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.
That's an interesting project. I'd like to learn more about it. For
cases where you don't mind having your UI reflect your object structure,
it might be very useful. I'll look into this more so that I can be
thinking about other ways things can work.
Thanks!
Ken