data first, structure on demand

[ChadDavis <ch...@gmail.com>]

I've read a lot of stuff regarding the use of unstructured and
avoiding structured node types as long as possible.  I think I have a
compelling reason to use a structured node type pretty early in my
project . . . I'd like some thoughts from others who've been down this
road.

I want to be enable a sort of run time awareness of the structure of
documents in my CMS.  I'd like to be able to add custom document
types, defined as node types, and have my system just handle them.  To
do this, it seems necessary for the code to be able to "inspect" the
structure of the document, e.g. learn what attributes is has in order
to become aware of the document's structure so that I can render edit
or create wizards the appropriate fields -- correspondent to the
attributes of the node type that backs the document being created.  I
can't really see how I can pull this off without have structured node
types.  If you see a alternative, let me know.

Additionally, I don't see much threat in defining non-mandatory
properties and children nodes.  It seems that this wouldn't pose any
data migration issues, which are the main danger behind getting into a
structured model, correct?  Thoughts?

Re: data first, structure on demand

[ChadDavis <ch...@gmail.com>]

>
> Jcr node type is kind of database schema, once defined, it's expensive
> to update/upgrade.
>

I don't care about expensive -- I'm only considering an very rare
event; not something triggered by users, or regular application level
actions.  Does this make sense?

Re: data first, structure on demand

[Guo Du <mr...@gmail.com>]

On Tue, Jan 26, 2010 at 6:34 PM, ChadDavis <ch...@gmail.com> wrote:
> I've read a lot of stuff regarding the use of unstructured and
> avoiding structured node types as long as possible.  I think I have a
unstructured give you freedom to extend to any structure. You may put
custom properties such as node_type as meta-data instead of jcr node
type. Your application could aware of the meta data and display custom
wizards etc.

Jcr node type is kind of database schema, once defined, it's expensive
to update/upgrade.

-Guo

Re: data first, structure on demand

[ChadDavis <ch...@gmail.com>]

> That's actually not what I meant by type-specific metadata.I meant things
> like whether a String property should be displayed as a single or multi-line
> entry form. If you're going to be dynamically creating a UI, you need this
> type of metadata. One (albeit not the only) approach to this problem is to
> use Sling and statically define the UI in scripts specific to particular
> node/resource types. That way you don't need the metadata (or you do, but
> it's essentially embedded in your HTML pages).

This is exactly what I'm facing.  My plan is to enforce some
conventions on the NodeTypes that back my application level document
types.  I'll have a limited set of application level propertyTypes
that will be mapped to the nodetype properties via some layer of
meta-data.

For starters, I'll probably just embed my meta-data into some naming
conventions on the node properties.  But if it get's to thick, I'll
just have to introduce something else.  Probably storing such
meta-data in the repository itself.

I need to find a few minutes to peruse Sling on the off chance that I
could integrate it into my own framework; but that path never seems to
work out for me.

Re: data first, structure on demand

[Bertrand Delacretaz <bd...@apache.org>]

Hi Justin,

On Thu, Jan 28, 2010 at 12:26 AM, Justin Edelson
<ju...@justinedelson.com> wrote:
> On Wed, Jan 27, 2010 at 4:33 PM, Bertrand Delacretaz <bdelacretaz@apache.org
>> wrote:
>> ...IIUC, that sling:resourceType property is what you mean by
>> type-specific metadata...

> That's actually not what I meant by type-specific metadata.I meant things
> like whether a String property should be displayed as a single or multi-line
> entry form. If you're going to be dynamically creating a UI, you need this
> type of metadata....

Ah ok got it , you mean the type of a specific property, I meant the
type of a node, or more specifically the type of the "micro-tree" that
you want to edit or render.

-Bertrand

Re: data first, structure on demand

[Justin Edelson <ju...@justinedelson.com>]

Hi Bertrand,

On Wed, Jan 27, 2010 at 4:33 PM, Bertrand Delacretaz <bdelacretaz@apache.org
> wrote:

> Hi
>
> On Wed, Jan 27, 2010 at 3:51 PM, Justin Edelson <ju...@gmail.com>
> wrote:
> > ...I would caution you that
> > JCR Node Types do not, IMHO, provide enough metadata to be used to create
> a
> > UI. Sling provides one solution to this whereby you can write "edit"
> and/or
> > "create" scripts per node type (or, in Sling parlance, resource type).
> > Another solution is to put additional type-specific metadata in the
> > repository....
>
> Just to clarify (I know Justin is aware of that ;-) that is what Sling
> does by default, it uses a sling:resourceType JCR property to point to
> (easily overridable) servlets or scripts, which can also be selected
> based on http method, URL extension and "selectors" (addtional
> extensions), etc.
>
> IIUC, that sling:resourceType property is what you mean by
> type-specific metadata - Sling standardizes the use of that, and
> provides default servlets, conventions and utilities to make it easier
> to handle that.
>
That's actually not what I meant by type-specific metadata.I meant things
like whether a String property should be displayed as a single or multi-line
entry form. If you're going to be dynamically creating a UI, you need this
type of metadata. One (albeit not the only) approach to this problem is to
use Sling and statically define the UI in scripts specific to particular
node/resource types. That way you don't need the metadata (or you do, but
it's essentially embedded in your HTML pages).

