--- On Fri, 5/28/10, Harmeet Bedi <harmeet.b...@gmail.com> wrote:
> Forms/Screens are specified in XML with a key - based on
> xml file and name of element. XML Specifications is
> converted into Object model using model classes. These
> objects are then used to render.
>
> Since model classes are cached and shared, the model must
> accurately represent the XML specification at the start of
> rendering.
>
> So a way could be immutable classes
> Another way could be to return cloned copy of cached object
> at the start of rendering. If you do this it does not matter
> if anyone makes a mistake in the dozens of model classes
> wrt. cloned. (which many people may do over life of project
> because it is human to make stupid mistakes)
>
> It may also be worth asking why cache. To me answer is
> performance due to cost of XML parsing and conversion from
> XML to object model.
> Creating Flexible string expander instance variables in the
> model classes may also be a cost but it is not due to
> FlexibleStringExpander cache.
Actually, there is no reason to create FlexibleStringExpander instances - you
can call the static expandString method with very little performance loss.
> Wondering if the following proposal makes sense:
> - Generate Model Classes from XSD using something like
> JAXB. These would not have any flexible string expander
> instance variables.
> - Cache the key (resource+name) to Model for lookup of
> screens and forms
> - In cache lookup. Clone copy of Model root. Wrap the
> cloned copy with a dynamic proxy. Dynamic proxy also stores
> reference to context.
> - Getters from the dynamic proxy return values by applying
> FlexibleStringExpander.getInstance(..) on the value obtained
> from underlying cloned model.
> - Change Render classes to use these generated JAXB
> objects.
That would eliminate the unmarshalling code.
> Advantage could be
> - Most of the handwritten code for Model Classes goes
> away.
I don't know about "most." From my perspective, the unmarshalling code is a
small percentage of the screen widget code (basically just the class
constructors).
If we used the builder pattern, we could unmarshall the XML files by using a
builder class that builds the model objects. Builder classes could build model
objects from XML files, or from another source - like a database, a CMS, or
another file format.
> - Model classes and XML specification are tied together and
> specified only by XSD.
> - Rendering presents a pipeline. Model classes can be
> modified by renderer if needed as the pipeline proceeds from
> start of rendering till end.
The state data doesn't need to be stored in the model objects - it's only
stored there now because the developer who put it there didn't know any better.
It can be stored just as easily in the renderer. There is no need to clone
model objects.
> - Dynamic proxies are small. Mostly standard conversion
> (apply FlexibleStringExpander::expand) but it could be the
> spot to add any additional behavior.
>
> thoughts ?
> Harmeet
