Dear Wiki user, You have subscribed to a wiki page or wiki category on "Jakarta-slide Wiki" for change notification.
The following page has been changed by DEFord: http://wiki.apache.org/jakarta-slide/IntroFullCustomStore ------------------------------------------------------------------------------ Anyway, looking at your store this way you have to specify six interfaces - and an optional one - for a complete store definition. Additionally, you will need to implement an ''XAResource'' to let your store participate in a distributed transaction. This interface is specified by the [http://java.sun.com/products/jta/ JTA] and is needed by Slide's internal transaction manager which also is more or less compliant to the JTA. Slide also requires the implementation of ''org.apache.slide.common.Service''. I'd recommend to start from ''AbstractServiceBase'' as it sensibly implements many of the methods in ''Service'' interface. - Where to go from there highly depends on what you want to do. In any case you will have to implement '''all''' interfaces or supply implementation for all of them for a complete store definition. This means when you want to interface Slide to you proprietary store/CMS/whatever and you want all data to be stored there you will have to adapt all Slide stores to yours. You may think ''I do not need security and I am not interested in Locking etc., but only in content, so I simply implement the ContentStore interface''. This will not work, as you might not be interested in those feeatures, but Slide needs them in any case. What you ''can'' do is to implement the interface for content only and store the additional data to the file system or a relational databse. Note that in this case you will have half your data in your proprietary store and half of your data somewhere else. This is pretty ugly when you think of backups, recovery and the restoring of past states. Maybe this can make sense when your system uses a relational database and you combine it with the relational database store delivered with Slide, but I have never tried this. + Where to go from there highly depends on what you want to do. In any case you will have to implement '''all''' interfaces or supply implementation for all of them for a complete store definition. This means when you want to interface Slide to you proprietary store/CMS/whatever and you want all data to be stored there you will have to adapt all Slide stores to yours. - Another possibility is to store the content natively to your system, but use the XML serialization feature also used by Slide's default store ''TxXMLFileDescriptorsStore''. This way you will have two objects stored in your system, one for content and one for all descriptors set in ''NodeStore'', ''LockStore'', ''RevisionDescriptorsStore'', ''RevisionDescriptorStore'' and ''SecurityStore''. Recent versions allow to reuse this feature. Have a look at ''XMLResourceDescriptor'' that inherits from ''AbstractXMLResourceDescriptor'' to store the XML into the transactional filesystem. Inherit from ''AbstractXMLResourceDescriptor'' yourself to store the data into your own system. + You may think ''I do not need security and I am not interested in Locking etc., but only in content, so I simply implement the ContentStore interface''. This will not work, as you might not be interested in those features, but Slide needs them in any case. What you ''can'' do is implement the interface for ''content'' only and store the additional data to the file system or a relational databse. Note that in this case you will have half your data in your proprietary store and half of your data somewhere else. This is pretty ugly when you think of backups, recovery and the restoring of past states. Maybe this can make sense when your system uses a relational database and you combine it with the relational database store delivered with Slide, but I have never tried this. + Another possibility is to store the content natively to your system, but use the XML serialization feature also used by Slide's default store ''TxXMLFileDescriptorsStore''. This way you will have two objects stored in your system, one for content and one for all descriptors set in ''NodeStore'', ''LockStore'', ''RevisionDescriptorsStore'', ''RevisionDescriptorStore'' and ''SecurityStore''. Recent versions allow you to reuse this feature. Have a look at ''XMLResourceDescriptor'' that inherits from ''AbstractXMLResourceDescriptor'' to store the XML into the transactional filesystem. Inherit from ''AbstractXMLResourceDescriptor'' yourself to store the data into your own system. + - == The Store Intefaces == + == The Store Interfaces == '''[http://jakarta.apache.org/slide/javadoc/org/apache/slide/store/RevisionDescriptorStore.html RevisionDescriptorStore]''' The store described by this interface is responsible for storing and retrieving meta data for objects stored in Slide. While the actual methods are trivial the [http://jakarta.apache.org/slide/javadoc/org/apache/slide/content/NodeRevisionDescriptor.html NodeRevisionDescriptor] which is involved in almost all methods is the important one. It contains all properties and information on version numbers and labels. This ''NodeRevisionDescriptor'' is used by the ''ContentStore'' as well to specify the revision number and - where applicable - the content length. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
