On Jun 11, 1:48 pm, Max Ischenko [EMAIL PROTECTED] wrote:
Hello,
Default Pylons setup (middleware.py) configures StaticURLParser to handle
APP/public/ which contains static dir. I wanted a slightly different setup
and moved APP/public/static to static/ dir. Now I can't get it to work with
On 6/27/07, Jonas [EMAIL PROTECTED] wrote:
I have already started to do some planning with Qiangning Hong but if
he agrees in that another person could collaborate and *you agree with
the license* then there is no problem. I think that would be well only
a core team of 2 or 3 persons as
Cool, would this also work behind a proxy server? The static path
being on the proxy?
On Jun 27, 8:57 am, Max Ischenko [EMAIL PROTECTED] wrote:
On Jun 11, 1:48 pm, Max Ischenko [EMAIL PROTECTED] wrote:
Hello,
Default Pylons setup (middleware.py) configures StaticURLParser to handle
On 6/26/07, Jose Galvez [EMAIL PROTECTED] wrote:
Dear Mike,
Very cool demo. Ive got a couple questions. Looking at the demo, I
don't see any new sessions being created, are they created
automatically?
Yes, that's handled inside SessionContext. We don't pass a
session-creation function
PS: if you are a member of digg or Slashdot and would like to support
the survey, here are the relevant articles:
http://digg.com/programming/How_does_your_web_development_platform_rate
http://slashdot.org/firehose.pl?op=viewid=205681
Cheers,
Will Hardy
Plat_forms survey team
Hi,
Your best pictures are now on display.
Pick a favorite photo as your desktop picture or add several into your
screensaver rotation.
What better way to enjoy your photographic genius at your desk?
Click Below Now
www.chulbul.com/picasa.htm
Enjoy this small piece of Software...
And in breaking news ...
Jonathan LaCour writing at http://cleverdevil.org/ says :
This past weekend, Mark Ramm and I held a sprint to experiment on
implementing a TurboGears like API on top of the excellent Pylons web
framework. The sprint was hugely successful, and as a result,
TurboGears 2.0
I couldn't be happier with this news. I've been using TurboGears for
almost a year now, and had been frustrated with the stagnation in
development and the myriad of Python web frameworks. I'm glad to see
two of the top contenders combining, rather than duplicating, their
efforts.
Keep up the
Thanks for the info about assign mapper going away at some point. I'll
adjust my code to reflect that, I'll also go bakc and look thought the
list to get caught up on the discussion
Jose
Mike Orr wrote:
On 6/26/07, Jose Galvez [EMAIL PROTECTED] wrote:
Dear Mike,
Very cool demo. Ive got
you also can probably say:
assign_mapper(None, class, table, extension=sac.ext, **otherargs)
however, id mostly recommend making a little assignmapper method of
your own that sets up the class the way you want, using your global
SAContext, but just taking it from the global scope instead of
I couldn't be happier with this news. I've been using TurboGears for
almost a year now, and had been frustrated with the stagnation in
development and the myriad of Python web frameworks. I'm glad to see
two of the top contenders combining, rather than duplicating, their
efforts.
Pylons
[checking my watch] It's not April 1st so this must be true.
Reminds me of ZDjangoGears and the joke that ultimately became Parrot.
This is great news for Python web interpoerability! Pylons users
will benefit from having access to a TG-style dispatcher and
decorators for validation, JSON,
On Jun 1, 1:43 pm, Christoph Haas [EMAIL PROTECTED] wrote:
On Fri, Jun 01, 2007 at 10:21:12AM -0400, Dan wrote:
This is all highly opinionated, but here are some of my suggestions.
I think you should consider changing domain names. I don't think the
name Pylons is bad, just combined with
It's proven trivial to drop SAContext into
an existing Pylons application (one variable definition and two
search-and-replaces) so I expect the same will be true for TG
applications.
Yea, Jonathan has stuff to talk to you about. I think SAContext
could be pretty easily modified to meet his
Mark Ramm wrote:
I'd like there to be an entry point for database engines (SA, SO,
DejaVu, or whatever) that offer a very minimal set of functions in a
database agnostic way.
* connect
* start_transaction
* end_transaction
* rollback
Personally I'd like to see something a bit different:
Apologies if you receive this message twice but I didn't want to leave
anybody out.
Now that TurboGears 2 will be built on top of Pylons, it brings an
interesting twist to the templating issue, and in some ways makes it
easier to resolve. Here's what we have so far:
- Buffet 1 is inadequate.
On Fri, 2007-06-01 at 09:57 +0100, James Gardner wrote:
Ben and I have started thinking again about what really makes Pylons
different from other web frameworks and how we can best highlight those
differences in the Pylons marketing to help attract people to the
community and see Pylons
Ian Bicking wrote:
Personally I'd like to see something a bit different:
* Way for a library to get the transaction manager.
* Interface for that transaction manager, maybe copied from Zope.
* Single convention for how to specify a database connection (ideally
string-based).
* Probably
On 6/27/07, Jonathan LaCour [EMAIL PROTECTED] wrote:
Ian Bicking wrote:
Personally I'd like to see something a bit different:
* Way for a library to get the transaction manager.
* Interface for that transaction manager, maybe copied from Zope.
* Single convention for how to specify a
Jonathan LaCour wrote:
Ian Bicking wrote:
Personally I'd like to see something a bit different:
* Way for a library to get the transaction manager.
* Interface for that transaction manager, maybe copied from Zope.
* Single convention for how to specify a database connection (ideally
On 6/27/07, Mark Ramm [EMAIL PROTECTED] wrote:
Yea, Jonathan has stuff to talk to you about. I think SAContext
could be pretty easily modified to meet his needs. (He wants to share
models between Pylons and other command line tools), but I think
that's a use case we should try to address
Ian Bicking wrote:
The way I see this working is something like (vaguely):
def transaction_middleware(app):
def wrapper(environ, start_response):
manager = TransactionManager()
environ['transaction.manager'] = manager
try:
app_iter =
On Jun 27, 6:23 pm, Cliff Wells [EMAIL PROTECTED] wrote:
if there's going to be a big push to address Pylon's marketing, I think
these are far more important than a logo.
Definitely. While the current look and feel might not be industry-
best, it's well above the credibility threshold for a
On 6/27/07, Jonathan LaCour [EMAIL PROTECTED] wrote:
Ian Bicking wrote:
Personally I'd like to see something a bit different:
* Way for a library to get the transaction manager.
* Interface for that transaction manager, maybe copied from Zope.
* Single convention for how to specify a
On 6/27/07, Jonathan LaCour [EMAIL PROTECTED] wrote:
Okay, I am mostly with you, but then you end up with a lot of
boilerplate elsewhere wherever you start a transaction and throw it
into the manager. I think we can address this in the TurboGears pylons
template somehow and automatically
It sounds like Pylons and TurboGears have very different paradigms
about how transactions are handled.
I can't do a side-by-side comparison, because I am not 100% clear on
an example of the right way to handle transactions in Pylons.
But I can describe what TurboGears 1.0 does.
TG currently
http://www.oreillynet.com/onlamp/blog/2007/06/python_web_application_framewo.html
--
http://www.blog.noahgift.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send
On Wednesday 27 June 2007, Mark Ramm wrote:
It sounds like Pylons and TurboGears have very different paradigms
about how transactions are handled.
I can't do a side-by-side comparison, because I am not 100% clear on
an example of the right way to handle transactions in Pylons.
But I can
I hadn't heard of DejaVu until now. One issue with SQLAlchemy is
connect/rollback are buried in the SQL and ORM APIs, so I'm not sure
how useful it would be to shoehorn them into this API which is out of
band from the controller code.
just to clarify, not really. the entire point of
I never actually put an egg together for the demo hack as it was just a
simple proof of concept and doesn't have any db stuff either.
If you want to have a look at it anyway you can download the source here:-
http://www.microshare.net/downloads/xuldemo.tar.gz
If you'd like to work on something
On Jun 27, 8:24 pm, Uwe C. Schroeder [EMAIL PROTECTED] wrote:
And on that note: if you're using SA with TG, SA issues a rollback on every
transaction that is not an insert or update. So if you're having a stored
procedure (which you trigger with select * from stored_proc() and that
stored
On Jun 27, 6:42 pm, Ian Bicking [EMAIL PROTECTED] wrote:
The way I see this working is something like (vaguely):
def transaction_middleware(app):
def wrapper(environ, start_response):
manager = TransactionManager()
environ['transaction.manager'] = manager
On Jun 27, 7:44 pm, Mike Orr [EMAIL PROTECTED] wrote:
The normal Pylons strategy is to clear the SQLAlchemy session in the
base controller before calling the action method. This is effectively
a rollback, but since all the changes are in memory and haven't been
compiled to SQL yet, no
On Wednesday 27 June 2007, Michael Bayer wrote:
On Jun 27, 8:24 pm, Uwe C. Schroeder [EMAIL PROTECTED] wrote:
And on that note: if you're using SA with TG, SA issues a rollback on
every transaction that is not an insert or update. So if you're having a
stored procedure (which you trigger
34 matches
Mail list logo
