Jan, I found it in your Weblocks fork.
Bardzo Dziekuje! Yarek On Jan 20, 10:47 am, Yarek Kowalik <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
