Re: Intake mask compatibility from 2.2 to 2.3 - contains or matches?

[co...@xs4all.nl]

We could think of a compromise and have a *flexible* setting (similiar to
checking Dates) that determines whether contains or matches should be
used.

i.e.
flexible = true = contains
flexible = false = matches

Best of both worlds.

Colin

> Scott Eade wrote:
>> When intake was converted from regexp to oro the behaviour of the mask
>> rule was changed from "contains" to "matches".
>>
>> Does anyone have a particular concern about this?
>>
>> I myself have had to update one particular mask to achieve the old
>> behaviour.
>>
>> We can either switch intake to use "contains" or we can add a note to
>> the 2.2 to 2.3 migration documentation indicating that regular
>> expressions will need to be updated.
>>
>> Opinions?
>
> Mine depends upon the preferred behavior of the operation.  What are
> people's
> use cases for that functionality?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

Re: Intake mask compatibility from 2.2 to 2.3 - contains or matches?

[Scott Eade <se...@backstagetech.com.au>]

collie@xs4all.nl wrote:

>We could think of a compromise and have a *flexible* setting (similiar to
>checking Dates) that determines whether contains or matches should be
>used.
>
>i.e.
>flexible = true = contains
>flexible = false = matches
>
>Best of both worlds.
>  
>
That makes sense, but I think it would be better if the existing "flexible" rule was renamed "lenientDateFormats" in order to associate it with the rules it is modifying.

Modifying one or more rules using another rule doesn't really feel right to me.  I think it would be better to express the match/contains decision in the "mask" rule itself, but this would require the dtd to be updated for every rule that used such a concept (I guess an XML schema would be able to handle this better).  An alternative might be to use a different rule for match than contain.

Scott
-- 
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au





---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org