Jake,
This enhancement is really made up of two parts. One part is the
document factory that provides a mechanism to supply document instances
based on customized master templates (i.e. for locale and browser
client) created at runtime rather than at compile time and the other
part is an enhancement to the LazyDOM functionality so that LazyDOMs can
be used as these runtime created master templates.
The document factory works like this. When a request for a document
instance comes in the factory checks it's cache for a master template
with a key that matches the document class and any applied
transformations. For example the key for a document a.b.x for French and
Internet Explorer would be 'a.b.x_fr_ie'. If the master template does
not exist then one is created by creating a lazy instance of the
static template, applying all transformations, in this case localisation
for French and customizations for the browser and stored in the cache
with the correct key. From this master template an instance is derived
and returned to the application for dynamic content manipulation. This
factory supports both XercesDOM and LazyDOM templates. XercesDOM support
is relatively straight forward as instances are derived by cloning the
entire DOM of the customized template. LazyDOM support requires an extra
couple of steps because a customized instance needs to be converted into
a DOM template before it can used to produce LazyDOM instances.
PROS:
1. Avoids the need to manage a large number of document variations
based on a set of possible transformations (i.e. localization, client
customization, etc). This is all done dynamically at runtime.
2. Allows master templates to be transformed using information that is
only available at runtime.
3. Supports XercesDOM, but more importantly supports LazyDOM where
document instances only contain new or modified nodes and the document
master template provides pre-formatted text for the unmodified parts of
the document.
CONS:
1. Extra processing overhead at runtime, but this limited to once for
each required document and transformation combination.
We've been using this stuff for over a year now so it's pretty solid.
The addition of this feature is backward compatible with previous
versions of the LazyDOM and therefore will not break existing code. I've
just submitted the patch for the LazyDOM enhancement to David Li for
review. I wasn't going to submit the factory code because it's pretty
straight forward to put that together and ours is tied to our MVC
framework which unfortunately is not Barracuda, yet.
I'm not sure if you wanted me to explain our actual localize processing.
Let me know if you have any more questions.
Regards,
Chris
Jacob Kjome wrote:
Hi Chris,
Is this feature sort of an alternative to Barracuda's compile-time
Localization? I'm curious as to what all is going on with your
runtime Locale modifications. Any chance you can provide a sample
webapp showing this basic functionality?
Jake
At 06:28 PM 11/21/2002 +0000, you wrote:
David,
That sounds like a great idea and while we are on the subject I like
to make another suggetsed enhancement. I hope I don't bore people who
have already heard this because I have mentioned it before ;) The
enhancement is being able to create LazyDOM master templates at
runtime as based on a compiled LazyDOM master template. The
functional requirment for this is that at runtime our application
needs to make a number of alterations to a DOM master template, such
as Locale tranformation and client browser modifications, after which
it is cached as a LazyDOM master and can be used like a normal
compile time LazyDOM. This allows the flexibility to create LazyDOM
master templates at any stage that is convenient for the particular
application. We have already patched our version of XMLC to support
this and we would very much like this functionality included in any
future version of XMLC.
Cheers,
Chris
David H. Young wrote:
Chris,
you bring out my number one concern... xmlc was created (during
Lutris' consulting days) as an alternative strategy to "templating"
approaches like jsp and jolt/jddi. We learned a lot from building
jolt (before jsp was available) and using it in an early consulting
gig at FedEx...
The target for xmlc was the interaction between html designers and
java developers. It's obvious that you and others are taking
advantage of xmlc's features to simplify that relationship. Another
huge win was the ability to support multiple presentation types
(wml, html, xml, svg, and even flash/xml). I'm concerned about a
bottom-up approach to re-thinking XMLC's internals might override
what xmlc is all about and what makes it a worthy alternative to jsp.
My recommendation to David, Richard and friends:
-> let's start a requirements document for xmlc 3.X and break it
into sections to deal with supportability/maintainability,
developer, device requirements and presentation designer requirements.
-> let's then make an announcement on theserverside.com for comments
on the requirements document, indicating that we're look for input
from those that deal with designer/developer interface in web
application development. I think it would serve as a nice way to
resurrect a bit of curiosity about xmlc. I know the folks at that
site and they are dying for content... it's pretty bad when they're
featuring an interview with their own people.
David
Chris Webb wrote:
Yep. It's a good feature because it allows our clients to create their
own look and feels and then test conformance against our reference
implementation. In most cases this means we do not have to be involved
in the process, which makes them happy and us even happier.
This process does need to be improved a little. At the moment the
compiler signals there is an incompatibility by stopping with the first
missing access method or return type and displays a message which is
fine for a Java developer but not to a mark up document designer. It
would be great if all incompatibilities were discovered in one pass and
presented in much more readable manner, i.e.
node 'foo' of type 'span' is missing.
node 'bar' of type 'link' should be of type 'span'
I don't know if it's possible to extract this information from the
compile process.
Chris
David Li wrote:
> Chris,
>
> So, you take advantage of the '-implement' option in the XMLC
> defining interfaces across different presentations, right? Hmm, I
> haven't used that for a long time but it's a good point on the
> strength of XMLC.
>
> I think this thread is getting interesting. All feedback and
> suggestion are valuable. Thanks and keep them coming.
>
> David
>
> On Thursday, Nov 21, 2002, at 19:04 Asia/Shanghai, Chris Webb wrote:
>
>> Mark,
>>
>> I agree with you on this. This change would be a completely
different
>> beast to the current XMLC. If we lose the convenience methods
then we
>> would lose the ability to create interfaces to abstract the dynamic
>> requirements of each document and thus compile time checking of
>> dynamic content compliancy. We use these dynamic content interfaces
>> extensively for multiple look and feels for HTML, WML and VoiceXML.
>>
>> Chris
>>
>> Mark Diekhans wrote:
>>
>>> Hi David,
>>> This sounds like a really interesting idea, however it's not
really
>>> XMLC anymore, it's a different paradigm. It doesn't compiling
>>> anything.
>>> I would suggest that this would be a separate package. I think it
>>> could
>>> share the output and lazydom packages. This would also keep from
>>> break existing XMLC users, as this will be completely incompatible.
>>>
>>> It would be interesting to compare applications developed in
this way
>>> with the current XMLC and Barracuda
>>>
>>> David Li writes:
>>>
>>>> DOM API is low level and was originally defined in IDL for cross
>>>> language portability. It's tedious to use and anyone who has tried
>>>> to populate a table using DOM API could testify this.
>>>>
>>>
>>> Yes, it didn't take long to figure out that a package like
Barracuda
>>> was essentially for doing complex things.
>>>
>>>> The new XMLC reloading has open up the possibility to get rid of
>>>> the Java classes and enable to dynamically add new documents into
>>>> XMLC system without source generation and compilation. However,
>>>> with this approach, we won't have the convenient methods for the
>>>> XMLC class and will have to deal with generic DOM.
>>>>
>>>> There are two possible solutions to provide a new programming
>>>> interface on top of the XMLC: a Document centric approaches using
>>>> XPath or a Java centric approaches using either JDOM or DOM4J.
Both
>>>> can probably be provided together and give the choice to the users
>>>> to pick their favorites.
>>>>
>>>> I have been experimenting with XPath for a while using a package
>>>> called JXPath from Jakarta project. It uses XPath to address the
>>>> elements in DOM and can be use to replace the convenient methods
>>>> generated by the currently XMLC implementation quite easily.
>>>>
>>>> for setting text,
>>>>
>>>> documentContext.setValue("id(foo)/text()", "New value");
>>>>
>>>> Just some random thought on the future of XMLC. I'd like to hear
>>>> what the community feel about the features needed to make XMLC a
>>>> better tools.
>>>>
>>> _______________________________________________
>>> XMLC mailing list
>>> XMLC@xxxxxxxxxxx
>>>http://www.enhydra.org/mailman/listinfo.cgi/xmlc
>>>
>>
>> --
>> Chris Webb
>> Voxsurf Ltd.
>> 3rd Floor
>> Elme House
>> 133 Long Acre
>> London WC2E 9DT
>>
>> Tel. +44 (0) 20 7240 3621 x 206
>> Mob. +44 (0) 77 8639 2359
>> Fax. +44 (0) 20 7379 7573
>> e-mail : chris.webb@xxxxxxxxxxx
>> Voice Demo. +44 (0) 870 744 7223http://www.voxsurf.com
<http://www.voxsurf.com/>
>>
>> Email disclaimer: This can be viewed at
>>http://www.voxsurf.com/disclaimer.html
>>
>>
>> _______________________________________________
>> XMLC mailing list
>> XMLC@xxxxxxxxxxx
>>http://www.enhydra.org/mailman/listinfo.cgi/xmlc
>
>
>
> _______________________________________________
> XMLC mailing list
> XMLC@xxxxxxxxxxx
>http://www.enhydra.org/mailman/listinfo.cgi/xmlc
--
Chris Webb
Voxsurf Ltd.
3rd Floor
Elme House
133 Long Acre
London WC2E 9DT
Tel. +44 (0) 20 7240 3621 x 206
Mob. +44 (0) 77 8639 2359
Fax. +44 (0) 20 7379 7573
e-mail : chris.webb@xxxxxxxxxxx
Voice Demo. +44 (0) 870 744 7223http://www.voxsurf.com
<http://www.voxsurf.com/>
Email disclaimer: This can be viewed
athttp://www.voxsurf.com/disclaimer.html
_______________________________________________
XMLC mailing list
XMLC@xxxxxxxxxxx
http://www.enhydra.org/mailman/listinfo.cgi/xmlc
--
Chris Webb
Senior Developer
Voxsurf Ltd.
3rd Floor
Elme House
133 Long Acre
London WC2E 9DT
Tel. +44 (0) 20 7240 3621 x 203
Cell. +44 (0) 77 8639 2359
Fax. +44 (0) 20 73797573
e-mail : chris.webb@xxxxxxxxxxx
Voice Demo. +44 (0) 870 744 7223
http://www.voxsurf.com
Email disclaimer: This can be viewed at
http://www.voxsurf.com/disclaimer.html
