[prev in list] [next in list] [prev in thread] [next in thread]
List: jakarta-commons-dev
Subject: Re: [CLI] XML Support (was Re: [CLI] Status)
From: "David Morris" <David.Morris () plumcreek ! com>
Date: 2004-12-31 4:45:43
Message-ID: s1d47716.040 () cfo-msg ! plumcreek ! net
[Download RAW message or body]
Rob,
Thanks for the feedback. I agree that it should be a design goal to
minimize reliance on outside packages. The XMLBuilder that I am working
on uses a SAX parser and doesn't require any outside package as long as
you are using a 1.4+ JDK. Those using an earlier JDK will need to have a
parser like Xerces on the classpath. There is also a requirement to
identity the Sax paser with an environment variable but that should be
pretty easy to get around.
Adding support for additional attributes and/or elements is no problem.
Right now, I am testing a prototype that implements the structure I
posted. I hope to have something to show in the next few days.
--David
>>> roxspring@imapmail.org 12/30/04 7:26 AM >>>
Modelling a cli in xml has been talked about in the past and there are a
couple of things you might want to take into consideration if you are
going to implement such a feature. Firstly, there is the question of
whether to parse the xml at runtime or build time - runtime introduces
another dependancy whereas build time involves an ant task / maven
plugin etc - Ideally I'd like to suppport both approaches so that the
user can choose but I've not thought about how practical that is.
Secondly there was a request a while ago to build an Ant task from a CLI
model, it was felt that code generation from XML might be the best way
forward; this is probably out of scope for your plans though I guess.
Going back to the structure you propose - I like it but have a couple of
suggestions that you might want to think about:
1) It would be great if people could customise the builders used for
each option, ie. allow them to choose whether to use bursting and to
change the prefixes for switches etc.
2) Allowing options to be referenced by name/id would allow the same
option to appear in multiple groups which adds loads of flexibility.
Off the top of my head these could be achieved by adding an extra
wrapping element e.g. option-model:
<option-model group-name="options">
<builders>
<option-builder id="obuilder" short-prefix="-" long-prefix="--"
burst-enabled="true"/>
</builders>
<option name="help" builder="obuilder" ... />
<group name="options" ... >
<reference name="help"/>
</group>
</option-model>
What do you think?
Rob
David Morris wrote:
> Rob,
>
> Thanks for applying all of the patches and getting CLI into shape. I
> will supply a test case for 32533. I have been working on an
XMLBuilder
> that uses an XML document to describe Options, Arguements, and Groups.
> Hopefully it will be useful to CLI. While working on this I found that
> not all properties are exposed from Groups and Arguements through the
> current builders. Do you expect that to change? If it won't change
then
> I will go with the properties exposed by the current builders. If it
> will/could, I will go to the base classes. An example is id for group.
>
> It also looks like some values like an argument validator are
singletons
> but the ArgumentBuilder doesn't seem to enforce this. In the case of
> validator, it seems useful to allow more than one.
>
> Could you look this empty XML document and schema and let me know if
it
> seems reasonable:
>
> <?xml version="1.0" encoding="ISO-8859-1"?>
> <group name="" description="" minimum="" maximum=""
> xsi:noNamespaceSchemaLocation="cli2.xsd"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
> <option id="" name="" description="" required="true">
> <alias name="" />
> <alias name="" />
> <group name="" description="" minimum="" maximum="">
> <option id="" name="" description="" required="true">
> <alias name="" />
> <alias name="" />
> <group name="" description="" minimum="" maximum=""></group>
> <argument id="" name="" description="" initial-seperator=""
> subsequent-seperator="" validator="" minimum="" maximum=""
> consume-remaining="">
> <default></default>
> <default></default>
> </argument>
> </option>
> </group>
> <argument id="" name="" description="" initial-seperator=""
> subsequent-seperator="" validator="" minimum="" maximum=""
> consume-remaining="">
> <default></default>
> <default></default>
> </argument>
> </option>
> </group>
>
> <?xml version="1.0" encoding="ISO-8859-1"?>
> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
> <xsd:element name="alias">
> <xsd:complexType>
> <xsd:attribute name="name" type="xsd:string"
> use="optional"/>
> </xsd:complexType>
> </xsd:element>
> <xsd:element name="argument">
> <xsd:complexType>
> <xsd:sequence>
> <xsd:element maxOccurs="unbounded" minOccurs="0"
> ref="default"/>
> </xsd:sequence>
> <xsd:attribute name="consume-remaining" type="xsd:string"
> use="optional"/>
> <xsd:attribute name="description" type="xsd:string"
> use="optional"/>
> <xsd:attribute name="id" type="xsd:string"
use="optional"/>
> <xsd:attribute name="initial-seperator" type="xsd:string"
> use="optional"/>
> <xsd:attribute name="maximum" type="xsd:string"
> use="optional"/>
> <xsd:attribute name="minimum" type="xsd:string"
> use="optional"/>
> <xsd:attribute name="name" type="xsd:string"
> use="optional"/>
> <xsd:attribute name="subsequent-seperator"
type="xsd:string"
> use="optional"/>
> <xsd:attribute name="validator" type="xsd:string"
> use="optional"/>
> </xsd:complexType>
> </xsd:element>
> <xsd:element name="default">
> <xsd:complexType/>
> </xsd:element>
> <xsd:element name="group">
> <xsd:complexType>
> <xsd:sequence>
> <xsd:element maxOccurs="unbounded" minOccurs="1"
> ref="option"/>
> </xsd:sequence>
> <xsd:attribute name="description" type="xsd:string"
> use="optional"/>
> <xsd:attribute name="maximum" type="xsd:string"
> use="optional"/>
> <xsd:attribute name="minimum" type="xsd:string"
> use="optional"/>
> <xsd:attribute name="name" type="xsd:string"
> use="optional"/>
> </xsd:complexType>
> </xsd:element>
> <xsd:element name="option">
> <xsd:complexType>
> <xsd:sequence>
> <xsd:element maxOccurs="unbounded" minOccurs="0"
> ref="alias"/>
> <xsd:element maxOccurs="unbounded" minOccurs="0"
> ref="group"/>
> <xsd:element maxOccurs="unbounded" minOccurs="0"
> ref="argument"/>
> </xsd:sequence>
> <xsd:attribute name="description" type="xsd:string"
> use="optional"/>
> <xsd:attribute name="id" type="xsd:string"
use="optional"/>
> <xsd:attribute name="name" type="xsd:string"
> use="optional"/>
> <xsd:attribute name="required" type="xsd:string"
> use="optional"/>
> </xsd:complexType>
> </xsd:element>
> </xsd:schema>
>
> --David
>
>
>>>>roxspring@imapmail.org 12/23/2004 5:55:18 AM >>>
>
> Hi,
>
> Sorry for the lack of response to your patch, I've been really busy
> with the
> day job lately and CLI2 has effectively stalled in the meantime.
> Hopefully
> I'll find some time between xmas and new year to get things in motion
> again.
> The main thing that needs doing is to go through bugzilla reviewing
> patches
> and deciding how to resolve/when to target the other bugs.
>
> Once that is done then its just a case of going through the release
> process:
> http://jakarta.apache.org/commons/releases/index.html
>
> Obviously it'd be great to have you on hand to discuss any
> thoughts/implications regarding your patch (might even get time to
look
> at
> that this afternoon); but if you have any thoughts / patches regarding
> other
> issues or documentation then please let me know! Also if anything in
> the
> releases doc looks doable then you're welcome to take it on.
>
> Thanks,
>
> Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic