Em Sábado 22 Abril 2006 22:00, jvanasco escreveu: > > But if you want to split your project into a heirarchy of multiple > controllers and templates , so it resembles the division of labor that > most webapp people are used to - your options are the big template or > one of the other approaches i listed in the wiki.
There's nothing exclusive to web apps. Take a look at python modules and you'll see that it is exactly the same thing. Those options are all the same thing using different names. > All I'm trying to do is find ways to make TG work with the approaches > that non-python people have, so its easier to use for me, and so that > more people will adopt it so it doesn't disappear off the face of the > earth. This seems to be the problem. TG *is* a Python application, so it works *the Python way* (whatever that means). Fighting against this is like trying to use JSF without Java or Ruby on Rails without Ruby. It won't work and you'll get disappointed. You have to learn some Python to use it. Also, I don't believe that it will disappear from the face of the Earth just because it is pythonic. In a few months this list has grown almost 5 times in size. It doesn't look like something that is bad to use, hard to use or going to disappear to me. > The approach that TG has is wholly different from just about every > other Framework and webapp design out there. Elsewhere in Python , Really? It looks to me like an MVC implementation and except for incentivating that your code be outside of your template it looks a lot like PHP or Perl or ... to me. > Django has everything compartmentalized in hierarchical directories. > Rails operates simlar. In perl Template Toolkit , Mason, and Embperl > are all hierarchical. PHP is usually same thing. But then in TG In Template Toolkit (http://www.tt2.org/) I haven't seen anything enforcing hierarchy. And I use it for my company's website for the last 4 years. You provide your templates and it glues them together or creates them on the fly -- we did an interface for generating graphs using GD and reading information from a Bugzilla database while I worked for Conectiva (http://snapshot.conectiva.com.br/cgi-bin/snap.cgi?page=mainpage.html). The same goes for Mason. You can separate your "components" -- that's how they call it -- into different directories, but there's nothing preventing you from putting everything in the same directory. You're as free as with TG to decide how to do that. You can build structures like the one you found at the archives but nothing makes them mandatory. These frameworks work like TG: they give you freedom to decide how to layout your application and it is your design that will dictate how things should be. > there's this very pythonic way of tossing everything into as few > directories as possible. From the seasoned python programmer's point This is not "pythonic". Python incentivates that you start small and grow your application easily. You don't have to make a mega project to achieve it, you are free to grow and scale. For example you start with a controllers.py file and a few controllers. Then you convert this file to a module -- you don't need to touch anything else, just split the file into multiple files and write the correct __init__.py -- so there it is... If one of these controllers need to grow more, then repeat the process. The same goes for templates -- if youhave taken a look at it and use Kid templates you might have noticed that you in fact end up using the ".pyc" files instead of the ".kid" ones... -- and other stuff. You are not tied to the proposed layout. It is easy to change if you need to. It just doesn't make sense to have a huge hierarchy for a simple project. It is far more difficult to reduce things than to grow them. It isn't because Python -- or Perl or PHP or ... -- makes it possible to have several things into one class and several files into one directory that you should always have it or that those languages incentivate it. > of view, thats a convenice, and you get a bunch of benefits. From any > other perspective, its the number one reason not to use the framework. If you say so, I'm not going to disagree just because that's my opinion. You seem to have done more research on this area then I did. I just don't see that much difference from other frameworks. -- Jorge Godoy <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
