cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From brian moseley ...@maz.org>
Subject RE: [Moving on] SAX vs. DOM part II
Date Mon, 24 Jan 2000 12:17:38 GMT
On Mon, 24 Jan 2000, Ricardo Rocha wrote:

> A related and very interesting direction Scott Boag has
> pointed out is that of stylesheet compilation: if we
> translate stylsheets into bytecodes the "prohibitive"
> cost I mention above would become less of a problem (I'd
> stick to stylesheet inclusion/importing, though!)

one of the most compelling uses of cocoon is in specifying
user interfaces that must scale to large numbers of
cobrands, locales, and output formats. consider an isp with
500 cobrands supporting html and wml output in 16 languages.
the number of combinations of these dimensions is
staggering.

in this scenario the sheer number of people involved in
producing an application is staggering. the various groups
involve:

 * production staff concentrating on the stylistic aspect of
cobranding - making images, creating html and wml
headers/footers/menus/what have you, interfacing with each
customers' designers

 * a localization team providing linquistic qa, interfacing
with translation outsourcing partner, collaborating with ui
designers on issues such as word order flexibility, etc

 * ui engineers creating the xsl templates that will be used
to generate the html and wml for each cobrand

 * application engineers coding the logicsheets that provide
custom behavior for each cobrand that overrides and extends
the application's custom behavior

each of these groups generates a distinct set of artifacts
from which combinations must be selected at runtime
according to the dimensions of a particular request. i
expect that the source form of each of these artifacts will
be xsl stylesheets and xsp logicsheets, and that the
mechanism used to combine stylesheets will be
including/importing "stylesheet fragments" into a final
transient stylesheet which will then be cached. i may be
mistaken but xsp already compiles logicsheets into classes,
right?

in my experience, its best to not perform this construction
at request time because of the often large number of
elements in each artifact that must be assembled into the
whole. i find that an offline compilation process, combined
with an application that can sense and reload cached
stylesheets and compiled classes which have been modified,
allows the best performance, and the least opportunity for
different instances of an application to become out of sync.
it also allows construction to happen at a central point on
the network, as a scheduled job or triggered manually, after
which the compiled assets can be distributed to production
hosts. this type of control over the update of cobranding
assets is essential for high paying and very picky
customers.


Mime
View raw message