I don't actually think this solution scales well beyond a small set of node
types, but it is feasible. On the flip side, a dynamically-generated UI is
no picnic either.

Hope this makes a bit more sense...

Justin

> -Bertrand
>

Re: data first, structure on demand

[Bertrand Delacretaz <bd...@apache.org>]

Hi

On Wed, Jan 27, 2010 at 3:51 PM, Justin Edelson <ju...@gmail.com> wrote:
> ...I would caution you that
> JCR Node Types do not, IMHO, provide enough metadata to be used to create a
> UI. Sling provides one solution to this whereby you can write "edit" and/or
> "create" scripts per node type (or, in Sling parlance, resource type).
> Another solution is to put additional type-specific metadata in the
> repository....

Just to clarify (I know Justin is aware of that ;-) that is what Sling
does by default, it uses a sling:resourceType JCR property to point to
(easily overridable) servlets or scripts, which can also be selected
based on http method, URL extension and "selectors" (addtional
extensions), etc.

IIUC, that sling:resourceType property is what you mean by
type-specific metadata - Sling standardizes the use of that, and
provides default servlets, conventions and utilities to make it easier
to handle that.

-Bertrand

Re: data first, structure on demand

[Justin Edelson <ju...@gmail.com>]

Chad-
I agree with you that there is a class of applications which require 
node/content/document type definitions. However, I would caution you 
that JCR Node Types do not, IMHO, provide enough metadata to be used to 
create a UI. Sling provides one solution to this whereby you can write 
"edit" and/or "create" scripts per node type (or, in Sling parlance, 
resource type). Another solution is to put additional type-specific 
metadata in the repository.

Justin


On 1/26/10 1:34 PM, ChadDavis wrote:
> I've read a lot of stuff regarding the use of unstructured and
> avoiding structured node types as long as possible.  I think I have a
> compelling reason to use a structured node type pretty early in my
> project . . . I'd like some thoughts from others who've been down this
> road.
>
> I want to be enable a sort of run time awareness of the structure of
> documents in my CMS.  I'd like to be able to add custom document
> types, defined as node types, and have my system just handle them.  To
> do this, it seems necessary for the code to be able to "inspect" the
> structure of the document, e.g. learn what attributes is has in order
> to become aware of the document's structure so that I can render edit
> or create wizards the appropriate fields -- correspondent to the
> attributes of the node type that backs the document being created.  I
> can't really see how I can pull this off without have structured node
> types.  If you see a alternative, let me know.
>
> Additionally, I don't see much threat in defining non-mandatory
> properties and children nodes.  It seems that this wouldn't pose any
> data migration issues, which are the main danger behind getting into a
> structured model, correct?  Thoughts?
>    

Re: data first, structure on demand

[Felix Meschberger <fm...@gmail.com>]

Hi,

On 26.01.2010 23:40, ChadDavis wrote:
>>
>> You might want to look at http://sling.apache.org
>>
> 
> I'll take a look.  I haven't looked a sling before because I
> understand it to be a web application framework.  I'm building a CMS
> feature into an existing application that has it's own web application
> framework.  Is it easy to integrate sling into other web app
> frameworks.

Hmm, good question. We never investigated that route ...


Regards
Felix

Re: data first, structure on demand

[ChadDavis <ch...@gmail.com>]

>
> You might want to look at http://sling.apache.org
>

I'll take a look.  I haven't looked a sling before because I
understand it to be a web application framework.  I'm building a CMS
feature into an existing application that has it's own web application
framework.  Is it easy to integrate sling into other web app
frameworks.

Re: data first, structure on demand

[Felix Meschberger <fm...@gmail.com>]

Hi Chad,

Have you looked at Apache Sling ?

Sling does not impose any explicit node types, yet copes very well, if
there are.

The way Sling works is, that the URL addresses the Repository Item and
from this Item a Script or Servlet is resolved which is then called to
handle the request. The one thing Sling needs in this process is a
"resource type" (we abstract a bit from the JCR API to make the Sling
implementation a lot simpler).

You might want to look at http://sling.apache.org

Regards
Felix

On 26.01.2010 19:34, ChadDavis wrote:
> I've read a lot of stuff regarding the use of unstructured and
> avoiding structured node types as long as possible.  I think I have a
> compelling reason to use a structured node type pretty early in my
> project . . . I'd like some thoughts from others who've been down this
> road.
> 
> I want to be enable a sort of run time awareness of the structure of
> documents in my CMS.  I'd like to be able to add custom document
> types, defined as node types, and have my system just handle them.  To
> do this, it seems necessary for the code to be able to "inspect" the
> structure of the document, e.g. learn what attributes is has in order
> to become aware of the document's structure so that I can render edit
> or create wizards the appropriate fields -- correspondent to the
> attributes of the node type that backs the document being created.  I
> can't really see how I can pull this off without have structured node
> types.  If you see a alternative, let me know.
> 
> Additionally, I don't see much threat in defining non-mandatory
> properties and children nodes.  It seems that this wouldn't pose any
> data migration issues, which are the main danger behind getting into a
> structured model, correct?  Thoughts?
>