I'd be very much interested in your solution. BTW, I can't find *presentation-dom-id* in the weblocks-dev. Where can I find it?
Yarek On Jan 20, 1:31 am, Jan Rychter <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
