> The state data doesn't need to be stored in the model objects ... can
be stored just as easily in the renderer.
I think safer practice should be to store state in context not renderer.
So push new map on context, call sub-widget rendering and pop map on
child widget render finish.
Renderer instance is single per screen render. I think of it as
something like global context. So would need to clean state after use.
Context(MapStack) may be better suited for this ?
Harmeet
On 29/05/10 4:23 AM, Adrian Crum wrote:
--- 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
