At one point I experimented with a custom ResourceProvider that provided
REST-ful access to database tables. The idea works conceptually, but
requires that you re-create a fair amount of functionality that already
works out-of-the-box with JCR Node Resources. I think that's what you
alluded to with the discussion of URL parsing & 20+ controllers.
However, I think you could use this idea, and then dispense with
actually importing the data as XML into the repository & rather just
access it directly from the source system (if it's a DB, service-bus,
file-system etc).
In particular, it appears the Sling-side of your application doesn't
require updating this data, so that would simplify the implementation.
I eventually abandoned my approach because I didn't have time to
re-implement all the SlingPostServlet functionality for creation/update
(which is JCR node specific) for my custom Resource Types.
tao wen wrote:
Hi,
There are two issues stopped us from importing them as JCR nodes:
1. the data not owned by us
It is owned by a backend system. So, it will need to be updated once a day
at least.
2. the data has rules
For example, products have dependencies. When we show the product catalogue,
we allow user to play with different packaging possibilities. We need to
apply the domain logic to validate the package user built. So, if we store
things in JCR nodes, we need to use OCM to map it back to memory and invoke
domain logic. Also, the relationships of domain entities are very rich, also
add complexitity to the mappings.
2009/3/16 Michael Marth <[email protected]>
