[rules-dev] externalize solver configuration - which technology?

[Mark Proctor]

Once your XML has stabalised and you are happy with it, I can evetually 
help you make an exercise parse if needed - doesn't take long, based on 
our existing pluggeable framework.

mark
Michael Neale wrote:
> Yeah the control in XStream is limited of course, but that XML looks 
> nice enough. You can also easily generate a schema for reference 
> purposes as needed.
>
> Of course, as mark said, we can bake this into a non XML grammar 
> eventually, but for now, I think that looks fine ! (as long as its 
> documented with lots of examples !).
>
> Michael.
>
> On 1/29/07, *Mark Proctor* <mproctor at codehaus.org 
> <mailto:mproctor at codehaus.org>> wrote:
>
>     As long as you don't care about controlling the output too much,
>     XStream
>     is simple and nice.
>
>     XML is good and quick way to prototype what you are doing,
>     hopefully we
>     can eventually also build this into the antlr grammar.
>
>     Mark
>     Geoffrey De Smet wrote:
>     > Michael told me on irc that XStream might also be a good idea.
>     >
>     > Since I 'd like the configuration as a separate domain object model,
>     > I tryed it that way and it looks ok:
>     >
>     >
>     > <LocalSearchSolver>
>     >   <randomSeed>5</randomSeed>
>     >   <finish class="StepCountFinish">
>     >     <maximumStepCount>50</maximumStepCount>
>     >   </finish>
>     > </LocalSearchSolver>
>     >
>     > What do you think of such kind of local search solver configuration?
>     >
>     >
>     >
>     > Here are the classes that do it, they follow the builder pattern:
>     >
>     > @XStreamAlias("LocalSearchSolver")
>     > public class LocalSearchSolverConfig {
>     >
>     >     private long randomSeed = 0;
>     >
>     >     @XStreamAlias("finish")
>     >     private FinishConfig finishConfig;
>     >
>     >     public LocalSearchSolver build() ...
>     >
>     > }
>     >
>     > @XStreamAlias("StepCountFinish")
>     > public class StepCountFinishConfig implements FinishConfig {
>     >
>     >     private int maximumStepCount = 100;
>     >
>     >     public Finish build() ...
>     >
>     > }
>     >
>     >
>     > which looks a lot easier than fiddling around with sax or DOM?
>     > Xsd might be a problem - but maybe some day XStream can use the
>     > javadocs to generate an xsd? If not, it shouldn't be to hard to
>     > replace the config package with a sax or dom based configuration
>     - or
>     > just manually write an xsd.
>     >
>     > With kind regards,
>     > Geoffrey De Smet
>     >
>     >
>     > Mark Proctor wrote:
>     >> Look at our xml reader.Its xerces based and pluggeable and should
>     >> easily be able to adapt to anything.
>     >>
>     >> Mark
>     >> Geoffrey De Smet wrote:
>     >>> For the solver I 'd like to externalize the configuration into an
>     >>> xml(?)  file.
>     >>> something like
>     >>>
>     >>> <localsearch decisionMode="OPTIMAL">
>     >>>    <finish steps="500"/>
>     >>>    <ruleBase location="/org/foo/bar/drools.drl"/>
>     >>> </localsearch>
>     >>>
>     >>> This is a bit inspired by how ehcache is configured, clean and
>     easy,
>     >>> without any class implementation details: the way users like it.
>     >>>
>     >>>
>     >>> I 've been thinking on doing this with XStream, but that's not
>     >>> versatile enough to make user friendly configuration files.
>     Although
>     >>> Xstream works out great to serialize solutions to and from xml
>     files.
>     >>>
>     >>> Next I was thinking about is JDom or Xom, but that's yet another
>     >>> dependency. What would you guys recommend?
>     >>>
>     >>>
>     >>
>     >> _______________________________________________
>     >> rules-dev mailing list
>     >> rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>     >> https://lists.jboss.org/mailman/listinfo/rules-dev
>     >>
>     >
>     > _______________________________________________
>     > rules-dev mailing list
>     > rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/rules-dev
>     >
>
>     _______________________________________________
>     rules-dev mailing list
>     rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/rules-dev
>     <https://lists.jboss.org/mailman/listinfo/rules-dev>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20070130/c6027773/attachment.html