For some unknown reason said solution doesn't work anymore. I can't tell what I've done to break it, since I basically haven't done anything (yeah right...). Anyway, if using variable_provider is a better way to do it then I'll be glad to walk that path. The problem is, I don't even know where to start with that one...
I found a another newsgroup entry by you (http://www.mail-archive.com/ [email protected]/msg40849.html) which describes what you mean with "variable_provider". I followed those directions exactly. Still, the template will complain about "categories" not being known to it (which is the variable I want to be filled by the underlying SQL query). Would you please take the time and explain to me in detail how you would solve this problem using this "variable_provider" approach ? If I simply put "from app_cfg import base_config" and do "base_config.variable_provider()" this would be simply the code block solution I tried before with lots of indirection, would it not ? So this can't be what you pointed at. I know almost nothing about TG's interior so please include all necessary information. Thanks, Amnu On Oct 20, 5:16 pm, "Diez B. Roggisch" <[email protected]> wrote: > On Wednesday, October 20, 2010 16:28:09 Patricio Valarezo Lozano wrote: > > > > > Diez B. Roggisch wrote: > > > On Oct 19, 2010, at 7:40 PM, Patricio Valarezo Lozano wrote: > > >> Amnu wrote: > > >>> I tried your second suggestion, putting a code block into the > > >>> corresponding template and it worked just perfectly. I figured this > > >>> would be the easiest hence fastest way of solving the issue and it > > >>> turned out to be just two lines of (very simple, straight forward) > > >>> code. Now that's what I like to see ! > > >>> Thank you ! :-) > > >>> Amnu > > > >> mmmm... but, you need to import your models? I think than this problem > > >> could be solved using decorators.. > > > > ? How so? Decorators aren't some magic cure-everything... > > > > Diez > > > I mean, insted of returning the menu data in the dict() on every > > controller function, he could build a decorator to do this. The > > suggestion of putting a code block into the master or main template may > > derivate in the need of importing a model from the view (for building > > the menu or something), I don't know if there is a better solution for > > this. > > So, instead of returning a specific key in every action, you suggest to wrap > every action in a specific decorator? If anything, that's slightly more > declarative, but by no means less error-prone or repetitive. > > The better solutions were suggested. > > And since when is importing models in templates a bad thing? Executing > controller code logic in there certainly is, and I would have preferred the > variable_providers approach. Which is by the way set up in app_cfg.py like > this: > > base_config.variable_provider = variable_provider > > But declaring that it's bad to have a essentially static SQL query inside > master.html is IMHO nothing but "foolish consistency" with some pattern-books' > contents. > > Diez -- You received this message because you are subscribed to the Google Groups "TurboGears" 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/turbogears?hl=en.
