[windup-dev] Rules API
Lincoln Baxter, III
lincolnbaxter at gmail.com
Mon May 5 11:27:18 EDT 2014
Sure, take this example:
.addRule()
> .when(Selection.exists(XMLFile.class, "xmls")
> .with(Element.DOCTYPE, "
> http://maven.apache.org/POM/4.0.0")
> )
> .perform(Iteration.over(XMLFile.class, "xmls", "pom"
> ).as(MavenPomFile.class)
> .perform(
>
> Graph.replace(Selection.current(XMLFile.class))
>
> .with(Selection.current(MavenPomFile.class))
> )
> )
Now consider what would happen if we were to parameterize the DOCTYPE
statement:
.addRule()
> .when(Selection.exists(XMLFile.class, "xmls")
> .with(Element.DOCTYPE, "http://
> {domain}/POM/4.0.0")
> )
What if we want to match some domains and not others? Well, we'll need to
configure the parameter:
> .addRule()
> .when(Selection.exists(XMLFile.class, "xmls")
> .with(Element.DOCTYPE, "http://
> {domain}/POM/4.0.0")
> )
> .where("domain").matches("(maven.apache.org|
> jboss.org/maven|example\\.(com|org|net))").convertedBy(new
> URLDomainConverter()).bindsTo(new GraphBinding("xml>domain"))
This would both ensure that the parameter matches only what was contained
in the regular expression, but also adds a converter which stores the value
in the graph (somehow) as a URLDomain (which just for example's sake is a
@VertexFrame annotated interface.) Keep in mind that this is just a
hypothetical example.
The full battery of parameter configuration options are:
> .where(String param)
> .matches(String regex)
> .constrainedBy(Constraint constraint)
> .convertedBy(Converter converter)
> .validatedBy(Validator validator)
> .bindsTo(Binding binding)
> .configuredBy(ParameterConfigurator configurator) // can do any of the
> above
~Lincoln
On Mon, May 5, 2014 at 11:05 AM, Jess Sightler <jsightle at redhat.com> wrote:
> Could you explain the "where" clause in more detail here? I have seen
> this a few times in your examples, but I'm not entirely clear on what it is
> doing. :)
>
>
>
> On 05/05/2014 10:33 AM, Lincoln Baxter, III wrote:
>
> .addRule()
> .when() // if
> .perform() // then
> .otherwise() // else
> .where("paramName1").configuredBy(...).where("paramName2") // configure
> parameters
>
>
> On Mon, May 5, 2014 at 10:23 AM, Lincoln Baxter, III <
> lincolnbaxter at gmail.com> wrote:
>
>> 1) The (when, perform) structure would be basic for all rules?
>>
>> Yes, there are actually a few more structures:
>>
>> .addRule()
>> .when() // if
>> .perform() // then
>> .otherwise() // else
>>
>>
>> 2) This seems like it will build object tree, which will then be
>> processed, right? No space for custom code?
>>
>> You can already do exactly what you just suggested :) Custom code is no
>> problem, it just accepts an object like any normal Java code - it's just
>> Java.
>>
>>
>> 3) Isn't that a fluent API overuse? How about something like:
>>
>> I don't know what you are referring to here as overuse, but yes, I am
>> exaggerating the use of the fluent API to make a point. The rules could be
>> completely un-fluent and still use these same APIs. I'm not sure I see the
>> point/difference of the sample you've shown.
>>
>> 4) .withDoctype("http://maven.apache.org/POM/4.0.0") ?
>> doctype is a property... Better .with(PropNames.DOCTYPE,
>> "http://maven.apache.org/POM/4.0.0") ?
>>
>> I agree, some kind of more general structure here would probably be
>> better.
>>
>>
>> 5) Could the variable be filled outside .when () ? But perhaps just a
>> matter of taste.
>>
>> Absolutely you could - and yes, it's all a matter of taste :)
>>
>>
>> On Fri, May 2, 2014 at 7:26 PM, Ondrej Zizka <ozizka at redhat.com> wrote:
>>
>>> Hi,
>>>
>>> WRT rules API, as proposed at
>>>
>>> https://github.com/windup/windup/blob/master/engine/config/api/src/main/java/org/jboss/windup/addon/config/example/MavenExampleConfigurationProvider.java#L22
>>>
>>> It's nice, with some comments.
>>>
>>> I know it was typed in a hurry, but anyway:
>>>
>>> 1) The (when, perform) structure would be basic for all rules?
>>>
>>> 2) This seems like it will build object tree, which will then be
>>> processed, right? No space for custom code?
>>>
>>> 3) Isn't that a fluent API overuse? How about something like:
>>>
>>> new ConfigBuilder( ... ){{
>>> addRule( new MavenPomRule( this, ... ){
>>> boolean when( ) { return Selection.exists(XMLFile.class,
>>> "xmls").with("doctype", DOCTYPE_POM); }
>>> void perform( MavenPomInfo mpi ){ ... }
>>> }
>>> );
>>> }}.run();
>>>
>>> It's verbose now but with Java 8 lambdas, it would be less.
>>>
>>> While it's a bit more verbose, it would have obvious benefits of better
>>> debuggability, and would better leverage Java's features like
>>> inheritance (imagine AbstractXmlFileRule and it's subclasses for
>>> whatever one would want to do with a XML file, having few of its
>>> properties passed as parameters.
>>>
>>> Btw this code above is inspired by Wicket and GWT.
>>>
>>> 4) .withDoctype("http://maven.apache.org/POM/4.0.0") ?
>>> doctype is a property... Better .with(PropNames.DOCTYPE,
>>> "http://maven.apache.org/POM/4.0.0") ?
>>>
>>> 5) Could the variable be filled outside .when () ? But perhaps just a
>>> matter of taste.
>>>
>>> More later when we have some more examples.
>>>
>>> Nice!
>>> Ondra
>>> _______________________________________________
>>> windup-dev mailing list
>>> windup-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/windup-dev
>>>
>>
>>
>>
>> --
>> Lincoln Baxter, III
>> http://ocpsoft.org
>> "Simpler is better."
>>
>
>
>
> --
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."
>
>
> _______________________________________________
> windup-dev mailing listwindup-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/windup-dev
>
>
>
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
>
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140505/c5008525/attachment-0001.html
More information about the windup-dev
mailing list