From graffito-dev-return-1438-apmail-incubator-graffito-dev-archive=www.apache.org@incubator.apache.org Tue Oct 17 10:41:01 2006 Return-Path: Delivered-To: apmail-incubator-graffito-dev-archive@www.apache.org Received: (qmail 87240 invoked from network); 17 Oct 2006 10:41:00 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 17 Oct 2006 10:41:00 -0000 Received: (qmail 13916 invoked by uid 500); 17 Oct 2006 10:41:00 -0000 Mailing-List: contact graffito-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: graffito-dev@incubator.apache.org Delivered-To: mailing list graffito-dev@incubator.apache.org Received: (qmail 13902 invoked by uid 99); 17 Oct 2006 10:41:00 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 Oct 2006 03:41:00 -0700 X-ASF-Spam-Status: No, hits=3.1 required=10.0 tests=DNS_FROM_RFC_ABUSE,HTML_00_10,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of fmeschbe@gmail.com designates 64.233.166.177 as permitted sender) Received: from [64.233.166.177] (HELO py-out-1112.google.com) (64.233.166.177) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 Oct 2006 03:40:59 -0700 Received: by py-out-1112.google.com with SMTP id c30so3146572pyc for ; Tue, 17 Oct 2006 03:40:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=f3QFAu+jo40Y9UsW9UctDv8r1/jl7lqiXouet4G8pwZMTbjGKrXhps8xYdBoHwSkVCwiPIpLcI+oiP53G6GRzCM69sSwBz973TAMEoJ8Pv03ymZvu9wT2UdbF4E/iPIr0sVJuG8k4XZDVEBoJdHmcfpArzo1vT37AuUbp7NHuUo= Received: by 10.65.232.12 with SMTP id j12mr11957885qbr; Tue, 17 Oct 2006 03:40:38 -0700 (PDT) Received: by 10.65.253.9 with HTTP; Tue, 17 Oct 2006 03:40:38 -0700 (PDT) Message-ID: Date: Tue, 17 Oct 2006 12:40:38 +0200 From: "Felix Meschberger" Sender: fmeschbe@gmail.com To: graffito-dev@incubator.apache.org Subject: JCR-Mapping: Extend Bean/Collection/FieldDescriptor with support for node type management tools MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_45293_18855661.1161081638401" X-Google-Sender-Auth: e57f0d10264aa06e X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_45293_18855661.1161081638401 Content-Type: multipart/alternative; boundary="----=_Part_45294_19045069.1161081638401" ------=_Part_45294_19045069.1161081638401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all, I started working with Graffito JCR-Mapping some weeks ago noticing that it actually implements what I planned to implement in my own tool - and more :-) So I started to like that thing. While working on it I thought, that it would be nice to define node types based on the mapping definitions and also noticed, that this is actually also supported by the mapping descriptors. Still, the support by the descriptors has some drawbacks: Field descriptors are thought to only map to properties, while collection and bean descriptors are thought to only map to child nodes. Consequently the field descriptors support attributes for property definition while bean and collection definitions support attributes for child node definition. While this assumption is mostly true, it fails in the case of multi-valued properties, which is implemented using a collection descriptor. I myself implemented another CollectionConverter, which supports residual jcrName values. Also in this case, the collection descriptor maps properties. Hence I proopse to extend the bean and collection descriptors with attributes for property definition. Namely I propose the addition of "jcrType" and "jcrMultiple" attributes which should contain the property type and multi-value flag respectively. The respective BeanDescriptor and CollectionDescriptor classes are to be extended for these attributes. To further simplify node type management tools, I further propose, to define two interfaces - PropertyDefDescriptor and ChildNodeDefDescriptor - which may be used by node type management tools to extract the relevant information to define properties and child nodes. The FieldDescriptor will only implement the PropertyDefDescriptor while the BeanDescriptor and CollectionDescriptor classes will implement both interfaces. The node type management tool will then have to apply heuristics to decide, whether a property or a child node should be defined. Attached you will find the patchs to the FieldDescriptor, BeanDescriptor and CollectionDescriptor classes as well as the proposed interfaces. What do you think of these extensions ? They certainly make my life easier, as I implemented a very simple node type management tool. Thanks for any comments. Regards Felix ------=_Part_45294_19045069.1161081638401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all,

I started working with Graffito JCR-Mapping some weeks ago noticing that it actually implements what I planned to implement in my own tool - and more :-) So I started to like that thing. While working on it I thought, that it would be nice to define node types based on the mapping definitions and also noticed, that this is actually also supported by the mapping descriptors.

Still, the support by the descriptors has some drawbacks: Field descriptors are thought to only map to properties, while collection and bean descriptors are thought to only map to child nodes. Consequently the field descriptors support attributes for property definition while bean and collection definitions support attributes for child node definition. While this assumption is mostly true, it fails in the case of multi-valued properties, which is implemented using a collection descriptor. I myself implemented another CollectionConverter, which supports residual jcrName values. Also in this case, the collection descriptor maps properties.

Hence I proopse to extend the bean and collection descriptors with attributes for property definition. Namely I propose the addition of "jcrType" and "jcrMultiple" attributes which should contain the property type and multi-value flag respectively. The respective BeanDescriptor and CollectionDescriptor classes are to be extended for these attributes.

To further simplify node type management tools, I further propose, to define two interfaces - PropertyDefDescriptor and ChildNodeDefDescriptor - which may be used by node type management tools to extract the relevant information to define properties and child nodes. The FieldDescriptor will only implement the PropertyDefDescriptor while the BeanDescriptor and CollectionDescriptor classes will implement both interfaces. The node type management tool will then have to apply heuristics to decide, whether a property or a child node should be defined.

Attached you will find the patchs to the FieldDescriptor, BeanDescriptor and CollectionDescriptor classes as well as the proposed interfaces.

What do you think of these extensions ? They certainly make my life easier, as I implemented a very simple node type management tool.

Thanks for any comments.

Regards
Felix
------=_Part_45294_19045069.1161081638401-- ------=_Part_45293_18855661.1161081638401--