[windup-dev] RuleProvider's and Rule's metadata

[Ondrej Zizka]

After today's meeting dedicated to this topic, we

* Updated 
https://docs.google.com/document/d/1F07dzjkAwupZ7-FusBP6OQXDkQzwwKqnqL7gEvw7nrc/edit#

* Created https://issues.jboss.org/browse/WINDUP-520

* Split these tasks:

 1.

    Implement categories / fix the PR - Ondra

 2.

    Metadata API - Lincoln

 3.

    Filtering and selection (UI) - Jess

 4. XML handlers to actually define rules metadata in XML - Matej?



The rest inline.


On 19.2.2015 23:12, Lincoln Baxter, III wrote:
> Hey Ondra,
>
> For now, let's continue using Rule objects as Contexts. Once the 
> prototype is working and tested, we can look at ways to add a real API 
> onto the Rule objects (or possibly add some indirection or abstraction.)
+1, step-by-step, no rushing :) But eventually. ;-)
>
> Keep in mind that you shouldn't be focused too much on the individual 
> Rule objects, you probably should be focused on the Rule Providers 
> that they are loaded from (since we do most of our filtering on the 
> RuleProviders themselves, not on the rules.) I would be a lot more 
> willing to change the RuleProvider API to add the getMetadata() method 
> that you are looking for than I would be changing the Rule API in Rewrite.
Right, rules themselves won't probably have much specific metadata for 
now. They will rather "inherit" from the higher structures.

--
Ondra

>
> ~Lincoln
>
> On Thu, Feb 19, 2015 at 8:55 AM, Ondrej Zizka <ozizka at redhat.com 
> <mailto:ozizka at redhat.com>> wrote:
>
>     Hi all,
>
>     I am working on the categories.
>     I think we all agree that this should have a nice API since every rule
>     will work with that, directly or indirectly.
>     We will get more metadata, and "hiding" them into various places,
>     untyped hashmaps of lists of strings, really seems like a bad way
>     to do it.
>
>     After some work on the subject, I think we should abandon the current
>     unfortunate approach of Rules acting like a map through being a
>     Rule and
>     Context at the same time, needing conditional retyping. And the other
>     way of overriding methods like enhanceMetadata() is not fortunate
>     either
>     as every subclass needs to be aware of what's going on in the
>     superclasses.
>
>     Instead, we should follow the *conventions*, take the *standard*
>     approach, and let Rules have a normal getMetadata(), which would
>     return
>     an object with all the metadata at one place. This could be subclassed
>     to match the needs of individual addons but provide type-safe and
>     easy-to-use API for shared metadata.
>
>     getPhase(), getExecute*(), getCategories() etc. could
>     a) still return what they return, being executed by the loader as now,
>     and put to that object, or
>     b) let the rule initialize this object in rule's init() (which we
>     don't
>     have) or a construtor;
>            I would drop get*() but we could tunel them to that object for
>     backwards compatibility.
>
>     I think this goes beyond the scope of Windup and would need a
>     rewrite of
>     Rewrite (well, not real rewrite, but I liked the pun :).
>
>     Other option is to keep scattering metadata in various places, untyped
>     hashmaps of lists of strings. Not recommended.
>
>     WDYT?
>     Ondra
>     _______________________________________________
>     windup-dev mailing list
>     windup-dev at lists.jboss.org <mailto:windup-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20150303/e63012d6/attachment.html