Implement categories / fix the PR - Ondra
Metadata API - Lincoln
Filtering and selection (UI) - Jess
+1, step-by-step, no rushing :) But eventually. ;-)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.)
Right, rules themselves won't probably have much specific metadata for now. They will rather "inherit" from the higher structures.
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.
~Lincoln
On Thu, Feb 19, 2015 at 8:55 AM, Ondrej Zizka <ozizka@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/windup-dev
--
_______________________________________________ windup-dev mailing list windup-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/windup-dev