On Mon, Oct 13, 2008 at 9:14 AM, Tomasz Nazar <[EMAIL PROTECTED]> wrote: > > Hi there! > > I've been a Pylons user for more than a year already. Few other people > in the neighbourhood ask me for Pylons advantages often, so I also > talk about Pylons disadvantages also. > Here I'd like to point out some of them and ask you for your > opinion/answer.. (basically I'm a happy Pylons user :) ) > > It may also be hard to define things below as related to Pylons only, > as Pylons is often just a glue to other frameworks (aka SQLA..). > Nevertheless full Pylons books contains several chapters treat about > these, so let me also point them out. > > Here goes: > > 1) all model classes are defined in 1 file together with database mapping > > That is 2nd most frustrating on my daily work. Even in Pylons tutorial > you've advised to mix all the code together in models/__init__.py. > Business logic in my small app contains more than 3K of code and is in > a single file! > I already moved out DB SQLA mappings into separate file, but that's > just a tip of the iceberg. > > So I ask: why is that? Each model class should be in a separate file > (aka Rails, java frameworks, etc)
It was not the developers' intention to force everything into one module. The default configuration was chosen to address a wide variety of needs both large and small, and to be a starting point for making your own customizations. The 'meta' module was created to make it easier to keep your classes in separate files, so that they could all import 'meta' and avoid importing 'model' circularly. SQLAlchemy models are intrinsically difficult to organize because there are three different "parts" (tables, classes, mappings) -- and Session configuration is a fourth part. Which module structure is best? People have different ideas and we couldn't come to a decision, so we just made the simplest configuration that would work. The next version of the SQLAlchemy configuration will default to SQLAlchemy 0.5's Declarative structure. This will bring the three parts together again, and perhaps make it easier to organize your classes per module without having to import as much. > Is reason other than problems with pure Python imports (which don't > work well for recursive dependencies)? Circular imports work but you have to put the lines in a certain order. If module A imports module B, and module B imports module A *and* in its top level code accesses something in module A, that something has to be created in module A *above* the "import B" statement. Otherwise, at the moment module B needs it, it doesn't exist yet. If you do all your attribute access inside functions, this doesn't matter because both modules are fully initialized by the time the function is called (as long as it isn't called at the top level of the module). Rather than having to carefully order their lines of code, most people prefer to just avoid circular imports. So they make small base modules like 'meta' and 'errors' that everybody can import, but which themselves import only the Python standard library. > Why: __init__.py -- there are lot's better names. > Also, when one uses IDE and tries to find (by incremental file search) > "__init*" there are many of them. Name it domain.py or model.py > And finally: any Python ways to split _my_ big file? __init__.py is a Python language feature, and there's nothing the Pylons developers can do about it. (Except switch to Ruby :). > 3) "flash messages" : data persisted somewhere between http session > and http request, which lives through one session of http redirects, > but then is purged. > > I often need that, as I place some common controller logic in some > controllers. Say: home.py:home which redirects to home.mako, and loads > complete user profile. I often use > h.redirect_to(cont=home,action=home) from inside other controllers. > I think such feature should be built in, similar to "c", and "session" > variables. As MikeB said, this is in webhelpers.pylonslib.Flash in WebHelpers 0.6. It was decided not to put it into core Pylons because it's a non-essential feature, and Pylons wants to be small. It's in 'pylonslib' rather than in a regular helper module because it depends on pylons.session. > 4) CRUD: generate view + controller methods > > Having controller file with CRUD methods already defined (using SQLA) > and redirecting to template files would be nice to have. > I don't need that at this stage of project, where I use custom views > all over the place. But for beginners it would be nice to have > CRUD*.mako(s) created (as option?) and to have working application > almost instantly. > It's often said that Django does that, and Pylons not :( We've been hoping TurboGears would build this for us. They had an old admin interface (Catwalk) and said they were going to build a new one. When Pylons and TurboGears teamed up, it was agreed that Pylons would concentrate on the core functionality (the essentials), and TG would build the extra stuff like ToscaWidgets, Javascript interfaces, and admin screens. According to Adrian's talk at PyCon this year, Django's CRUD interface should theoretically run on Pylons. Somebody just needs to test it and write a HOWTO. Ben and I thought it would be coming soon, but it got lost among all the other work finishing up 0.9.7. FormAlchemy also handles part of this problem. It builds a form based on an ORM object. You could probably build a generic CRUD interface based on this. One of Pylons' shortcomings is the ability to bundle up a few controllers/templates/models/routes together so they can be plugged into a larger Pylons application. ToscaWidgets does this with HTML/CSS/Javascript, and Pylons needs something analagous for chunks of functional code. We've tried a few approaches but haven't come up with anything satisfactory. The best idea we've found is to make a controller delegate to another WSGI application. This lack of infrastructure is one of the things that has been holding back a portable CRUD interface and other generic tools. -- Mike Orr <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
