Thanks for the response. Unfortunate info, but expected.
What other options might i have? The basic requirements are:
-- inherently not end-user request-based (the point of generating the HTML chunks in the backend is to avoid end users taking the generation hit, which can be large at times)
-- mix of object-access code and HTML tags (similar to JSP, we'll have HTML tags interspersed with getters on the object(s) passed in)
-- as easily as possible to generate and maintain (would like to avoid writing individual classes with stringBuffer.append(...) to write characters to the resultString, as creation/updates will be done by front-end folk)
Some ideas I've entertained, to give you an idea of what I'm thinking:
-- write an HTML-parser using regexp and use reflection to run the object getters. (would be hard AND certainly re-inventing the wheel)
-- send an HTTP request through the loopback device, sending objects as request parameters (undesireable since it'll have to be throttled and/or would be unnecessarily clogging the request pool)
-- set up a mini-servlet engine on the side to handle these requests apart from
tomcat (harder to maintain, memory hog, another possible bottleneck...)
any ideas or advice? the main problem is that some of these HTML chunks take non-neglible time to generate (which is why we're re-genning them without user-prompts), and they can be regenerated when loads are low, so as to tread as lightly as possible.
i appreciate any ideas or information or leads. thanks very much.