On Fri, Nov 5, 2010 at 1:50 PM, Jens Hoffrichter
wrote:
> - The deprecation of rails-style webhelpers. We depend on those quite a bit
> in our first application we wrote (and which is still live)
WebHelpers 0.6.4 is still on PyPI for just this reason. But it was
hard to maintain, the APIs were bo
Having a nearly-ready made CMS on top of Pylons would be the most amazing
thing likeever ;)
I have struggled too much with the shortcomings of PHP based CM systems over
the years (and I'm doing so right now, once more, with growing pains).
That much said, I would love to contribute something
On Nov 5, 2010, at 1:50 PM, Jens Hoffrichter wrote:
> Thanks to especially Graham and Mike to point out what the benefit for the
> "end-user-developer" (a crude term, I know ;) ) will be with the
> Pylons2/Pyramid move.
>
> When I started to read these posts, I was a bit concerned, too. I (we,
Hi Mike...I don't have much technical input on such a thing right now,
but we've been threatening to do this for a while:
http://lists.repoze.org/pipermail/cmf3k/
We've actually had two in-person sprints on it, but it's a large job and
not much was produced, at least not much that is very consuma
On Nov 5, 3:55 pm, Mike Orr wrote:
> Less confrontation, Chris, please. Pylons users are legitimately
> concerned about any sudden changes in the API, abandonment of
> previously-supported versions, and over-Zopeification. Also, Pyramid
> is being introduced to them in a haphazard way, rather than
I've started wondering about porting a subset of Plone to Pyramid.
Pylons has long lacked a full-featured CMS package. While Plone can be
mounted as a sub-URL or vice-versa, it's still really big and
different and harder to extend. As a programmer I'd be interested in
making custom Plone products f
Hi all,
Thanks to especially Graham and Mike to point out what the benefit for the
"end-user-developer" (a crude term, I know ;) ) will be with the
Pylons2/Pyramid move.
When I started to read these posts, I was a bit concerned, too. I (we, my
company) have been long time Pylons users, and admitt
As some may have noticed in the tweetsphere (or whatever the catchy term is for
that), a Pylons + repoze.bfg framework merger is under way. Some will be
shocked, sad, excited, etc. at this move. We wanted to have a good amount of
'support' under the new combined effort which was the main reason
On Fri, Nov 5, 2010 at 8:05 AM, Graham Higgins wrote:
> Kevin J Smith wrote:
>> From
>> the page on pyramids it seems to suggest that pylons post 1.0 will be using
>> pyramids? If so, statements like "no controllers" kind of frighten me ...
>> and quite frankly most things that are Zope related f
On Nov 5, 2010, at 11:36 AM, Kevin J. Smith wrote:
> I found it all a bit depressing, mind you, because I have chosen to build our
> application on a technological dead end framework (Pylons 1.x) But if there
> is some inherent architectural dead end to Pylons 1.x then I completely
> understan
On Fri, Nov 5, 2010 at 11:58 AM, Eric Rasmussen wrote:
> This has been a fascinating discussion! I don't have anything to add that
> hasn't already been expressed, but I second Kevin's request to try it out
> and see how it works.
>
> More specifically, to the developers: do you need testers? I'm
This has been a fascinating discussion! I don't have anything to add that
hasn't already been expressed, but I second Kevin's request to try it out
and see how it works.
More specifically, to the developers: do you need testers? I'm planning some
updates to one of my side-projects, and I'd be happ
Thanks for that very thorough dissertation of the state of the Pylons union!
I found it all a bit depressing, mind you, because I have chosen to build
our application on a technological dead end framework (Pylons 1.x) But if
there is some inherent architectural dead end to Pylons 1.x then I
compl
On Fri, Nov 5, 2010 at 9:24 AM, David Gardner wrote:
> So as a user what matters to me is that I can still continue to:
>
> 1) use SQLAlchemy to fetch stuff
> 2) call some backend modules with that data
> 3) maybe store the results in Beaker
> 4) then send those results to Mako
Yes for 1, 3, and
Yeah, the main issue is that I think the new structure at a high level can
be a little confusing, since the Pylons name is changing from a framework to
a project. The distinction between Pylons 1.0 and Pylons project makes it
difficult to relay the Pylons name and the fact that Pyramid is a standal
My $0.02 USD:
As a longtime Pylons classic (1.x) and sometimes Zope 3 user, I'm
intrigued by Pyramids.
A disclaimer: I was not fond of classical Zope 3 development. Since I
worked with a longtime Zope veteran (Jeff Shell), I know why Zope 3
was an architectural improvement over Zope 2. But the ap
So as a user what matters to me is that I can still continue to:
1) use SQLAlchemy to fetch stuff
2) call some backend modules with that data
3) maybe store the results in Beaker
4) then send those results to Mako
I suspect this is probably going to be the case, so I'm cool.
Any incompatibilitie
Can you point to some decent documentation on getting Sprox to work
with Pylons that doesn't require translating TG's implementation of
Pylons? It's been about 6 months since I tried to shove Sprox into my
Pylons app without a lot of success. I've only recently been digging
into Django, and I've
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Kevin,
On 4 Nov 2010, at 23:44, Kevin J. Smith wrote:
Someone pointed out pyramids to me (http://docs.pylonshq.com/pyramid/dev/narr/introduction.html
) and I am a bit confused with the relationship between pyramids and
pylons.
I have been usin
On Fri, Nov 5, 2010 at 2:34 AM, daniel wrote:
> had a quick look at pyramid ... too complex to me and not really
> understand for which benefits, which could not be handled with the
> lovely pylons ..
The Pyramid book is a reference manual so it contains all the details.
More Pylons-specific guid
On Nov 5, 7:15 am, daniel wrote:
> No criticism at all, although it would be nice getting the relevant
> user's benefits of the change. The complexity I talked about as well
> the allergy to zope is a personal perception I would wish expressing
> here (perhaps I'm the only one feeling that, then j
No criticism at all, although it would be nice getting the relevant
user's benefits of the change. The complexity I talked about as well
the allergy to zope is a personal perception I would wish expressing
here (perhaps I'm the only one feeling that, then just don't care
about it)
I decided to jum
@Tim: apologies for huge delay in responding on this. Missed this when
first came through and only noticed this now when reading back threads
...
On 24 May 2010 10:05, Tim Black wrote:
> On 05/23/2010 03:51 AM, Rufus Pollock wrote:
>> On 22 May 2010 21:25, Tim Black wrote:
[...]
>> If so that at
so we did it...
import pylons
from pylons.controllers.util import Response
response_options = config['pylons.response_options']
request_counter = 1
while request_counter <= MAX_REQUEST_TRIES:
try:
pylons_obj = environ['pylons.pylo
On Nov 5, 5:44 am, chrism wrote:
> > I feel should consider whether it's time for me to step back to
> > django .. I always hated zope (useless ?) complexity and I love simple
> > way of thinking
>
> I've spent ten years using Zope. Pyramid is not Zope. It does use
> several packages in the zope
On Nov 5, 5:34 am, daniel wrote:
> had a quick look at pyramid ... too complex to me and not really
> understand for which benefits, which could not be handled with the
> lovely pylons ..
More specific criticism would be helpful.
> I feel should consider whether it's time for me to step back to
had a quick look at pyramid ... too complex to me and not really
understand for which benefits, which could not be handled with the
lovely pylons ..
I feel should consider whether it's time for me to step back to
django .. I always hated zope (useless ?) complexity and I love simple
way of thinkin
27 matches
Mail list logo
