Re: OCM: why not to hide ugly init code?
Wednesday 12 March 2008 10:52:58 Christophe Lombart написав: > If I understand you, your proposal is something like this : > 1. If the class is mapped to the unstructured node type or a node type > that gives you the possibility to add extra properties, create a new > property "ocm_classname". > 2. If it is not possible to add this property due to strong > constrains in the corresponding node type, try to add the mixin type > "ocm:discriminator" (if necessary). > > Is it something like this ? Yes, exactly. I doubd pople are using restrictive node types in real life with OCM. Counting that jcr-1.0 does not support custom node types ... So it will be rather rare exception to use some mixin type to store mapping class info. For instance JCROM OCM implementation does not require any custom node registration. BTW, it easy maps binary content. See http://code.google.com/p/jcrom/ -- SY, Alex Lukin RIPE NIC HDL: LEXA1-RIPE
Re: OCM: why not to hide ugly init code?
If I understand you, your proposal is something like this : 1. If the class is mapped to the unstructured node type or a node type that gives you the possibility to add extra properties, create a new property "ocm_classname". 2. If it is not possible to add this property due to strong constrains in the corresponding node type, try to add the mixin type "ocm:discriminator" (if necessary). Is it something like this ? Christophe On Wed, Mar 12, 2008 at 8:59 AM, Alex Lukin <[EMAIL PROTECTED]> wrote: > Wednesday 12 March 2008 00:34:27 Christophe Lombart написав: > > Just one comment : > > > > The OCM has to be completely independent of Jackrabbit core. By this > > way, it can be used with other JCR implementation. As you can see, > > Jackrabbit core is only used for the unit tests. > > That's why the code is so ugly ... until there is a standard way to > > add new node types. > I see. > So my Jira Isuue and patch has to be deleted. > Node type registration is standard in JSR-283 so we have to wait when it > will be ready. > Anyway, use of custom node types is not quite mandatory for OCM. It is > possible to use some hidden property to store needed info. > > -- > SY, Alex Lukin > RIPE NIC HDL: LEXA1-RIPE >
Re: OCM: why not to hide ugly init code?
Wednesday 12 March 2008 00:34:27 Christophe Lombart написав: > Just one comment : > > The OCM has to be completely independent of Jackrabbit core. By this > way, it can be used with other JCR implementation. As you can see, > Jackrabbit core is only used for the unit tests. > That's why the code is so ugly ... until there is a standard way to > add new node types. I see. So my Jira Isuue and patch has to be deleted. Node type registration is standard in JSR-283 so we have to wait when it will be ready. Anyway, use of custom node types is not quite mandatory for OCM. It is possible to use some hidden property to store needed info. -- SY, Alex Lukin RIPE NIC HDL: LEXA1-RIPE
Re: OCM: why not to hide ugly init code?
Just one comment :
The OCM has to be completely independent of Jackrabbit core. By this
way, it can be used with other JCR implementation. As you can see,
Jackrabbit core is only used for the unit tests.
That's why the code is so ugly ... until there is a standard way to
add new node types.
br,
Christophe
On Tue, Mar 11, 2008 at 10:32 PM, Alex Lukin <[EMAIL PROTECTED]> wrote:
> Hi, All, Hi, Christophe!
>
> I just took a look at new OCM docs at
> http://jackrabbit.apache.org/5-with-jackrabbit-ocm.html
>
> I must say taht ugly init code for annotation based OCM may be and must be
> hidden.
>
> In my application I created needed xml file and placed it in same package
> where OCM init code is.
> Then I read it directly from jar using simple code below:
>
> InputStream xml =
> this.getClass().getResourceAsStream("nodetypes-ocm.xml");
> NodeTypeDef[] types = NodeTypeReader.read(xml);
>
> Rest of init code needs Session object with superuser rights (Oh! rights on
> jackrabbit! :) ) but it is not a big problem to
> create one built-in OCM method with session as parameter.
>
> In my opinion, current init code is conerproductive and creates bad attitude
> of user just by the first look of new OCM user.
> I can not imagine any reason to leave such code for end user.
>
> BTW, you forgot to mention in docs 3 not trivial dependencies for OCM:
> cglib-2.1_3.jar , asm-1.5.3.jar, commons-beanutils-1.7.0.jar
> I forgot to put libs for yet next OCM project so I just made a big sticker
> with shuch message on my desctop :)
>
> As allways, should I create Jira issue with this?
> --
> SY, Alex Lukin
> RIPE NIC HDL: LEXA1-RIPE
>
Re: OCM: why not to hide ugly init code?
Hi Alex, On Tue, Mar 11, 2008 at 10:32 PM, Alex Lukin <[EMAIL PROTECTED]> wrote: > As allways, should I create Jira issue with this? Please, yes. I'm very busy with other activities and it will be a great help and ... if possible with a patch :-) That's the fast way to improve the code. Thanks, Christophe
OCM: why not to hide ugly init code?
Hi, All, Hi, Christophe!
I just took a look at new OCM docs at
http://jackrabbit.apache.org/5-with-jackrabbit-ocm.html
I must say taht ugly init code for annotation based OCM may be and must be
hidden.
In my application I created needed xml file and placed it in same package
where OCM init code is.
Then I read it directly from jar using simple code below:
InputStream xml =
this.getClass().getResourceAsStream("nodetypes-ocm.xml");
NodeTypeDef[] types = NodeTypeReader.read(xml);
Rest of init code needs Session object with superuser rights (Oh! rights on
jackrabbit! :) ) but it is not a big problem to
create one built-in OCM method with session as parameter.
In my opinion, current init code is conerproductive and creates bad attitude of
user just by the first look of new OCM user.
I can not imagine any reason to leave such code for end user.
BTW, you forgot to mention in docs 3 not trivial dependencies for OCM:
cglib-2.1_3.jar , asm-1.5.3.jar, commons-beanutils-1.7.0.jar
I forgot to put libs for yet next OCM project so I just made a big sticker with
shuch message on my desctop :)
As allways, should I create Jira issue with this?
--
SY, Alex Lukin
RIPE NIC HDL: LEXA1-RIPE
