Running the Javascript rules

Devan Goodwin dgoodwin at rm-rf.ca
Tue Mar 16 13:41:28 UTC 2010


This looks good but are you using something to auto-format the code,
and if so is it possible to turn it off? This code has changed and
you'll likely get some conflicts, I don't think they'll be too bad but
they'll definitely be worse than if the unnecessary formatting wasn't
changed, similarly for anyone who gets conflicts resulting from these
changes.

As for the patch itself great change, much easier to test different
rules files now.

Also as Jesus pointed out yesterday the ProductServiceAdapter could
probably go too, looking at how it's used it would likely require a
change to the methods on the interface but nothing major.

Cheers,

Devan

On Mon, Mar 15, 2010 at 8:24 PM, Adam Young <ayoung at redhat.com> wrote:
> I added a new  Constructor to JavascriptEnforcer:
>
>
>  public JavascriptEnforcer(DateSource dateSource, Reader rulesReader,
>        PreEntHelper preHelper, PostEntHelper postHelper,
>        ProductServiceAdapter prodAdapter, ScriptEngine jsEngine)
>
>
> I also left the old one, but changed its implementation to call the new one:
>  public JavascriptEnforcer(DateSource dateSource, RulesCurator rulesCurator,
>        PreEntHelper preHelper, PostEntHelper postHelper,
>        ProductServiceAdapter prodAdapter) {
>
>            this(dateSource, new
> StringReader(rulesCurator.getRules().getRules()),
>            preHelper, postHelper, prodAdapter, new ScriptEngineManager()
>                .getEngineByName("JavaScript"));
> }
>
> However, this type of construction code is really no appropriate a class
> like this.  Jesus mentioned that he feels the same way about
> ProductServiceAdapter, which I will look at in a little bit.
>
>
> With those changes, I can make a stand alone unit test that runs without any
> Hibernate support, at least for calling
> public Pool selectBestPool(Consumer consumer, String productId, List<Pool>
> pools);
>
>
> The next piece of trickiness is loading in the Javascript file.  For static
> deployments, the usual way to find a text file like this is:
>
>    URL url =
>  this.getClass().getClassLoader().getResource("rules/default-rules.js");
>    InputStreamReader inputStreamReader = new
> InputStreamReader(url.openStream());
>
> Which works fine so long as the resource is on the classpath.  Thus for the
> Junit test, I added a file CLASSPATH extension which was
> "target/test/resources".  Since it looks like we are regenerating  the
> .project file from git sources, this might not live across check-ins.
>
>
> I'm thinkin that if our goal is to make the Javascript something that the
> end use is responsible for editing and deploying, we need to provide the
> user with a tool to go through the edit-deploy-debug cycle.  Are we planning
> on doing that as part of the web app?  Are we going to allow the user to
> deploy multiple .js rules files, and indicate which is the "live" one?
>
>
> Both patch and html diff are are attached.
>
>
> _______________________________________________
> candlepin mailing list
> candlepin at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/candlepin
>
>



-- 
Devan Goodwin <dgoodwin at rm-rf.ca>
http://rm-rf.ca



More information about the candlepin mailing list