1:28 p.m.
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