jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Edelson <jus...@justinedelson.com>
Subject Re: data first, structure on demand
Date Wed, 27 Jan 2010 23:26:40 GMT
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 <justinedelson@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message