Thanks both of you for answers...
On Mon, Oct 13, 2008 at 7:39 PM, Wayne Witzel <[EMAIL PROTECTED]> wrote:
> On Oct 13, 12:14 pm, "Tomasz Nazar" <[EMAIL PROTECTED]> wrote:
>> Hi there!
>>
>> 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.
Table definitions might be in one place. I don't bother about that.
It's around 50 lines.
What I want is to separate classes definition into separate files / modules.
I always hit the wall with Python saying 'cannot import name ..' --
cause of recursive dependencies.
And for that I see place of having a doc for that.
I'm influenced a bit by Java, so I might not fully understand Python modules.
If modules are the only way to separate into files - I'm fine.
I will try again to split with latest Pylons code, maybe I'm having
some stupid bug. But I was trying 2 times and failed. Let's make it 3
then.
>> 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))
I don't bother if it's implemented with memcached or any other. I
bother about having it at all.
Don't say to me it's easy to implement. If it's easy then as an author
I'd feel obliged to provide that. Other ORMs in the world have that.
Should I say more.. (?)
OK. Back to your code? What is this MemCachedMapper.. google 2 hits
only. Is it your own solution, does it work, can you share?
>> 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>
Yeah. I already did that months ago. I just feel it's good to propose
to include in Pylons, so you know one would make use of that..
>> 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 :)
If it's 2-way you don't go it. Someone else could go..
I don't insist on that. It'd be nice to have. I will have look at what
you propose. Thanks.
>> 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.
Sorry for not being precise. The point was that I felt ... surprised,
that installed Pylons to a friend, and I've seen some "*beta*" egg
dependencies. It's about naming. I was not expecting beta stage..
--
_i______'simplicity_is_the_key'__________tomasz_nazar
_ii____'i_am_concern_oriented'________________JKM-UPR
_iii__'patsystem.sf.net'___________________linux_user
_'aspectized.com'___________________________prevayler
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
