Yarek Kowalik <[email protected]> writes: > 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.
I had exactly the same problem, a number of times already. In one case I was able to work around this with a dynamic variable hack (see *presentation-dom-id* in weblocks). [...] > 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. True. In my case, I found that I often begin with views and presentations, then later throw them out in favor of widgets. I end up rewriting and reimplementing lots of stuff that way. I have an idea on how to solve this relatively cleanly while keeping most of the view machinery intact and sticking to the general idea that views have no state -- but I have to actually write some code and flesh it out. I'll post more on this soon. --J. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
