Hi! Well, if you don't mind to get your hands dirty, you can write a store and event listeners for your specific needs. Event listeners can receive events about many different things that go on inside slide, like document updates, creations and deletions, to mention only a few. It is also possible to write new methods and expose them to the slide servlet with your custom method factory, but that is getting really low-level and you probably don't need it. But it would solve your problem in a clean way, meaning your app talks only to slide. It might just be easier to go with what you are more comfortable with at the moment and use the DB for what you need, even though it is "not clean". After all, its about time-to-market, right? :)
max > -----Original Message----- > From: Lixin Chu [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 07, 2006 23:21 > To: Slide Users Mailing List > Subject: Re: common practice of managing metadata with Slide > > > I am keen to see if Slide could manage everything for me. > Keeping folder and > file metadata info in a DB is unnecessary. > > However, my concern arises when I think it again: > > You don't necessarily have to keep it in an external place. > Ideally yes. However, we typically need to keep a lot more > info with the > user. For example, in the application I am doing, we also need to keep > user's org, dept, role, projects, etc. Slide is ok to handle > any type of > data, but I am not sure if it is a good idea to let Slide provide DB > features, such as indexing, sorting, etc. > > > And also, customer is asking more and more doc management > features, one > example is doc tracking - users can track the doc and get > notification when > there is any changes. So now I need to maintaine the doc-tracker > many-to-many relationship. Is it also ok to let Slide keep > this information > or better keep it in a DB ? > > That's why I was thinking if I should keep metadata in a DB > and let Slide > handle these: > - file repository > - lock/unlock > - versioning and > - full text search > > the rest will be handled by DB. but it is just not a clean > solution. still > doing more investigation .... > > thanks ! > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
