|
From: bruce <br...@mc...> - 2003-03-28 14:19:33
|
Erik, Comments inline... On Friday 28 March 2003 08:54 am, ek...@ba... wrote: > Sounds interesting and flexible but perhaps a little complicated. I > regret that I cannot immediately provide a more "elegant" solution, but > I can tell you what was discussed at my database design meeting > yesterday with our data architect ... please bear one thing in mind > before reading on ... I'm tasked with delivering a very challenging > system in a very short timeframe ... that being said, we have initially > decided to add a Sybase "text" field (unlimited character length field) > to the CONFIG table, named "cfg_script" that is nullable. For rows in > this table in which you would normally reference a file descriptor or > URL in the cfg_value field, we will embed that script into "cfg_script" > and read it in using SQLConfig.getConfig(). I will then have to figure > out a way to feed this script (contained in a String) to the appropriate > process (Xalan, etc) ... but I haven't even thought that far yet. But this is where the real problem is, right here. I think I might have an idea that will make things even simpler. We add another configuration parameter to the XslTransform that provides the XSL document inline. This will be in addition to the file configuration parameter. So the logic is: 1. If the file/url parameter is not null, load from the url 2. if the inline parameter is not null, use the XSL in the parameter What do you think? regards, Bruce. > Yes, your solution is MUCH more elegant than what I have detailed above, > but I've got management coming down on me like a ton of bricks to get > this project designed and developed. I would much rather implement a > solution that keeps me in-line with Babeldoc's progress. > > Thanks again for all your assistance and interest. > > Erik > > << > Erik, Dejan: > > I think I have found a relatively simple solution: > > 1. We implement a new URLStreamHandler so that we can have a new > protocol > (lets say, babelsql:) that can access the database just like a > filesystem. > 2. We implement the virtual filesystem using three tables - a directory > table > that knows about about its parent directory and maintains an id. A data > table that knows about its directory table id and its own id and an > "inode" > table that tracks common stuff for the two tables: permissions, last > write, > access time, modification etc. > 3. Then we simply manage the data in the tables just like a regular > filesystem and we access them in the same way. > > thoughts? > > regards, > Bruce. > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: > The Definitive IT and Networking Event. Be There! > NetWorld+Interop Las Vegas 2003 -- Register today! > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > _______________________________________________ > Babeldoc-devel mailing list > Bab...@li... > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel |