jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Omid <omil...@gmail.com>
Subject Re: why no pattern for item definition names?
Date Fri, 08 Apr 2011 13:46:26 GMT
As a map-like (string->string) structure I use properties like
@map1-key=value and @map2-key=value. Now I need to define different
definitions for map1 & map2 properties (say not have map2 ones in
index).

Sure it's not something that must be this way. I solved this by moving
map2 ones into a new child node so they became like map2/@key=value.
But why forcing the structure if there's nothing against enabling
patterns? I guess this pattern of naming nodes & properties is used a
lot (for map-like access in browsing), and now if we want different
types for two maps they should be separated into two nodes.

On Fri, Apr 8, 2011 at 6:02 PM, Jukka Zitting <jzitting@adobe.com> wrote:
> Hi,
>
> On 04/08/2011 03:25 PM, Omid wrote:
>>
>> I expected to be able to use patterns for name of node&  property
>> definition in node types. But it doesn't work, and it's mentioned in
>> specification that other than simple name, only * pattern can be used
>> that matches all unmatched items with property type. Is there a reason
>> for not allowing more flexible patterns?
>>
>> I had a look into source and it seems fairly easy to implement this,
>> should I go on and do so?
>
> Do you have a good use case where you'd need such a feature? Why can't that
> use case be covered with the existing * pattern?
>
> --
> Jukka Zitting
>

Mime
View raw message