Re: [windup-dev] RuleModel et al.

1) A reference to the rule being executed could be made accessible from a context. 2) Some layer above Frames could catch any creation/alteration of vertices and link them. Haven't seen Frames guts, perhaps not doable easily at the moment. On 22.7.2014 17:30, Jess Sightler wrote: > But how does it know which vertices were created (or modified) by > that rule? > > On 07/22/2014 10:57 AM, Lincoln Baxter, III wrote: >> The rule executor (RuleSubset) could actually handle doing this I >> think. For each rule it executes, set the ID, the version, and the >> phase in the graph (and possibly also a stringification of what the >> rule consists of) >> >> >> On Tue, Jul 22, 2014 at 10:09 AM, Jess Sightler <jsightle(a)redhat.com >> <mailto:jsightle@redhat.com>> wrote: >> >> Oh, I see... if we are going to do this, I could see it having a >> few things: >> >> 1. RuleID - A string uniquely identifying the rule >> 2. Rule Version - The version of the addon containing the rule >> 3. RulePhase - The phase during which the rule was run >> >> I don't think that this belongs in reporting, though. I am also >> not sure >> how easy it would be to automate the population of these fields, >> though >> it might be possible with some tweaks to frames. >> >> On 07/21/2014 08:59 PM, Ondrej Zizka wrote: >> > So far, an ID and a reference to the Ruleset. The ruleset then >> would >> > probably have further info, like, version etc. >> > >> > >> https://github.com/OndraZizka/windup/blob/3940b146f811ab6e5fff1cb6c6def71... >> > >> > Anyway, even if it was just an ID, OOP principles suggest to >> encapsulate >> > that ID to a type. My experience agrees. I may be wrong though. >> > >> > Ondra >> > >> > >> > On 22.7.2014 02:40, Jess Sightler wrote: >> >> I'm not opposed to this idea... except that I don't know what a >> >> "RuleModel" would actually contain, other than the ID. >> >> >> >> What are you proposing it to contain? >> >> >> >> On 07/21/2014 07:03 PM, Ondrej Zizka wrote: >> >>> We should have $subj: >> >>> >> >>> We need to refer to the rules in the report. >> >>> We agreed to store all information in the graph. >> >>> Current ID is not guaranteed to be the same over runs. >> >>> Current ID has no namespaces. >> >>> >> >>> my2c. >> >>> Ondra >> >>> >> >>> _______________________________________________ >> >>> windup-dev mailing list >> >>> windup-dev(a)lists.jboss.org <mailto:windup-dev@lists.jboss.org> >> >>> https://lists.jboss.org/mailman/listinfo/windup-dev >> >> _______________________________________________ >> >> windup-dev mailing list >> >> windup-dev(a)lists.jboss.org <mailto:windup-dev@lists.jboss.org> >> >> https://lists.jboss.org/mailman/listinfo/windup-dev >> > _______________________________________________ >> > windup-dev mailing list >> > windup-dev(a)lists.jboss.org <mailto:windup-dev@lists.jboss.org> >> > https://lists.jboss.org/mailman/listinfo/windup-dev >> >> _______________________________________________ >> windup-dev mailing list >> windup-dev(a)lists.jboss.org <mailto:windup-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/windup-dev >> >> >> >> >> -- >> Lincoln Baxter, III >> http://ocpsoft.org >> "Simpler is better." >> >> >> _______________________________________________ >> windup-dev mailing list >> windup-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/windup-dev > > > > _______________________________________________ > windup-dev mailing list > windup-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/windup-dev _______________________________________________ windup-dev mailing list windup-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/windup-dev