You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Omid <om...@gmail.com> on 2011/04/08 15:25:47 UTC

why no pattern for item definition names?

Hi,

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?

Re: why no pattern for item definition names?

Posted by Alexander Klimetschek <ak...@adobe.com>.
On 08.04.11 15:46, "Omid" <om...@gmail.com> wrote:
>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.

You can use residual properties "*" and have different types for each
property, on demand.

I understand your reasoning, but from experience I can tell you, if you go
"partially" unstructured, go the whole way. Whenever you come up with a
new "map-something" property pattern, you have to update your node types.
With fully unstructured nodes you don't.

Regards,
Alex

-- 
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel





Re: why no pattern for item definition names?

Posted by Omid <om...@gmail.com>.
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 <jz...@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
>

Re: why no pattern for item definition names?

Posted by Jukka Zitting <jz...@adobe.com>.
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