You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Knut Wannheden <kn...@paranor.ch> on 2003/10/06 10:58:57 UTC
[HiveMind] more on BuilderFactory
Hi,
I had a few more ideas on how BuilderFactory can be improved. These
improvements mainly address the usage and extensibility of the service.
Right now the BuilderFactory is very flexible, but this comes at a cost: the
syntax is fairly complicated: there are four attributes and 17 different
nested elements...
I have been thinking if all the <set...> elements could be replaced with a
single <property> element. This element could then have a "translator" (or
"type") attribute; e.g.
<property name="foo" value="22" translator="int"/>
Having a single element would of course mean that the translator feature of
the XML processing rules can't be used anymore, as the rules don't provide
conditional processing mechanisms. But the translation could also be
performed by the service itself, as the translator to be used is given. If
there were some kind of translator registry the BuilderFactory could then
also easily support new (even custom) translators, without requiring its
syntax to change. E.g.
<property name="foo" value="22.33" translator="float"/>
This idea could of course even be taken a step further. The "translator"
attribute could be skipped all together. Then the type of the corresponding
setter's attribute would tell BuilderFactory what translator to use.
Afterall, the type specified by the setter needs to be matched by the
translator. So specifying the type of the property in the hivemodule.xml
might be considered redundant by the user.
But what about <set-configuration> and <set-service>? If the setter
specifies a java.util.List parameter, then the corresponding configuration
could be looked up, and if an interface is required then a service could be
looked up. As a consequence setters with a List parameter could only accept
configurations, when used by HiveMind. If this is too restrictive, the
"translator" attribute could be optional, in which case also other
translators could be used for List setters.
Analogously, all constructor elements could be collapsed into a single
<constructor> element. But here the "translator" should maybe be required,
as finding the appropriate constructor could be hard otherwise.
What do you think about this idea? Would this work or have I missed
something important here? I could take a stab at implementing an optional
service implementing this strategy?
Would it make sense to add a HiveMind configuration for Translators?
Regards,
--knut
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [HiveMind] more on BuilderFactory
Posted by Knut Wannheden <kn...@paranor.ch>.
> No, just thinking in terms of build vs. new dependencies. We need to look
at the XPath component and
> see how easy it would be the mate it to HiveMind. Or we could just do an
XPath-lite.
>
OK, I see what you mean.
> http://jakarta.apache.org/commons/jxpath/index.html
>
JXPath is a great piece of software. Jaxen (http://jaxen.org/) is another
good implementation.
--knut
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [HiveMind] more on BuilderFactory
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
No, just thinking in terms of build vs. new dependencies. We need to look at the XPath component and
see how easy it would be the mate it to HiveMind. Or we could just do an XPath-lite.
http://jakarta.apache.org/commons/jxpath/index.html
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
> -----Original Message-----
> From: news [mailto:news@sea.gmane.org] On Behalf Of Knut Wannheden
> Sent: Tuesday, October 07, 2003 8:54 AM
> To: commons-dev@jakarta.apache.org
> Subject: Re: [HiveMind] more on BuilderFactory
>
>
> > Could be a step in the right direction .... the question
> is: how much
> > of
> XPath do we support? A
> > little as possible, I think.
> >
>
> Yes, I used XPath here; but it was more about illustrating
> how I think the processing elements could be restructured
> into a more intuitive form. Of course something else could
> be used as well. But I thought XPath would be a good match
> for this kind of thing. For example, it could be convenient
> to access values of parent or child elements. Why do you
> think as little as possible of XPath should be supported?
> Because you intend to support OGNL and/or Jython in the
> future? I like XPath because you can only navigate with it.
>
>
>
> > So ... translators become xpath functions ... that's cool.
> >
>
> A possibility in XPath. But I haven't thought much about it...
>
> > I like this concept because its more unique to HiveMind,
> rather than
> > just
> a crippled version of
> > Digester.
> >
>
> As I see it the HiveMind processing rule mechanism is a
> hybrid of a stripped down RelaxNG (to define the syntax) and
> an XMLified Digester (to define the correspondance in Java
> code). IMHO the syntax for the processing rules could be
> much improved. I've been playing with different ideas and
> came up with the solution presented in the last mail.
>
> Another approach would be to split the syntax definition and
> the rules part and use a pattern matching style (a la XSLT)
> for the rules. This makes it easy to read for a user of the
> configuration or service. Continuing with the same example:
>
> <element name="task">
> <attribute name="order" required="true"/>
> <attribute name="title" required="true"/>
> <attribute name="class"/>
> <attribute name="service-id"/>
> <element name="invoke-static">
> <attribute name="class" required="true"/>
> <attribute name="method"/>
> </element>
> </element>
>
> <rules>
> <template match="/task">
> <property setter-method="addElement">
> <object class="com.oubliette.framework.startup.service.Task">
> <property name="order" value="{int(@order)}"/>
> <property name="title" value="{@title}"/>
> <property name="executable" value="{class(@class)}"/>
> <property name="executable" value="{service(@service-id)}"/>
> <apply-templates/>
> </object>
> </property>
> </template>
> <template match="/task/invoke-static">
> <property setter-method="setExecutable">
> <object class="com.oubliette.framework.startup.service.StaticTask">
> <property name="className" value="{@class}"/>
> <property name="methodName" value="{@method}"/>
> </object>
> </property>
> </template>
> </rules>
>
> Note that I also replace the <invoke-parent> elements by a
> <property> with a "setter-method" attribute.
>
> --knut
>
> > --
> > Howard M. Lewis Ship
> > Creator, Tapestry: Java Web Components
> > http://jakarta.apache.org/tapestry
> > http://jakarta.apache.org/commons/sandbox/hivemind/
> > http://javatapestry.blogspot.com
> >
> > > -----Original Message-----
> > > From: news [mailto:news@sea.gmane.org] On Behalf Of Knut Wannheden
> > > Sent: Tuesday, October 07, 2003 6:28 AM
> > > To: commons-dev@jakarta.apache.org
> > > Subject: Re: [HiveMind] more on BuilderFactory
> > >
> > >
> > > The more I think about this, the more I wonder if the XML
> processing
> > > rules and the BuilderFactory could be joined. Afterall,
> they do very
> > > similar things...
> > >
> > > Unlike in Digester the the HiveMind processing rules are
> written in
> > > XML. So how about using a more declarative notation? Take the
> > > schema from the "Startup" configuration point of the case study
> > > (descriptions skipped):
> > >
> > > <element name="task">
> > >
> > > <attribute name="order" required="true"/>
> > > <attribute name="title" required="true"/>
> > > <attribute name="class"/>
> > > <attribute name="service-id"/>
> > >
> > > <rules>
> > > <create-object
> > > class="com.oubliette.framework.startup.service.Task"/>
> > > <read-attribute attribute="order" property="order"
> > > translator="int"/>
> > > <read-attribute attribute="title" property="title"/>
> > > <read-attribute attribute="class" property="executable"
> > > translator="class"/>
> > > <read-attribute attribute="service-id" property="executable"
> > > translator="service"/>
> > > <invoke-parent method="addElement"/>
> > > </rules>
> > >
> > > <element name="invoke-static">
> > > <attribute name="class" required="true"/>
> > > <attribute name="method"/>
> > > <rules>
> > > <create-object
> > > class="com.oubliette.framework.startup.service.StaticTask"/>
> > > <read-attribute attribute="class" property="className"/>
> > > <read-attribute attribute="method" property="methodName"/>
> > > <invoke-parent method="setExecutable"/>
> > > </rules>
> > > </element>
> > > </element>
> > >
> > > What if this were written in a more declarative way (resembling a
> > > pipeline as in Cocoon or Jelly) using XPath navigations to access
> > > attribute values:
> > >
> > > <element name="task">
> > >
> > > <attribute name="order" required="true"/>
> > > <attribute name="title" required="true"/>
> > > <attribute name="class"/>
> > > <attribute name="service-id"/>
> > >
> > > <rules>
> > > <invoke-parent method="addElement">
> > > <object class="com.oubliette.framework.startup.service.Task">
> > > <property name="order" value="{int(@order)}"/>
> > > <property name="title" value="{@title}"/>
> > > <property name="executable" value="{class(@class)}"/>
> > > <property name="executable" value="{service(@service-id)}"/>
> > > </object>
> > > </invoke-parent>
> > > </rules>
> > >
> > > <element name="invoke-static">
> > > <attribute name="class" required="true"/>
> > > <attribute name="method"/>
> > > <rules>
> > > <invoke-parent method="setExecutable">
> > > <object
> > > class="com.oubliette.framework.startup.service.StaticTask">
> > > <property name="className" value="{@class}"/>
> > > <property name="methodName" value="{@method}"/>
> > > </object>
> > > </invoke-parent>
> > > </rules>
> > > </element>
> > >
> > > </element>
> > >
> > > Note that I've used an AVT notation as in XSLT here (e.g.
> > > {@class}) and the translators are accessed as XPath functions.
> > >
> > > Just an idea that occured to me.
> > >
> > > --knut
> > >
> > > > I had a few more ideas on how BuilderFactory can be improved.
> > > > These improvements mainly address the usage and
> extensibility of
> > > > the service.
> > > >
> > > > Right now the BuilderFactory is very flexible, but this
> comes at a
> > > > cost:
> > > the
> > > > syntax is fairly complicated: there are four attributes and 17
> > > > different nested elements...
> > > >
> > > > I have been thinking if all the <set...> elements could be
> > > > replaced with a single <property> element. This element
> could then
> > > > have a "translator" (or
> > > > "type") attribute; e.g.
> > > >
> > > > <property name="foo" value="22" translator="int"/>
> > > >
> > > > Having a single element would of course mean that the
> translator
> > > > feature
> > > of
> > > > the XML processing rules can't be used anymore, as the
> rules don't
> > > > provide conditional processing mechanisms. But the
> > > translation could
> > > > also be performed by the service itself, as the translator
> > > to be used
> > > > is given. If there were some kind of translator registry the
> > > > BuilderFactory could then also easily support new (even custom)
> > > > translators, without requiring its syntax to change. E.g.
> > > >
> > > > <property name="foo" value="22.33" translator="float"/>
> > > >
> > > > This idea could of course even be taken a step further. The
> > > > "translator" attribute could be skipped all together. Then
> > > the type of
> > > > the
> > > corresponding
> > > > setter's attribute would tell BuilderFactory what
> > > translator to use.
> > > > Afterall, the type specified by the setter needs to be
> > > matched by the
> > > > translator. So specifying the type of the property in the
> > > > hivemodule.xml might be considered redundant by the user.
> > > >
> > > > But what about <set-configuration> and <set-service>? If the
> > > > setter specifies a java.util.List parameter, then the
> > > > corresponding configuration could be looked up, and if an
> > > > interface is
> > > required then
> > > > a service could
> > > be
> > > > looked up. As a consequence setters with a List parameter could
> > > > only
> > > accept
> > > > configurations, when used by HiveMind. If this is too
> > > restrictive, the
> > > > "translator" attribute could be optional, in which case
> also other
> > > > translators could be used for List setters.
> > > >
> > > > Analogously, all constructor elements could be collapsed
> > > into a single
> > > > <constructor> element. But here the "translator" should
> maybe be
> > > > required, as finding the appropriate constructor could be hard
> > > > otherwise.
> > > >
> > > > What do you think about this idea? Would this work or have I
> > > > missed something important here? I could take a stab at
> > > > implementing an optional service implementing this strategy?
> > > >
> > > > Would it make sense to add a HiveMind configuration for
> > > > Translators?
> > > >
> > > > Regards,
> > > >
> > > > --knut
> > >
> > >
> > >
> > >
> > >
> --------------------------------------------------------------------
> > > -
> > > 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [HiveMind] more on BuilderFactory
Posted by Knut Wannheden <kn...@paranor.ch>.
> Could be a step in the right direction .... the question is: how much of
XPath do we support? A
> little as possible, I think.
>
Yes, I used XPath here; but it was more about illustrating how I think the
processing elements could be restructured into a more intuitive form. Of
course something else could be used as well. But I thought XPath would be a
good match for this kind of thing. For example, it could be convenient to
access values of parent or child elements. Why do you think as little as
possible of XPath should be supported? Because you intend to support OGNL
and/or Jython in the future? I like XPath because you can only navigate
with it.
> So ... translators become xpath functions ... that's cool.
>
A possibility in XPath. But I haven't thought much about it...
> I like this concept because its more unique to HiveMind, rather than just
a crippled version of
> Digester.
>
As I see it the HiveMind processing rule mechanism is a hybrid of a stripped
down RelaxNG (to define the syntax) and an XMLified Digester (to define the
correspondance in Java code). IMHO the syntax for the processing rules
could be much improved. I've been playing with different ideas and came up
with the solution presented in the last mail.
Another approach would be to split the syntax definition and the rules part
and use a pattern matching style (a la XSLT) for the rules. This makes it
easy to read for a user of the configuration or service. Continuing with
the same example:
<element name="task">
<attribute name="order" required="true"/>
<attribute name="title" required="true"/>
<attribute name="class"/>
<attribute name="service-id"/>
<element name="invoke-static">
<attribute name="class" required="true"/>
<attribute name="method"/>
</element>
</element>
<rules>
<template match="/task">
<property setter-method="addElement">
<object class="com.oubliette.framework.startup.service.Task">
<property name="order" value="{int(@order)}"/>
<property name="title" value="{@title}"/>
<property name="executable" value="{class(@class)}"/>
<property name="executable" value="{service(@service-id)}"/>
<apply-templates/>
</object>
</property>
</template>
<template match="/task/invoke-static">
<property setter-method="setExecutable">
<object class="com.oubliette.framework.startup.service.StaticTask">
<property name="className" value="{@class}"/>
<property name="methodName" value="{@method}"/>
</object>
</property>
</template>
</rules>
Note that I also replace the <invoke-parent> elements by a <property> with a
"setter-method" attribute.
--knut
> --
> Howard M. Lewis Ship
> Creator, Tapestry: Java Web Components
> http://jakarta.apache.org/tapestry
> http://jakarta.apache.org/commons/sandbox/hivemind/
> http://javatapestry.blogspot.com
>
> > -----Original Message-----
> > From: news [mailto:news@sea.gmane.org] On Behalf Of Knut Wannheden
> > Sent: Tuesday, October 07, 2003 6:28 AM
> > To: commons-dev@jakarta.apache.org
> > Subject: Re: [HiveMind] more on BuilderFactory
> >
> >
> > The more I think about this, the more I wonder if the XML
> > processing rules and the BuilderFactory could be joined.
> > Afterall, they do very similar things...
> >
> > Unlike in Digester the the HiveMind processing rules are
> > written in XML. So how about using a more declarative
> > notation? Take the schema from the "Startup" configuration
> > point of the case study (descriptions skipped):
> >
> > <element name="task">
> >
> > <attribute name="order" required="true"/>
> > <attribute name="title" required="true"/>
> > <attribute name="class"/>
> > <attribute name="service-id"/>
> >
> > <rules>
> > <create-object
> > class="com.oubliette.framework.startup.service.Task"/>
> > <read-attribute attribute="order" property="order"
> > translator="int"/>
> > <read-attribute attribute="title" property="title"/>
> > <read-attribute attribute="class" property="executable"
> > translator="class"/>
> > <read-attribute attribute="service-id"
> > property="executable" translator="service"/>
> > <invoke-parent method="addElement"/>
> > </rules>
> >
> > <element name="invoke-static">
> > <attribute name="class" required="true"/>
> > <attribute name="method"/>
> > <rules>
> > <create-object
> > class="com.oubliette.framework.startup.service.StaticTask"/>
> > <read-attribute attribute="class" property="className"/>
> > <read-attribute attribute="method" property="methodName"/>
> > <invoke-parent method="setExecutable"/>
> > </rules>
> > </element>
> > </element>
> >
> > What if this were written in a more declarative way
> > (resembling a pipeline as in Cocoon or Jelly) using XPath
> > navigations to access attribute values:
> >
> > <element name="task">
> >
> > <attribute name="order" required="true"/>
> > <attribute name="title" required="true"/>
> > <attribute name="class"/>
> > <attribute name="service-id"/>
> >
> > <rules>
> > <invoke-parent method="addElement">
> > <object class="com.oubliette.framework.startup.service.Task">
> > <property name="order" value="{int(@order)}"/>
> > <property name="title" value="{@title}"/>
> > <property name="executable" value="{class(@class)}"/>
> > <property name="executable" value="{service(@service-id)}"/>
> > </object>
> > </invoke-parent>
> > </rules>
> >
> > <element name="invoke-static">
> > <attribute name="class" required="true"/>
> > <attribute name="method"/>
> > <rules>
> > <invoke-parent method="setExecutable">
> > <object
> > class="com.oubliette.framework.startup.service.StaticTask">
> > <property name="className" value="{@class}"/>
> > <property name="methodName" value="{@method}"/>
> > </object>
> > </invoke-parent>
> > </rules>
> > </element>
> >
> > </element>
> >
> > Note that I've used an AVT notation as in XSLT here (e.g.
> > {@class}) and the translators are accessed as XPath functions.
> >
> > Just an idea that occured to me.
> >
> > --knut
> >
> > > I had a few more ideas on how BuilderFactory can be improved. These
> > > improvements mainly address the usage and extensibility of the
> > > service.
> > >
> > > Right now the BuilderFactory is very flexible, but this comes at a
> > > cost:
> > the
> > > syntax is fairly complicated: there are four attributes and 17
> > > different nested elements...
> > >
> > > I have been thinking if all the <set...> elements could be replaced
> > > with a single <property> element. This element could then have a
> > > "translator" (or
> > > "type") attribute; e.g.
> > >
> > > <property name="foo" value="22" translator="int"/>
> > >
> > > Having a single element would of course mean that the translator
> > > feature
> > of
> > > the XML processing rules can't be used anymore, as the rules don't
> > > provide conditional processing mechanisms. But the
> > translation could
> > > also be performed by the service itself, as the translator
> > to be used
> > > is given. If there were some kind of translator registry the
> > > BuilderFactory could then also easily support new (even custom)
> > > translators, without requiring its syntax to change. E.g.
> > >
> > > <property name="foo" value="22.33" translator="float"/>
> > >
> > > This idea could of course even be taken a step further. The
> > > "translator" attribute could be skipped all together. Then
> > the type of
> > > the
> > corresponding
> > > setter's attribute would tell BuilderFactory what
> > translator to use.
> > > Afterall, the type specified by the setter needs to be
> > matched by the
> > > translator. So specifying the type of the property in the
> > > hivemodule.xml might be considered redundant by the user.
> > >
> > > But what about <set-configuration> and <set-service>? If the setter
> > > specifies a java.util.List parameter, then the corresponding
> > > configuration could be looked up, and if an interface is
> > required then
> > > a service could
> > be
> > > looked up. As a consequence setters with a List parameter could only
> > accept
> > > configurations, when used by HiveMind. If this is too
> > restrictive, the
> > > "translator" attribute could be optional, in which case also other
> > > translators could be used for List setters.
> > >
> > > Analogously, all constructor elements could be collapsed
> > into a single
> > > <constructor> element. But here the "translator" should maybe be
> > > required, as finding the appropriate constructor could be hard
> > > otherwise.
> > >
> > > What do you think about this idea? Would this work or have I missed
> > > something important here? I could take a stab at implementing an
> > > optional service implementing this strategy?
> > >
> > > Would it make sense to add a HiveMind configuration for Translators?
> > >
> > > Regards,
> > >
> > > --knut
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
Re: [HiveMind] more on BuilderFactory
Posted by Knut Wannheden <kn...@paranor.ch>.
Read the comments further down...
>
> >
> > What if this were written in a more declarative way
> > (resembling a pipeline as in Cocoon or Jelly) using XPath
> > navigations to access attribute values:
> >
> > <element name="task">
> >
> > <attribute name="order" required="true"/>
> > <attribute name="title" required="true"/>
> > <attribute name="class"/>
> > <attribute name="service-id"/>
> >
> > <rules>
> > <invoke-parent method="addElement">
> > <object class="com.oubliette.framework.startup.service.Task">
> > <property name="order" value="{int(@order)}"/>
> > <property name="title" value="{@title}"/>
> > <property name="executable" value="{class(@class)}"/>
> > <property name="executable" value="{service(@service-id)}"/>
> > </object>
> > </invoke-parent>
> > </rules>
> >
> > <element name="invoke-static">
> > <attribute name="class" required="true"/>
> > <attribute name="method"/>
> > <rules>
> > <invoke-parent method="setExecutable">
> > <object
> > class="com.oubliette.framework.startup.service.StaticTask">
> > <property name="className" value="{@class}"/>
> > <property name="methodName" value="{@method}"/>
> > </object>
> > </invoke-parent>
> > </rules>
> > </element>
> >
> > </element>
> >
>
> The problem here is that without the explicit stack-oriented approach used
with Digester, it isn't
> clear what the top object on the stack is at the time the rules for the
invoke-static contribution
> are executed. This is because <invoke-parent> wraps around <object>.
>
I don't quite understand what you mean. The top object is the object that
was added (using <invoke-parent>) by the <rules> of the <element> one level
up. In this example the nested <invoke-parent method="setExecutable"> would
pertain to the <object class="...Task"> of the enclosing <element
name="task">. But to make it clearer the <object> and <invoke-parent>
should maybe be merged into a single element.
In this example I tried to maintain the same mix of syntax and processing as
in the current implementation. But the more I think about it the more I
think that these two things shouldn't be mixed at all. Instead they should
be kept separate right from the beginning as I suggested in a later post.
If I understand Christian and Harish corretly they even seem to suggest to
decouple the two as separate services, which would let developers implement
their own. I'd for example like to use RelaxNG for specifying (and
checking) the syntax and maybe an XSLT approach for processing.
But as it is now the two concepts are very intertwined. To decouple the two
one would have to come up with a reasonably expressive, yet simple, default
implementation. But as I see it this would at least require to change the
processing part. One option would be to provide a very simple pattern based
approach, similar to what I described in another post. Or of course
something like Digester.
> I have doubts that we'll be able to use XPath here, based on what the
current Translator classes
> need to operate; I may be wrong. I need to dig through the APIs to see how
to glue it together.
>
> Actually, perhaps the Digester model is the flawed part? I still like the
idea of a declarative,
> rules-based conversion of XML to objects ... how can we make it simpler?
>
> Right now, all we can safely do is change:
>
> <read-attribute property="..." attribute="..." translator="..."/>
> <read-content property="..." translator="..."/>
>
> to:
>
> <property name="..." value="..."/>
>
> Where the value attribute will have an XPath-like expression for reading
content or attribute and
> applying a translator-ish function upon the
> value before assigning it to the property. I'm not seeing enough gain
there to make a change (the
> code change is easy, but its a lot of work to update the test suite).
>
The XPath notation was just an idea. Don't know whether it's a good one :-)
So I agree, that small change would probably not justify all the work it
implies. But if, as I said, the syntax and processing parts were split it
would be a more drastical change, in which case the processing should
probably be reconsidered.
--knut
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [HiveMind] more on BuilderFactory
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
Could be a step in the right direction .... the question is: how much of XPath do we support? A
little as possible, I think.
So ... translators become xpath functions ... that's cool.
I like this concept because its more unique to HiveMind, rather than just a crippled version of
Digester.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
> -----Original Message-----
> From: news [mailto:news@sea.gmane.org] On Behalf Of Knut Wannheden
> Sent: Tuesday, October 07, 2003 6:28 AM
> To: commons-dev@jakarta.apache.org
> Subject: Re: [HiveMind] more on BuilderFactory
>
>
> The more I think about this, the more I wonder if the XML
> processing rules and the BuilderFactory could be joined.
> Afterall, they do very similar things...
>
> Unlike in Digester the the HiveMind processing rules are
> written in XML. So how about using a more declarative
> notation? Take the schema from the "Startup" configuration
> point of the case study (descriptions skipped):
>
> <element name="task">
>
> <attribute name="order" required="true"/>
> <attribute name="title" required="true"/>
> <attribute name="class"/>
> <attribute name="service-id"/>
>
> <rules>
> <create-object
> class="com.oubliette.framework.startup.service.Task"/>
> <read-attribute attribute="order" property="order"
> translator="int"/>
> <read-attribute attribute="title" property="title"/>
> <read-attribute attribute="class" property="executable"
> translator="class"/>
> <read-attribute attribute="service-id"
> property="executable" translator="service"/>
> <invoke-parent method="addElement"/>
> </rules>
>
> <element name="invoke-static">
> <attribute name="class" required="true"/>
> <attribute name="method"/>
> <rules>
> <create-object
> class="com.oubliette.framework.startup.service.StaticTask"/>
> <read-attribute attribute="class" property="className"/>
> <read-attribute attribute="method" property="methodName"/>
> <invoke-parent method="setExecutable"/>
> </rules>
> </element>
> </element>
>
> What if this were written in a more declarative way
> (resembling a pipeline as in Cocoon or Jelly) using XPath
> navigations to access attribute values:
>
> <element name="task">
>
> <attribute name="order" required="true"/>
> <attribute name="title" required="true"/>
> <attribute name="class"/>
> <attribute name="service-id"/>
>
> <rules>
> <invoke-parent method="addElement">
> <object class="com.oubliette.framework.startup.service.Task">
> <property name="order" value="{int(@order)}"/>
> <property name="title" value="{@title}"/>
> <property name="executable" value="{class(@class)}"/>
> <property name="executable" value="{service(@service-id)}"/>
> </object>
> </invoke-parent>
> </rules>
>
> <element name="invoke-static">
> <attribute name="class" required="true"/>
> <attribute name="method"/>
> <rules>
> <invoke-parent method="setExecutable">
> <object
> class="com.oubliette.framework.startup.service.StaticTask">
> <property name="className" value="{@class}"/>
> <property name="methodName" value="{@method}"/>
> </object>
> </invoke-parent>
> </rules>
> </element>
>
> </element>
>
> Note that I've used an AVT notation as in XSLT here (e.g.
> {@class}) and the translators are accessed as XPath functions.
>
> Just an idea that occured to me.
>
> --knut
>
> > I had a few more ideas on how BuilderFactory can be improved. These
> > improvements mainly address the usage and extensibility of the
> > service.
> >
> > Right now the BuilderFactory is very flexible, but this comes at a
> > cost:
> the
> > syntax is fairly complicated: there are four attributes and 17
> > different nested elements...
> >
> > I have been thinking if all the <set...> elements could be replaced
> > with a single <property> element. This element could then have a
> > "translator" (or
> > "type") attribute; e.g.
> >
> > <property name="foo" value="22" translator="int"/>
> >
> > Having a single element would of course mean that the translator
> > feature
> of
> > the XML processing rules can't be used anymore, as the rules don't
> > provide conditional processing mechanisms. But the
> translation could
> > also be performed by the service itself, as the translator
> to be used
> > is given. If there were some kind of translator registry the
> > BuilderFactory could then also easily support new (even custom)
> > translators, without requiring its syntax to change. E.g.
> >
> > <property name="foo" value="22.33" translator="float"/>
> >
> > This idea could of course even be taken a step further. The
> > "translator" attribute could be skipped all together. Then
> the type of
> > the
> corresponding
> > setter's attribute would tell BuilderFactory what
> translator to use.
> > Afterall, the type specified by the setter needs to be
> matched by the
> > translator. So specifying the type of the property in the
> > hivemodule.xml might be considered redundant by the user.
> >
> > But what about <set-configuration> and <set-service>? If the setter
> > specifies a java.util.List parameter, then the corresponding
> > configuration could be looked up, and if an interface is
> required then
> > a service could
> be
> > looked up. As a consequence setters with a List parameter could only
> accept
> > configurations, when used by HiveMind. If this is too
> restrictive, the
> > "translator" attribute could be optional, in which case also other
> > translators could be used for List setters.
> >
> > Analogously, all constructor elements could be collapsed
> into a single
> > <constructor> element. But here the "translator" should maybe be
> > required, as finding the appropriate constructor could be hard
> > otherwise.
> >
> > What do you think about this idea? Would this work or have I missed
> > something important here? I could take a stab at implementing an
> > optional service implementing this strategy?
> >
> > Would it make sense to add a HiveMind configuration for Translators?
> >
> > Regards,
> >
> > --knut
>
>
>
>
> ---------------------------------------------------------------------
> 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
Re: [HiveMind] more on BuilderFactory
Posted by Christian Essl <ch...@yahoo.de>.
I think this way we could also solve that chicken-egg problem with rules
and translators:
The HiveMind build in processing is kept. This build in processing is used
by the ProcessingServices to have their rules, translators, xsl-functions
etc defined/added. (ProcessingServices are only allowed to use the build
in).
To differentiate between the build in processing and the 'custom-
processing' the configuration-point tag is just checked wheter it contains
a <processing> tag.
On Thu, 09 Oct 2003 11:20:09 -0400, Harish Krishnaswamy
<hk...@comcast.net> wrote:
> Yeah, I like this idea. Options are good.
>
> Christian Essl wrote:
>
>> I am personally quite happy with the digester/translator aproach
>> HiveMind uses currently.
>>
>> I like Knut's suggestion to split up the validating schema from the
>> processing.
>>
>> Maybe in a later release of HiveMind it could be possible to use a
>> something like this:
>>
>> <configuration-point>
>> <schema>....</schema>
>> <processing service-id="ie digester-id or XSLT-id">
>> ....
>> </processing>
>> </configuratino-point>
>>
>> The schema checks the elements and after this check the elements are
>> given to the defined processing-service:
>>
>> public interface ProcessingService{
>> public List getContributions(Element[] processingContent,Element[]
>> contributions,String config-id);
>> }
>>
>> I think this way the configuration-point definer could choose the form
>> he want's to define/parse the contributions.
>>
>> On Thu, 9 Oct 2003 08:35:43 -0400, Howard M. Lewis Ship
>> <hl...@comcast.net> wrote:
>>
>>> Been running around a lot, but found a few minutes to think about this
>>> in more detail.
>>>
>>>> -----Original Message-----
>>>> From: news [mailto:news@sea.gmane.org] On Behalf Of Knut Wannheden
>>>> Sent: Tuesday, October 07, 2003 6:28 AM
>>>> To: commons-dev@jakarta.apache.org
>>>> Subject: Re: [HiveMind] more on BuilderFactory
>>>>
>>>>
>>>> The more I think about this, the more I wonder if the XML processing
>>>> rules and the BuilderFactory could be joined. Afterall, they do very
>>>> similar things...
>>>>
>>>> Unlike in Digester the the HiveMind processing rules are written in
>>>> XML. So how about using a more declarative notation? Take the schema
>>>> from the "Startup" configuration point of the case study (descriptions
>>>> skipped):
>>>>
>>>
>>>>
>>>> What if this were written in a more declarative way (resembling a
>>>> pipeline as in Cocoon or Jelly) using XPath navigations to access
>>>> attribute values:
>>>>
>>>> <element name="task">
>>>>
>>>> <attribute name="order" required="true"/>
>>>> <attribute name="title" required="true"/>
>>>> <attribute name="class"/>
>>>> <attribute name="service-id"/>
>>>>
>>>> <rules>
>>>> <invoke-parent method="addElement">
>>>> <object class="com.oubliette.framework.startup.service.Task">
>>>> <property name="order" value="{int(@order)}"/>
>>>> <property name="title" value="{@title}"/>
>>>> <property name="executable" value="{class(@class)}"/>
>>>> <property name="executable" value="{service(@service-id)}"/>
>>>> </object>
>>>> </invoke-parent>
>>>> </rules>
>>>>
>>>> <element name="invoke-static">
>>>> <attribute name="class" required="true"/>
>>>> <attribute name="method"/>
>>>> <rules>
>>>> <invoke-parent method="setExecutable">
>>>> <object class="com.oubliette.framework.startup.service.StaticTask">
>>>> <property name="className" value="{@class}"/>
>>>> <property name="methodName" value="{@method}"/>
>>>> </object>
>>>> </invoke-parent>
>>>> </rules>
>>>> </element>
>>>>
>>>> </element>
>>>>
>>>
>>> The problem here is that without the explicit stack-oriented approach
>>> used with Digester, it isn't
>>> clear what the top object on the stack is at the time the rules for the
>>> invoke-static contribution
>>> are executed. This is because <invoke-parent> wraps around <object>.
>>>
>>> I have doubts that we'll be able to use XPath here, based on what the
>>> current Translator classes
>>> need to operate; I may be wrong. I need to dig through the APIs to see
>>> how to glue it together.
>>>
>>> Actually, perhaps the Digester model is the flawed part? I still like
>>> the idea of a declarative,
>>> rules-based conversion of XML to objects ... how can we make it
>>> simpler?
>>>
>>> Right now, all we can safely do is change:
>>>
>>> <read-attribute property="..." attribute="..." translator="..."/>
>>> <read-content property="..." translator="..."/>
>>>
>>> to:
>>>
>>> <property name="..." value="..."/>
>>>
>>> Where the value attribute will have an XPath-like expression for
>>> reading content or attribute and
>>> applying a translator-ish function upon the
>>> value before assigning it to the property. I'm not seeing enough gain
>>> there to make a change (the
>>> code change is easy, but its a lot of work to update the test suite).
>>>
>>> -- Howard M. Lewis Ship
>>> Creator, Tapestry: Java Web Components
>>> http://jakarta.apache.org/tapestry
>>> http://jakarta.apache.org/commons/sandbox/hivemind/
>>> http://javatapestry.blogspot.com
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
--
--
Christian Essl http://jucas.sourceforge.net
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [HiveMind] more on BuilderFactory
Posted by Harish Krishnaswamy <hk...@comcast.net>.
Yeah, I like this idea. Options are good.
Christian Essl wrote:
> I am personally quite happy with the digester/translator aproach
> HiveMind uses currently.
>
> I like Knut's suggestion to split up the validating schema from the
> processing.
>
> Maybe in a later release of HiveMind it could be possible to use a
> something like this:
>
> <configuration-point>
> <schema>....</schema>
> <processing service-id="ie digester-id or XSLT-id">
> ....
> </processing>
> </configuratino-point>
>
> The schema checks the elements and after this check the elements are
> given to the defined processing-service:
>
> public interface ProcessingService{
> public List getContributions(Element[] processingContent,Element[]
> contributions,String config-id);
> }
>
> I think this way the configuration-point definer could choose the form
> he want's to define/parse the contributions.
>
> On Thu, 9 Oct 2003 08:35:43 -0400, Howard M. Lewis Ship
> <hl...@comcast.net> wrote:
>
>> Been running around a lot, but found a few minutes to think about
>> this in more detail.
>>
>>> -----Original Message-----
>>> From: news [mailto:news@sea.gmane.org] On Behalf Of Knut Wannheden
>>> Sent: Tuesday, October 07, 2003 6:28 AM
>>> To: commons-dev@jakarta.apache.org
>>> Subject: Re: [HiveMind] more on BuilderFactory
>>>
>>>
>>> The more I think about this, the more I wonder if the XML processing
>>> rules and the BuilderFactory could be joined. Afterall, they do very
>>> similar things...
>>>
>>> Unlike in Digester the the HiveMind processing rules are written in
>>> XML. So how about using a more declarative notation? Take the
>>> schema from the "Startup" configuration point of the case study
>>> (descriptions skipped):
>>>
>>
>>>
>>> What if this were written in a more declarative way (resembling a
>>> pipeline as in Cocoon or Jelly) using XPath navigations to access
>>> attribute values:
>>>
>>> <element name="task">
>>>
>>> <attribute name="order" required="true"/>
>>> <attribute name="title" required="true"/>
>>> <attribute name="class"/>
>>> <attribute name="service-id"/>
>>>
>>> <rules>
>>> <invoke-parent method="addElement">
>>> <object class="com.oubliette.framework.startup.service.Task">
>>> <property name="order" value="{int(@order)}"/>
>>> <property name="title" value="{@title}"/>
>>> <property name="executable" value="{class(@class)}"/>
>>> <property name="executable" value="{service(@service-id)}"/>
>>> </object>
>>> </invoke-parent>
>>> </rules>
>>>
>>> <element name="invoke-static">
>>> <attribute name="class" required="true"/>
>>> <attribute name="method"/>
>>> <rules>
>>> <invoke-parent method="setExecutable">
>>> <object class="com.oubliette.framework.startup.service.StaticTask">
>>> <property name="className" value="{@class}"/>
>>> <property name="methodName" value="{@method}"/>
>>> </object>
>>> </invoke-parent>
>>> </rules>
>>> </element>
>>>
>>> </element>
>>>
>>
>> The problem here is that without the explicit stack-oriented approach
>> used with Digester, it isn't
>> clear what the top object on the stack is at the time the rules for
>> the invoke-static contribution
>> are executed. This is because <invoke-parent> wraps around <object>.
>>
>> I have doubts that we'll be able to use XPath here, based on what the
>> current Translator classes
>> need to operate; I may be wrong. I need to dig through the APIs to
>> see how to glue it together.
>>
>> Actually, perhaps the Digester model is the flawed part? I still like
>> the idea of a declarative,
>> rules-based conversion of XML to objects ... how can we make it simpler?
>>
>> Right now, all we can safely do is change:
>>
>> <read-attribute property="..." attribute="..." translator="..."/>
>> <read-content property="..." translator="..."/>
>>
>> to:
>>
>> <property name="..." value="..."/>
>>
>> Where the value attribute will have an XPath-like expression for
>> reading content or attribute and
>> applying a translator-ish function upon the
>> value before assigning it to the property. I'm not seeing enough
>> gain there to make a change (the
>> code change is easy, but its a lot of work to update the test suite).
>>
>> --
>> Howard M. Lewis Ship
>> Creator, Tapestry: Java Web Components
>> http://jakarta.apache.org/tapestry
>> http://jakarta.apache.org/commons/sandbox/hivemind/
>> http://javatapestry.blogspot.com
>>
>>
>> ---------------------------------------------------------------------
>> 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
Re: [HiveMind] more on BuilderFactory
Posted by Christian Essl <ch...@yahoo.de>.
I am personally quite happy with the digester/translator aproach HiveMind
uses currently.
I like Knut's suggestion to split up the validating schema from the
processing.
Maybe in a later release of HiveMind it could be possible to use a
something like this:
<configuration-point>
<schema>....</schema>
<processing service-id="ie digester-id or XSLT-id">
....
</processing>
</configuratino-point>
The schema checks the elements and after this check the elements are given
to the defined processing-service:
public interface ProcessingService{
public List getContributions(Element[] processingContent,Element[]
contributions,String config-id);
}
I think this way the configuration-point definer could choose the form he
want's to define/parse the contributions.
On Thu, 9 Oct 2003 08:35:43 -0400, Howard M. Lewis Ship
<hl...@comcast.net> wrote:
> Been running around a lot, but found a few minutes to think about this in
> more detail.
>
>> -----Original Message-----
>> From: news [mailto:news@sea.gmane.org] On Behalf Of Knut Wannheden
>> Sent: Tuesday, October 07, 2003 6:28 AM
>> To: commons-dev@jakarta.apache.org
>> Subject: Re: [HiveMind] more on BuilderFactory
>>
>>
>> The more I think about this, the more I wonder if the XML processing
>> rules and the BuilderFactory could be joined. Afterall, they do very
>> similar things...
>>
>> Unlike in Digester the the HiveMind processing rules are written in XML.
>> So how about using a more declarative notation? Take the schema from
>> the "Startup" configuration point of the case study (descriptions
>> skipped):
>>
>
>>
>> What if this were written in a more declarative way (resembling a
>> pipeline as in Cocoon or Jelly) using XPath navigations to access
>> attribute values:
>>
>> <element name="task">
>>
>> <attribute name="order" required="true"/>
>> <attribute name="title" required="true"/>
>> <attribute name="class"/>
>> <attribute name="service-id"/>
>>
>> <rules>
>> <invoke-parent method="addElement">
>> <object class="com.oubliette.framework.startup.service.Task">
>> <property name="order" value="{int(@order)}"/>
>> <property name="title" value="{@title}"/>
>> <property name="executable" value="{class(@class)}"/>
>> <property name="executable" value="{service(@service-id)}"/>
>> </object>
>> </invoke-parent>
>> </rules>
>>
>> <element name="invoke-static">
>> <attribute name="class" required="true"/>
>> <attribute name="method"/>
>> <rules>
>> <invoke-parent method="setExecutable">
>> <object class="com.oubliette.framework.startup.service.StaticTask">
>> <property name="className" value="{@class}"/>
>> <property name="methodName" value="{@method}"/>
>> </object>
>> </invoke-parent>
>> </rules>
>> </element>
>>
>> </element>
>>
>
> The problem here is that without the explicit stack-oriented approach
> used with Digester, it isn't
> clear what the top object on the stack is at the time the rules for the
> invoke-static contribution
> are executed. This is because <invoke-parent> wraps around <object>.
>
> I have doubts that we'll be able to use XPath here, based on what the
> current Translator classes
> need to operate; I may be wrong. I need to dig through the APIs to see
> how to glue it together.
>
> Actually, perhaps the Digester model is the flawed part? I still like the
> idea of a declarative,
> rules-based conversion of XML to objects ... how can we make it simpler?
>
> Right now, all we can safely do is change:
>
> <read-attribute property="..." attribute="..." translator="..."/>
> <read-content property="..." translator="..."/>
>
> to:
>
> <property name="..." value="..."/>
>
> Where the value attribute will have an XPath-like expression for reading
> content or attribute and
> applying a translator-ish function upon the
> value before assigning it to the property. I'm not seeing enough gain
> there to make a change (the
> code change is easy, but its a lot of work to update the test suite).
>
> --
> Howard M. Lewis Ship
> Creator, Tapestry: Java Web Components
> http://jakarta.apache.org/tapestry
> http://jakarta.apache.org/commons/sandbox/hivemind/
> http://javatapestry.blogspot.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
--
--
Christian Essl http://jucas.sourceforge.net
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [HiveMind] more on BuilderFactory
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
Been running around a lot, but found a few minutes to think about this in more detail.
> -----Original Message-----
> From: news [mailto:news@sea.gmane.org] On Behalf Of Knut Wannheden
> Sent: Tuesday, October 07, 2003 6:28 AM
> To: commons-dev@jakarta.apache.org
> Subject: Re: [HiveMind] more on BuilderFactory
>
>
> The more I think about this, the more I wonder if the XML
> processing rules and the BuilderFactory could be joined.
> Afterall, they do very similar things...
>
> Unlike in Digester the the HiveMind processing rules are
> written in XML. So how about using a more declarative
> notation? Take the schema from the "Startup" configuration
> point of the case study (descriptions skipped):
>
>
> What if this were written in a more declarative way
> (resembling a pipeline as in Cocoon or Jelly) using XPath
> navigations to access attribute values:
>
> <element name="task">
>
> <attribute name="order" required="true"/>
> <attribute name="title" required="true"/>
> <attribute name="class"/>
> <attribute name="service-id"/>
>
> <rules>
> <invoke-parent method="addElement">
> <object class="com.oubliette.framework.startup.service.Task">
> <property name="order" value="{int(@order)}"/>
> <property name="title" value="{@title}"/>
> <property name="executable" value="{class(@class)}"/>
> <property name="executable" value="{service(@service-id)}"/>
> </object>
> </invoke-parent>
> </rules>
>
> <element name="invoke-static">
> <attribute name="class" required="true"/>
> <attribute name="method"/>
> <rules>
> <invoke-parent method="setExecutable">
> <object
> class="com.oubliette.framework.startup.service.StaticTask">
> <property name="className" value="{@class}"/>
> <property name="methodName" value="{@method}"/>
> </object>
> </invoke-parent>
> </rules>
> </element>
>
> </element>
>
The problem here is that without the explicit stack-oriented approach used with Digester, it isn't
clear what the top object on the stack is at the time the rules for the invoke-static contribution
are executed. This is because <invoke-parent> wraps around <object>.
I have doubts that we'll be able to use XPath here, based on what the current Translator classes
need to operate; I may be wrong. I need to dig through the APIs to see how to glue it together.
Actually, perhaps the Digester model is the flawed part? I still like the idea of a declarative,
rules-based conversion of XML to objects ... how can we make it simpler?
Right now, all we can safely do is change:
<read-attribute property="..." attribute="..." translator="..."/>
<read-content property="..." translator="..."/>
to:
<property name="..." value="..."/>
Where the value attribute will have an XPath-like expression for reading content or attribute and
applying a translator-ish function upon the
value before assigning it to the property. I'm not seeing enough gain there to make a change (the
code change is easy, but its a lot of work to update the test suite).
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [HiveMind] more on BuilderFactory
Posted by Knut Wannheden <kn...@paranor.ch>.
The more I think about this, the more I wonder if the XML processing rules
and the BuilderFactory could be joined. Afterall, they do very similar
things...
Unlike in Digester the the HiveMind processing rules are written in XML. So
how about using a more declarative notation? Take the schema from the
"Startup" configuration point of the case study (descriptions skipped):
<element name="task">
<attribute name="order" required="true"/>
<attribute name="title" required="true"/>
<attribute name="class"/>
<attribute name="service-id"/>
<rules>
<create-object class="com.oubliette.framework.startup.service.Task"/>
<read-attribute attribute="order" property="order" translator="int"/>
<read-attribute attribute="title" property="title"/>
<read-attribute attribute="class" property="executable"
translator="class"/>
<read-attribute attribute="service-id" property="executable"
translator="service"/>
<invoke-parent method="addElement"/>
</rules>
<element name="invoke-static">
<attribute name="class" required="true"/>
<attribute name="method"/>
<rules>
<create-object
class="com.oubliette.framework.startup.service.StaticTask"/>
<read-attribute attribute="class" property="className"/>
<read-attribute attribute="method" property="methodName"/>
<invoke-parent method="setExecutable"/>
</rules>
</element>
</element>
What if this were written in a more declarative way (resembling a pipeline
as in Cocoon or Jelly) using XPath navigations to access attribute values:
<element name="task">
<attribute name="order" required="true"/>
<attribute name="title" required="true"/>
<attribute name="class"/>
<attribute name="service-id"/>
<rules>
<invoke-parent method="addElement">
<object class="com.oubliette.framework.startup.service.Task">
<property name="order" value="{int(@order)}"/>
<property name="title" value="{@title}"/>
<property name="executable" value="{class(@class)}"/>
<property name="executable" value="{service(@service-id)}"/>
</object>
</invoke-parent>
</rules>
<element name="invoke-static">
<attribute name="class" required="true"/>
<attribute name="method"/>
<rules>
<invoke-parent method="setExecutable">
<object class="com.oubliette.framework.startup.service.StaticTask">
<property name="className" value="{@class}"/>
<property name="methodName" value="{@method}"/>
</object>
</invoke-parent>
</rules>
</element>
</element>
Note that I've used an AVT notation as in XSLT here (e.g. {@class}) and the
translators are accessed as XPath functions.
Just an idea that occured to me.
--knut
> I had a few more ideas on how BuilderFactory can be improved. These
> improvements mainly address the usage and extensibility of the service.
>
> Right now the BuilderFactory is very flexible, but this comes at a cost:
the
> syntax is fairly complicated: there are four attributes and 17 different
> nested elements...
>
> I have been thinking if all the <set...> elements could be replaced with a
> single <property> element. This element could then have a "translator" (or
> "type") attribute; e.g.
>
> <property name="foo" value="22" translator="int"/>
>
> Having a single element would of course mean that the translator feature
of
> the XML processing rules can't be used anymore, as the rules don't provide
> conditional processing mechanisms. But the translation could also be
> performed by the service itself, as the translator to be used is given. If
> there were some kind of translator registry the BuilderFactory could then
> also easily support new (even custom) translators, without requiring its
> syntax to change. E.g.
>
> <property name="foo" value="22.33" translator="float"/>
>
> This idea could of course even be taken a step further. The "translator"
> attribute could be skipped all together. Then the type of the
corresponding
> setter's attribute would tell BuilderFactory what translator to use.
> Afterall, the type specified by the setter needs to be matched by the
> translator. So specifying the type of the property in the hivemodule.xml
> might be considered redundant by the user.
>
> But what about <set-configuration> and <set-service>? If the setter
> specifies a java.util.List parameter, then the corresponding configuration
> could be looked up, and if an interface is required then a service could
be
> looked up. As a consequence setters with a List parameter could only
accept
> configurations, when used by HiveMind. If this is too restrictive, the
> "translator" attribute could be optional, in which case also other
> translators could be used for List setters.
>
> Analogously, all constructor elements could be collapsed into a single
> <constructor> element. But here the "translator" should maybe be required,
> as finding the appropriate constructor could be hard otherwise.
>
> What do you think about this idea? Would this work or have I missed
> something important here? I could take a stab at implementing an optional
> service implementing this strategy?
>
> Would it make sense to add a HiveMind configuration for Translators?
>
> Regards,
>
> --knut
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org