On 10.08.2011, at 17:24, Mark Herman wrote:
> I think your problem is that you're trying to use your structure as an
> implicit property of your content. One of the ideas behind JCR is that your
> content is most important and your structure is less important. If it is
> important to your content then it should be part of your content, not implied
> by its structure. Personally I see two major reasons for this:
>
> 1 - since it's implied, you can't be 100% sure what it means. For example
> organizing by date like folders, is it the date the content was created, or
> the date it was published, or some other date?
> 2 - if you want to change your structure, you have to go in and change every
> single query that relies on that structure. If you do your JCR setup right,
> most if not all your queries should stay the same.
>
> For example, if you create your my:issue nodetype with a publishedDate
> property, to find all your available dates would just be something like:
> (warning: quick pseudo example)
>
> SELECT issue.publishedDate FROM [my:issue] AS issue ORDER BY
> issue.publishedDate DESC
> (not sure if some form of "SELECT DISTINCT" could be accomplished)
>
> You can change your structure multiple times, but that query will still work.
> Never done it before, but I'm guessing it'll also make it easier to do
> between date queries. In the real world it's not always that simple so they
> give you a few functions to help. If you have my:issue nodes all over your
> repo but all you really want is everything in your "published" folder, you
> could use ISDESCENDANTNODE('/published'). Even better yet you would have a
> my:published node and use ISDESCENDANTNODE([my:published]). Again that way
> your structure can change drastically but your queries mean the same thing.
>
> You don't necessarily have to create a custom node type, you could just use
> unstructured and use a specific property to filter them by, but that will add
> an extra clause to all your queries. I think creating a custom node type
> will usually pay off in the long run unless your content is so dynamic that
> you constantly need to update your nodetype.
yeah i see your point and i thought about this as well. the structure is
basically articles under /issue which are just spread out by date. if an
article appears in multiple dates we will use references.
so the final approach looks like i will use properties instead of custom node
types for two reasons:
1) i need to sort by the date
2) i would like custom node types as much as possible because it feels like its
going to complicate moving the content between setups
thx for your feedback!
regards,
Lukas Kahwe Smith
[email protected]
