I'm not sure I agree with the "it's not MVC" argument. MVC isn't about super-simple templates, it's about partitioning actions (controllers) from display (views). View logic could concevably be pretty complex, as long as it's kept seprate and still be real mvc.
But I do agree that it's nice to keep the templates usable by designers, so I'm generally in favor of turning predicates you want to check into simple functions and using those in the template. But on the other hand, I think making it harder to do things in the template rather than making it easier is a step backwards, because people do have to do this kind of thing sometimes ;) On Fri, Jan 30, 2009 at 4:13 PM, Gustavo Narea <[email protected]> wrote: > > Hi, Christoph. > > On Friday January 30, 2009 13:52:02 Christoph Zwerschke wrote: >> I think that function would be also useful as a standard template >> variable (like "auth_stack_enabled" or "identity"). Of course, you can >> always evaluate in the controller and pass the boolean, or pass the >> function, but why not provide something to make simple things simple? > > I would be -1 on making it available there because of the same issue I > mentioned in my previous email, I think defining/evaluating predicates in the > template is anti-MVC. > > I think the whole point of MVC is that a non-programmer web designer can work > on the template without dealing with programming, and that the web application > developer can work on the software that will process data without dealing with > how it will represented before the end-user. > > I think web designers must not encounter code like the one below in their > templates: > """ > <?python > from yourapplication.lib.auth.predicates import from_ip > # In case it's not available in the templates by default: > from tg import evaluate > ?> > <div py:if="${evaluate(from_ip('127.0.0.1')}"> > The application is running on your own computer! > </div> > """ > > But I won't oppose if people really want this available by default. > > >> By the way, checking a permission is not a good use case for this >> funciton since you can already easily do this in a template using >> tg.identity.user.permissions(), > > No, that's in TG1 (I guess, I've only used TG2). > >> and you can also easily add a >> has_permission() method to the user class. > > I think it's the same thing, even if the predicate simply is not_anonymous. > >> The need for such a function comes primarily if you have compound or >> custom predicate checkers (e.g. checking the ip addr). It's better if >> you can define them at one place only, and then use them for both >> restricting access to controllers and changing the behavior of >> controllers/views. > > Sure, you can define single/compound predicate once and use it in many places. > But giving the ability to easily deal with predicates in the template is what > I wouldn't like. > > Cheers! :) > -- > Gustavo Narea <http://gustavonarea.net/>. > > Get rid of unethical constraints! Get freedomware: > http://www.getgnulinux.org/ > > > > -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" 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-trunk?hl=en -~----------~----~----~----~------~----~------~--~---
