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 <harmeet.b...@gmail.com> 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<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 > > > > > > > > > >
