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

[Michael Neale]

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> 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
> >> 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
> >
>
> _______________________________________________
> 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/20070129/fb090604/attachment.html