Rachael, sounds interesting. I'm guessing you're using an XSLT stylesheet to convert the XML you receive either to HTML or FO--which then goes into FOP and comes out PDF. Is that right? If so, I'm still not sure why you couldn't put some extra logic in that stylesheet. I'd also be very intersted in anything you can say about how you're implementing the edit feature.
Here's what we're doing: Our application is a mostly read-only internet reporting application that provides ongoing lab results and some canned management reports to our clinical trials customers. We plan to add more features in the future. (I don't think I'm giving away anything here.) We get the data for a given report from Oracle (incremental data is received from a MUMPS system and fed to Oracle 8 times a day) by executing stored procedures which can return any number of result sets representing levels in the data (study, doctor, patient, visit, test, etc...). We convert these result-sets straight into XML using the built in Oracle tool. Then we have a Java piece which combines the flat-strucuted XML result-sets into one XML document(report) which reflects the structure of the data. The nice part about this piece is that it gets specific instructions about how to assmeble each report from a fairly straightforward XML template. Finally we use a collection of report-specific XSLT stylesheets to convert the report XML into FO->PDF, HTML, or delimited text. The end user can also request data in straight XML, though we doubt any of our customers will be ready for that for a while. The nice part about the tailored structure of the XML is that the stylesheets come out very simple, mostly just dropping from one template to the next. We've tried to relegate report-specific logic to a few places, keeping data-manipulation in the data layer (the stored procs), presentation in the stylesheets, and have the Java piece be essentially a dumb conduit. But as always we've had to cheat a little here and there. I've discovered that you can do almost anything in a stylesheet, it's just a matter of how much you want to complicate things. For instance, in one of the reports we're doing a full transpose of row data into columns, with a break at every fifth column. IE - the first set of columns could take up 3 pages, with columns 6-10 starting at page 4. We decided to put this piece in the stylesheet because the number of columns printed varies, which makes defining a result-set that emulates the report difficult (the max number of columns is technically 9,999 - don't ask). But in practice the max number of columns and rows is low (20/100), so we don't have to worry about XSLT memory or performance issues arising from the transpose. On that note, we've also discovered that when the report XML is already in a fairly pristine data structure, the stylesheet seems to have no issues rendering some of our other reports which can get huge. On large reports, the FOP transformation, stored proc call, and Oracle XML conversion all take longer than the XSLT piece by a factor of 10. So anyway, if you really can't do anything special before your data gets to FOP I guess you can either wait for these guys to implement linefeed-treatment="preserve" or try to write your own extension. Like I said I've got an extension I need to create. But I've got a million little loose ends to tie up before I start on it. Just out of curiosity has anyone ever offered the active FOP developers money to work faster or on a specific piece? I can't imagine trying to convince my company to shell out $50k for something like this, even if it would save them a million in the long run. It just wouldn't compute. But $50k for third-party penetration testing, where they come back with pearls like "Use POST instead of GET"??? - No problem. Sorry guys. Matt Rachael Blank wrote: > > Matt, > > Thanks again for your help. I haven't gotten it to work yet, but I am still > plugging away at it. > > As a developer in the healthcare industry, I can understand your curiousity. > > My company handles the archival of millions of records at UPMC. Essentially, we > parse disparate data and archive it so that users can access data from different > systems in one place. Great idea...huh? > > We have a subsidiary company which offers a transcription service, Scribes > Online. It is an Internet-based transcription service for which I developed the > interim solution for the online retrieval of their physician's dictations. There > is currently now a small team of us who are wrapping up development of the > replacement to my interim solution. The only road block seems to be the > linefeed-preserve issue. > > I can't get into details without breeching non-disclosure agreements and such, but > here it is... > A Physican dictates a report via phone > The Medical Trancriptionist transcribes the document into an application which > feeds into Oracle. > We pull the document from Oracle using JSP and servlets. The XML is generated on > the fly with JSP. > (Up until this point I am not involved in development) > I am on the Web GUI side where I create stylesheets that enable the physician to > edit, view a "read only" copy and/or print a final PDF copy of the document. > We also offer a batch printing, sorting and searching capabilities. > > After a certain period of time specified by the client, we archive the data and > can do very detailed and advanced analysis for the client. > > We would sincerely appreciate any more help with this issue. It would be a > terrible shame for us and FOP for the project to go BUST. > > Thanks again! > > Rachael > > Matt Savino wrote: > > > I work for a giant healthcare company, and it's still hard for me to > > imagine how the data comes from --somewhere-- then is inserted into an > > fo: document with no chance for any text manipulation. Not saying I > > don't believe it, Id just love to hear the situation. > > > > So what about some kind of quick n' dirty little extension to do the > > work until linespace-treatment="preserve" is implemented. (Is it in the > > plans to attempt to implement everything in the FO spec?) I haven't > > started on my table-header with (Cont) extension yet, but when I do I'll > > let the group know how it goes. > > > > Arved Sandstrom wrote: > > > > > > At 09:52 AM 11/2/01 -0800, you wrote: > > > >Our application also needs linefeeds preserved in certain cases. We > > > >convert them at the stylesheet level. Here's how we do it: > > > [ SNIP ] > > > >Like I said, I have no idea if you're even using stylesheets. I have a > > > >feeling if you're talking with Arved, this avenue has already been > > > >explored. But I figured I'd throw it out there just in case. By the way > > > >if anyone knows of a slicker method to do what I'm doing above (ie some > > > >sort of Perl-style replace, or Java-style string tokenizer > > > >functionality), please chime in. > > > > > > This possibility, or something essentially similar, came up. That is, I > > > suggested a workaround. Rachael explained the production scenario, and it > > > appears to make sense to me that extra processing of the content before it > > > gets to the formatter is not acceptable. So unless something has changed we > > > are definitely talking about source code changes. > > > > > > I did Rachael a disservice by underestimating the scope of the fix (I looked > > > at the FOP code and started working on this, and it wasn't so > > > straightforward) and overestimating the amount of time I had available to do > > > something about it. Work at my last company was pretty crazy for a lot of > > > this year, and I should have taken that into account, and I apologize for > > > being naively optimistic. In any case that last company has now folded and > > > at the moment I am _not_ in a position to assist. :-) > > > > > > Regards, > > > Arved Sandstrom > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, email: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, email: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
