On Mon, Oct 13, 2008 at 10:11 PM, Mike Orr <[EMAIL PROTECTED]> wrote: > > 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. >> Most of the feature you suggest aren't part of pylons because they depend on a style of programming that may not fit everyone. But most of the things you need are actually build into TG2, except the SA catching, which as Mike suggested isn't really needed in the SA/web world.
>> 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. > TG2 default model templates work like this, it does a little magic in order to prevent the circular imports issue but the code is really simple. And can be ported almost directly to pylons http://svn.turbogears.org/projects/tg.devtools/trunk/devtools/templates/turbogears/+package+/model/ >> 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. > the underlaying problem is that if you want to make your models available as model.Obj instead of model.obj.Obj you need to provide this "magic" with the meta.py and __init__.py if you will reference everything in a java-like form, then you can get rid of the imports in model and everything works fine, but then you don't have the flexibility of reorganizing stuff inside the model package without breaking your client code. Bottom line it's a very handy feature that require a little obscure code, and by obscure I mean it's not logical at first glance not that is complex code. >> 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 :). > hehehe rulons >> 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. > ohh that's really nice I didn't knew it was implemented there. perhaps we should change turbogears.flash to use that instead of using our own copy. Kudos to adding that as almost everyone had their own version inside their helpers.py >> 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. > ok I think you are mixing two things here. #1 crud - as in code generation #2 admin interface - as in a real way to update models both approaches have their advantages and disadvantages which I won't cover here. as for #1 there is tgcrud which is part of tg.devtools which is something you get plugged into your paster quickstart command. http://svn.turbogears.org/projects/tg.devtools/trunk/devtools/templates/ as for #2, they are currently two implementation out there. 1- DBMechanic, http://code.google.com/p/dbsprockets/wiki/DBMechanic 2- rum, http://toscawidgets.org/documentation/rum/ The state here is that DBMechanic is stable but has a stop development because rum is made to be a LOT more flexible, it's so flexible that you can write your own views, don't use toscawidgets, write your own backend, your own controllers, and it's fully wsgi. in fact rum is more like a little application you can fully configure and stick in your wsgi stack. > 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. > django-admin? how will it know about all the model configuration stuff? is there any links anywhere that suggest how it should be done? last time I heard django's sqlalchemy compatibility was in an abandoned branch. Also I assume you still need to install the whole tarball to get it running. Since we are in the subject, someone could write a rumDjango backend to make django-models work inside it. > 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. This is the current approach in TG, you can mount any other TG app as a wsgi delegate or simply make a controller a wsgi app. And I agree with you we need something simpler, that will let things get aggregated. > > -- > 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 -~----------~----~----~----~------~----~------~--~---
