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? -- With kind regards, Geoffrey De Smet _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

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?

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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev > _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

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(a)codehaus.org <mailto:mproctor@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(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/rules-dev >> > > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/rules-dev > _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org <mailto:rules-dev@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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev