On Oct 13, 12:14 pm, "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)
> Is reason other than problems with pure Python imports (which don't
> work well for recursive dependencies)?
> 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?
>
You can take this as far as you would like. I have my init_model
method and mappers in model/__init__.py
My tables and their classes and logic are each in their own file in
model/tables
from project.model.tables import table1
__init__.py is a Python convention and really has nothing to do with
Pylons.
> 2) SQLAlchemy 2nd level cache
>
> That is most frustrating for me coming from Hibernate, where it's
> built in. You may point to memcached or whatever, but the truth is it
> improves performance and coding style hugely!
> I would love to optimize later and be a bit lazy.
> Maybe the authors do not have resources -- it's a great soft anyway --
> but that should be one of the 1st features on the roadmap.
>
Memcached works great. Why implement an maintain another 2nd level
caching system when a good one already exists and is very easy to
plugin to SA?
mapper(Foo, foo_table, extension=MemCachedMapper(mc, timeout=35))
> 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.
>
Make yourself a component template and include it on pages you need to
present a flash
<%def name="flash()">
% if session.has_key('flash'):
<div id="flash"><p>${session.get('flash')}</p></div>
<%
del session['flash']
session.save()
%>
% endif
</%def>
> 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 :(
>
But what if I don't want that? .. 2-way street. Take a look at the
template for RESTful controllers. You could easily implement yourself
a CRUD controller to do just this. Then make a patch and open a
feature ticket and attach your patch. Who knows :)
> 5) easy_install pylons - Beta
>
> It's a minor, but let me say that: When last time I installed Pylons
> in Windows for a friend, it downloaded some eggs which were beta stage
> (sqlalchemy?). I just know that proper 0.9.6 app was not working.. We
> had to downgrade few eggs to make it work.
>
I can see the point here, I've done many a easy_install which needed a
rollback because the latest version of Foo was borked.
I usually find myself freezing my Python installation once development
starts on the application and doing sprints to phase in new product
versions.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
