Dear list, I'm not hitting any direct problem at this time, but want to vent some of my ideas on how to implement a certain extension on this list. Such that you can shoot at me if I'm doing something totally evil ;-)
The final functionality I'm building goes a bit far, but for the sake of discussion I can summarize by mentioning the two main ingredients needed. One functionality needed is that in certain cases, typically marked by a save() or refresh() (tbd), child nodes and properties are automatically re-created using some algorithm. The values of the properties and which children to generate might be dependent on the state of whole different parts of the JCR tree. The other base functionality that these generated item states are actually never persisted. Their information is volatile because it can be re-created. For example and the sake of argument, one property might get an integer value with the count of all nodes in the repository at the moment of save() or refresh(). This state differs per session, and should therefor (and for other reasons) not be persisted. Basically we have a virtual layer, not suppost to be edited, but which is different from VirtualItemStateManagers because they are distinct per session. Okay, that is the base I'm trying to achieve. Now this functionality I've already implemented as a prototype using decorating the entire JCR layer. However this pattern has too many problems. One is that it is too much work to support all JCR calls and the other is that this does not integrate well with caching and a session would over time accumulate to much memory. Basically it is implemented in the wrong layer. I dove right down into JackRabbit, and came to the preliminary conclusion that the way in this could fairly neatly (we're not going beauty contest) be handled is largely in the ChangeLog kept by the LocalItemStateManager. This would mean subclassing the LocalItemStateManager, but most code is actually in a extended ChangeLog. The proper handles are available and I was able to prototype the functions needed. So I'm not really asking how I should start implementing this. However I do want to throw this into the JR community to see the reactions and whether I'm not overlooking things, or whether I'm going 666 on the design of JR... Regards, \Berry PS, references from real nodes to virtual nodes are not supported, by design, so I did take that into account. -- Berry A.W. van Halderen [EMAIL PROTECTED] / [EMAIL PROTECTED] Disclaimer: the above is the author's personal opinion and is not the opinion or policy of his employer or of the little green men that have been following him all day.
