Here is an example why views are an inadequate rendering mechanism. In my app I am using images representing products. Not all images are of the same dimensions. I want every image to fit in an 80px by 80px div. I want the images to be scaled to fit into that dimension.
You'd think you can do that in HTML. But HTML does not scale images proportionally when you specify both the width and the height. Since I must guarantee to be no larger than 80px in any dimension, I therefore must compute scaling on the server side. Anyway, so you think, easy, lets write a subclass of IMAGE- PRESENTATION that computes the scale and renders the value. All you need is a new RENDER-VIEW-FIELD-VALUE that does the scaling for you. But, you cannot compute the desired dimensions and store them in WIDTH and HEIGHT view slots and then call CALL-NEXT-METHOD to render the image. Views are SINGLETONS, and the presentations it uses are effectively so too. And so, modifying slot values in a view or presentation is a bad idea, since then any parallel use of the view (this happens with multiple users on the site) will have undesired consequences. This forces you to compute the desired dimensions in place, and copy the code from the IMAGE-PRESENTATION class and modify it to use your newly computed values instead of using the WIDTH and HEIGHT slots. And, you end up calling CALL-NEXT-METHOD only to handle the NIL value, which feels kind of hokey. This approach is unwieldy. If you inherit again, you're forced to copy and modify the code again. To battle that you go down the path of writing a complex RENDER-VIEW-FIELD-VALUE near the top of the class tree that anticipates all the various things you want to do and then for the subclasses you write methods that to turn these various things on and off. A nightmare to write and maintain. Was the intend for the views as singletons to avoid object creation churn? Is that really such a big gain? What are the reasons for the view being singleton? Is it the sheer size of the objects created? Right now is no easy path to move from the simple view to a more complex representation without rewriting a whole lot of machinery in your own app (like writing a lot of custom widgets). That's a big stumbling block to run into, and you can run into this late in the game. One solution that I thought of is to have a state-object stashed away, say in a hash table, for each obj used by the view. The state-object life would be short: created in the RENDER-OBJECT-VIEW and removed when the method returns. The state object would be used to store the state of the view during rendering and then thrown away. This might solve some of the problems I described, but it worries me that this adds more complexity... I haven't really thought this through yet, it might work, but I'm sure there are shortcomings. Any thoughts? Yarek --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "weblocks" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/weblocks?hl=en -~----------~----~----~----~------~----~------~--~---
