Hi, [I believe that large parts of your question are of interest for the Sling group, so I'll answer here. For the parts that are related to Communique only you might want to head over to http://groups.google.com/group/day-communique]
As far as I understand it you try do to the import in a way that is possible, but not very JCR-like: "As the data is not stored in JCR repository as nodes, but a plain file" I would recommend to actually store each of your products in a JCR node at a path like /mobile/handset/NokiaN75 or /content/mobile/handset/NokiaN75 Like that the script resolution is handled by Sling and you will not need the "20+ controllers". The import itself could be done with a little standalone JCR app. IIRC Sling can also process POSTed XML files (and produce nodes) so if you can control the incoming XML format that might be even simpler (but I would personally go the first route) hth Michael On Sun, Mar 15, 2009 at 7:21 AM, tao wen <[email protected]> wrote: > Integrate Sling with data from another system > > > > We are working a public website using CQ 5. Some of the data like product > catalogue comes from another system. The requirement asks us to get the > data > and embed them as part of the page hosted by CQ. This is a challenging job > to us, as we can not find any example out there doing this. The challenges > we have identified are: > > > > 1. How to get/load the data > > 2. How the data being updated and notified > > 3. How the data being rendered > > 4. How to embed them as part of the page > > > > Before we sending out this mail to ask for help, we did some consulting > with > sales of CQ, and did some homework like reading source code of sling. Here > are our planned apporaches. We need some advices here about are those > apporaches following the best practices of sling or simply anti-patterns. > > > > 1. How to get/load the data > > Some background: we will deploy three CQ instances. One author instance and > two publish instances. The data will be prepared in author instance using > JDBC, and doing some transformation in memory. The result will be persisted > into a xml file and saved in JCR repository. We rely on replication > functionality to publish the xml file to the publish instance. Then in the > publish instance we just need to read things in xml back into memory. > > > > 2. How the data being updated and notified > > We will set up a scheduler in author instance to poll the data every day. > The update will be notified as event. If the replication process can > generate event itself, then we will rely on it. Otherwise, we need to set > up > new topic and publish event to it when the serialized xml file being > updated. We assume CQ will distribute the event to publish instance so that > the publish instance can know they need to refresh the data in memory using > the updated xml file. > > > > 3. How the data being rendered > > As the data is not stored in JCR repository as nodes, but a plain file, so > things like /mobile/handset/NokiaN75 can not be understand by CQ. To make > those nodes available, we write our own resource provider, and map it to > /mobile/handset. We will do URL parsing ourself to get the parameters. The > final resource provided to script engine will contain the necessary data. > In > the page, we can reference the handset by reference the current node (a.k.a > the resource provided). The resource provider is similar to tranditional > controller in MVC architecture. So there might be 20+ controllers in a > system, would that be a issue? > > > > 4. How to embed them as part of the page > > We leverage the CQ component here. The component will be configured with a > URL, where it can fetch its html. So, the comonent can not render itself, > instead, it relies on another URL to do it (which is backened by a > controller). To do this, we either need to implement some sort of server > side include, or using client side ajax call. The concern of server side > include is how to do that, and how to pass user session. The concern of > using client side ajax call is the user experience might be impacted as the > network could be slow. We were told from the sales of CQ that to be > effective about page caching, we’d better to use ajax call to retrieve the > dynamic content. > > > > Any comments? > -- Michael Marth | http://dev.day.com/
