Julian and Alex, thank you, those are good ideas. But the problem is that this kind of solution wouldn't scale in our case, as it would require at least N x A nodes, where A is the number of articles, and N is the number of apps that we could build. Say that we have 100,000 articles (and that's to start with) and each consists of maybe an average of 3 to 5 nodes. If we decide to use an approach where we clone the tree (minus the contents) to hold the new sling:resourceType values, we would have at least 100,000 extra nodes for each app. Any update to the position of a story, or a adding or deleting would also need to update the shadows. Again, I fully understand that this is possibly a better approach with fewer contents and maybe if there variations on them, but in my use case (same exact contents, just different rendering) the approach of extending the script search path seems to be more reasonable.
Cheers, Alessandro On Mon, Nov 4, 2013 at 4:44 PM, Alexander Klimetschek <[email protected]>wrote: > On 02.11.2013, at 08:38, Alessandro Bologna <[email protected]> > wrote: > > I am confused on how that could be implemented? How do you point a > resource > > tree to another, and make the contents of the tree the same minus the > > resource type? I mean, that would be cool... I don't think the solution > is > > shared nodes though... > > No, I meant a tree that would just include references (string path > properties) to the original tree instead of copying everything. You still > have to manage that tree yourself. It depends on how much custom management > you have to do anyway in your business case (because of differences in the > trees like ACLs, availability etc.) whether it makes sense to manage an > active copy or a an automatic duplication via another resource provider (or > other automatic solutions). > > Cheers, > Alex >
