On Wednesday, October 1, 2003, at 07:46 PM, Jacob Kjome wrote:
At 03:27 PM 10/1/2003 -0700, you wrote:
Would there be any problem turning that custom tag into a utility
class that just returns the whole nested table HTML as one fat String
and slapping that into the DOM with a setFooText(fatStringHere) call?
Or do we need to create new nodes in the DOM and create every HTML
element present in the nested table structure?
Since we already have this code working I'd like to leave it as is
if at all possible.
Well, there is a quick hack you can use that might work for you.
However, you get no guarantee of a well formed document since the
markup will pass through un-parsed. Anyway, here's the hack if you
want to try it....
Node msgPlaceHolder = page.getElementMessage();
Node report = page.createCDATASection(sb.toString());
msgPlaceHolder.getParentNode().replaceChild(report,
msgPlaceHolder);
You'll have to make sure that you remove any <html>, <head>, or <body>
tags from the string of HTML.
The alternative is to load your database-stored HTML document as a
DOM. In order to do this, you'll have to parse it with an HTML parser
such as JTidy, NeckoHTML, or Jivan (which uses NeckoHTML). You could
use XMLC's dynamic loading for this purpose, although I believe it
expects the data to be loaded from a file located in a configured
resource path. I wonder if an enhancement wouldn't be to be able to
also allow loading from an InputStream? Anyway, I guess I'd try out
the CDATA hack to see if that works first since it is so simple.
Our HTML structure isn't stored in the database. Its that custom tag's
job to create the table from an object graph of data transfer objects
which represent entity beans in the database. So, we shouldn't have to
worry about stripping any html. It starts and closes a <table> and all
of the internal structure is well formed.
I'll give the code above a try when we attempt this.
Thanks,
-M@
| 