You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Rob Oxspring <ro...@imapmail.org> on 2004/12/30 15:26:19 UTC
[CLI] XML Support (was Re: [CLI] Status)
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
>
> David Morris wrote:
>
>>I used the COMMONS CLI package for a couple of recent projects and I
>
> ran
>
>>into some serious problems and submitted some patches. Next, I tried
>>version 2, which appears to be a ground up rewrite. It worked a lot
>>better after a couple of minor tweaks and a patch. I don't see much
>>activity lately in CVS. I need this to be a released product. In
>>addition to patches for the outstanding issues, is there anything
>
> else I
>
>>can do to help this get moving?
>>
>>David
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org