From: Mike O. <ir...@ms...> - 2001-04-08 22:04:42
|
On Sun, Apr 08, 2001 at 10:51:24AM -0400, Chuck Esterbrook wrote: > At 12:45 PM 4/7/2001 -0700, Mike Orr wrote: > >Why does the template class need display logic? Looping can be done with > >blocks. To display big numbers in bold, do: > > > >### In the template. > > <TD> {value_format_begin} ${value} {value_format_end} </TD> > > > >### In the calling program. > > if real_value > 100.00: > > value_format_begin = "<STRONG>" > > value_format_end = "</STRONG>" > > else: > > value_format_begin = "" > > value_format_end = "" > > value = "%.2f" % real_value # Display two decimal places. > > I don't see any looping here... This in itself doesn't loop. But I'm assuming the entire <TD>...</TD> is inside a block. > > > Also, do we want to add a "set" for convenience? > > > > > > [set salary value=[department.manager.salary]] > > > ... > > > [value salary] > > > >This makes "salary" a temporary plugin value? > > Providing "set" isn't taking away the responsibility you mention. It is > providing convenience for the designer who might get tired of saying > "department.manager.salary" 4 times if he uses it 4 times. Oh, I see. An alias for a longer value. Yes, that would be convenient. It would also cache the value for free. > Again, it comes back to the fact that I work with designers in my > consulting. I don't want them to have to tap me on the shoulder every time > they want an index for a set of data they are looping through. That's a > pain in the arse for everyone. OK, you're talking about programming in a different situation than I have. In my case, the developers handle both the program and the templates, and if we hire a professional design firm, they only produce a sample page once and we maintain it thereafter. So I prefer the templates to be as dumb as possible, but I can see how you want to give your designers more autonomy. I don't agree that it's necessarily worth the effort to put looping constructs and if-blocks in the template (plus the inevitable debugging and enhancements that will come), but it's not worth arguing about. Put display logic in TemplateFiller if you and Tavis want it, and I'll make a simpler version of Plow that doesn't have it (which I need for my pages anyway, before TemplateFiller is completed). Then there will be a robust class and a no-frills alternative. I do like the proposed restructuring for Page.writeHTML(), BTW. I'm not sure how templates should be integrated with Page. There should be a way that the servlet maintainer can access the template class with a minimum of imports and constructors. On the other hand, it should also be easy to use an alternative template class or no templates at all. The name PlateKit is good. The problem with the word "template" is that it's too generic. -- -Mike (Iron) Orr, ir...@ms... (if mail problems: ms...@ji...) http://mso.oz.net/ English * Esperanto * Russkiy * Deutsch * Espan~ol |