[jboss-as7-dev] Automagic Interfaces

[David Bosschaert]

FWIW, it might also be an idea to consider using XML Schema as the 
master of everything and fill the gaps in there with xs:appinfo tags.

A good while ago I developed a graphical editor for Eclipse that was 
purely based on schema. It rendered the GUI dynamically based on the XML 
Schema [3]. For certain things there was no holder in XML Schema, and in 
those cases XML-Schema appInfo annotations were used. For an example see 
[1] and for more details see [2].

While not everybody likes the looks of XML and XML Schema, there are a 
number of benefits associated with the approach.

* While the GUI that I wrote at the time dynamically dealt with the XML 
Schema, the parsing code in the runtime was actually generated java and 
hence high-performance. Similarly, the XML parsing code that is 
currently in AS7, could be generated from such an XML schema I think, 
without losing performance.
* The XML Schema contains the documentation which you can use for both 
online and printed documentation.
* When changing/extending/maintaining, the only thing needed was to add 
an extra piece of XML schema in, which was quite quick and straightforward.
* But, possibly the biggest advantage is that there is only a single 
source of the configuration metadata, which means nothing (parser, gui, 
documentation) ever gets out of sync.

Anyway, just a thought. At the time when this project was used (during 
my IONA days) people quite liked the approach...

Cheers,

David

[1] 
http://wiki.eclipse.org/STP/Policy_editor_documentation#Further_Customizations
[2] http://wiki.eclipse.org/STP/Policy_Component/XEF_Reference
[3] Note that something that is represented as XML Schema doesn't have 
to be represented as XML at runtime. You could use it for the runtime 
model that AS7 has today...

On 25/07/2011 12:50, Heiko Braun wrote:
>
>
> Not sure if we are on the page wrt to this discussion.
> (you lost me somewhere) but here are my thoughts about the value type 
> descriptions
> and automagic interfaces:
>
> Instead of using the VALUE_TYPE descriptions to get to know the inner 
> structure of a complex attribute,
> we could aim for a more simple approach: turn complex attributes into 
> sub resources.
>
> This is not possible straight away and has certain implications:
>
> *Sub resources need to be addressable*
>
> Consider the "jsp-configuration" of subsystem web for instance.
> it's not addressable per se, but it easily can be made addressable:
>
> /subsystem=web/config=jsp:read-resource
> /subsystem=web/config=jsp:read-attribute(name=development)
>
> What do we gain?  implicit operations for a the sub resource:
> (add, remove, read/write-arribute, etc)
>
> With this we are much closer to automagic interfaces,
> then the burden parse & analyze some half-baked description of the 
> structures at hand.
>
> Why "half-baked"? Well, IMO the current description of types and 
> constraints are straight forward
> and easy to understand, but far from be descriptive enough to 
> automagically generate interfaces.
>
> It's still very hard to generate human interfaces from proper xml 
> schema descriptions
> and the DMR descriptions don't cover the detail and descriptiveness of 
> xml schema yet.
> And in my opinion the shouldn't.
>
> We better stick to our simple & straight forward mantra
> and improve/refactor the current model descriptions like described 
> above before puling the sledgehammer.
>
> Ike
>
> On Jul 25, 2011, at 1:21 PM, Jason Greene wrote:
>
>> Not every complex structure in the DMR tres is addressable. You can 
>> have a single attribute that contains multiple values (like passing a 
>> map Iin Java, a struct in C etc).
>>
>> Read-description is supposed to describe the structure of these 
>> complex attributes using VALUE_TYPE
>>
>> Sent from my iPad
>>
>> On Jul 25, 2011, at 5:09 AM, Heiko Braun <hbraun at redhat.com 
>> <mailto:hbraun at redhat.com>> wrote:
>>
>>>
>>>
>>> Can you elaborate on this?
>>> I don't understand what you mean ...
>>>
>>> On Jul 23, 2011, at 2:26 PM, Jason Greene wrote:
>>>
>>>> If we allow value types then all of our interfaces need to know how 
>>>> to handle them
>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev at lists.jboss.org <mailto:jboss-as7-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev