> If I was a member of the marketing staff, I would have pursued a > strategy that ensured that defaults for appengine didn't lock you into > an ultra orthodox view of web development like Django Templates take. > By ultra orthodox I mean handcuffing the templates so you cannot > insert Python code in them.
While I agree that claims shouldn't be made for not fully working frameworks, I'd rather the core AppEngine team implement features the rest of the community would have great difficulty implementing. I don't consider templates a difficult piece of the pie. I'm a relative python newbie and if I had a little more time and motivation, I'd create a version of Haml (template system out of Ruby world that uses pythonic indentation for clarity) that allows embedded python. As far as I can tell, there's nothing preventing any of us from creating such a framework because evals aren't sandboxed. I haven't created that template system (yet) because I find Django's templates sufficient. Yes, I run into the python embedding issue sometimes, but there are ways to work around it and Django does provide a nice number of filters and a tailorable template system. There's a difference between things the community can build on the existing framework and things Google probably has to do themselves, like https support, cross-app datastore access, and relaxing the sandbox or securing important packages like full PIL support. Stuff we can't do as a community should take priority. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
