With a well behaved model system, no processing state should be stored in the model object.
The renderer uses a modified visitor pattern, (should be real pattern), then the state for the rendering instance can and should the be store in the renderer/visitor instance. ----- "Adrian Crum" <[email protected]> wrote: > That could be done too. I don't see where it would be safer. You can > push/pop a state object in the renderer. > > -Adrian > > --- On Fri, 5/28/10, Harmeet Bedi <[email protected]> wrote: > > > 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<[email protected]> > > 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 > > > > > > > > > > > > > > > >
