Hi, I am trying to do the similar thing.
It works if I use config.add_route()
but if I use @view_config, it does not work me and keeps complaining
that it cannot find renderer
what is the problem?
Thanks
On Mar 4, 4:27 pm, Mengu wrote:
> for development, i recommend you using paster. you can
sure you can start with pyramid. pyramid 1.0 is already production
ready with its awesome docs.
On Mar 4, 5:10 am, Ravi wrote:
> Hi Group:
> I have started a new web based project and it is in its
> early stage. So with pylons merging with pyramids, I have two
> questions:
>
> 1) do
for development, i recommend you using paster. you can just do "paster
serve --reload development.ini".
- make sure you have "mako.directories = appname:templates" under
[app:appname] directive in your *.ini files.
- when you add a route or so, do not set the path like "/templates/
index.html" jus
Yeah like i said it's not a big deal for me, I would like it, but not doing
it is obviously not preventing me from using pyramid to do some really cool
stuff on GAE, and quickly.
--
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To post to thi
By that I meant, following a previous post I made, to possibly create
new comer guides, opinionated guides, etc... to fill the missing gap.
I don't think the current docs need to track down those requests, they
are not perfect but they are great.
Another point is complaint about pyramid needing mo
On Fri, 2011-03-04 at 16:38 -0500, Reed L O'Brien wrote:
> On Mar 4, 2011, at 3:42 PM, Blaise Laflamme wrote:
>
> > That said we definitely need to communicate the right message, provide
> > the right level of documentation for the targeted audience, have a
> > better way to expose tools and contr
On Fri, 2011-03-04 at 13:35 -0800, Rocky Burt wrote:
> I would be +1 on splitting this up to pyramid_chameleon and
> pyramid_mako. But that's almost certainly because I have no use for
> either of those templating languages and for my specific work they
> sort of feel like bloating pyramid core.
>
On Mar 4, 2011, at 3:42 PM, Blaise Laflamme wrote:
> That said we definitely need to communicate the right message, provide
> the right level of documentation for the targeted audience, have a
> better way to expose tools and contributions, etc...
Who is the targeted audience? Currently it seems
I would be +1 on splitting this up to pyramid_chameleon and pyramid_mako.
But that's almost certainly because I have no use for either of those
templating languages and for my specific work they sort of feel like
bloating pyramid core.
That being said, their presence doesn't cause any real pro
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/04/2011 03:36 PM, Blake Hyde wrote:
> On Fri, Mar 4, 2011 at 3:25 PM, Mike Orr wrote:
>> On Fri, Mar 4, 2011 at 12:03 PM, Blake Hyde wrote:
>>> On Fri, Mar 4, 2011 at 2:50 PM, Mike Orr wrote:
I have a friend who is a marketer and supports
On 3/4/11 12:03 PM, Mike Orr wrote:
I'll be at the Pyramid sprint but I don't know what I'll be doing.
I would like to learn Git and Pyramid-at-Github if somebody would like
to do a mini crash course.
I'm no git guru, but I've been using it pretty heavily for the last 6
months and would be ha
Well... same for me, I got a lot of clients work to complete and I've
done my best trying to put everything in place to have something
cohesive. I also got help from multiple people for different tasks and
I'm grateful for every contribution.
That said we definitely need to communicate the right m
On Fri, Mar 4, 2011 at 3:25 PM, Mike Orr wrote:
> On Fri, Mar 4, 2011 at 12:03 PM, Blake Hyde wrote:
>> On Fri, Mar 4, 2011 at 2:50 PM, Mike Orr wrote:
>>> I have a friend who is a marketer and supports the Pylons Project, but
>>> he's kind of gotten burned out on Python as a whole for various
>
On Fri, Mar 4, 2011 at 12:03 PM, Blake Hyde wrote:
> On Fri, Mar 4, 2011 at 2:50 PM, Mike Orr wrote:
>> I have a friend who is a marketer and supports the Pylons Project, but
>> he's kind of gotten burned out on Python as a whole for various
>> reasons so he can't quite be a full marketing adviso
On Fri, Mar 4, 2011 at 2:50 PM, Mike Orr wrote:
> I have a friend who is a marketer and supports the Pylons Project, but
> he's kind of gotten burned out on Python as a whole for various
> reasons so he can't quite be a full marketing advisor. Is there anyone
> else with marketing-type experience
I'll be at the Pyramid sprint but I don't know what I'll be doing.
I would like to learn Git and Pyramid-at-Github if somebody would like
to do a mini crash course.
On Fri, Mar 4, 2011 at 11:38 AM, Blaise Laflamme wrote:
> I'm up too
>
> On Mar 3, 8:09 pm, Carlos de la Guardia
> wrote:
>> Guys,
On Fri, 2011-03-04 at 12:00 -0800, Mike Orr wrote:
> On Thu, Mar 3, 2011 at 11:42 PM, Peter Alexis wrote:
> >>I mentioned "unless there are new magical docs", because I think 99%
> >> of the problems with pyramid right now are the docs. They're hard to
> >> sift through (rather dense) and easy to
On Thu, Mar 3, 2011 at 11:42 PM, Peter Alexis wrote:
>>I mentioned "unless there are new magical docs", because I think 99%
>> of the problems with pyramid right now are the docs. They're hard to
>> sift through (rather dense) and easy to miss things in. Meanwhile,
>> docs for projects like Djan
On Fri, Mar 4, 2011 at 12:11 AM, mjmein wrote:
> One also just needs to define what the ultimate goal is:
>
> Is it to compete with Django/Rails? In that case I agree that alot of
> work needs
> to be done on simplifying and removing options. The power of Django/
> Rails are that
> they provide on
Could you put this in the Pyramid issue tracker?
On Fri, 2011-03-04 at 14:28 -0500, Daniel Holth wrote:
> My wishlist for the manual:
>
> 1. searching for request.response_headers should pull up
> request.response_headerlist
> 2. glossary for 'Configurator' etc. should link to function signatures
I'm up too
On Mar 3, 8:09 pm, Carlos de la Guardia
wrote:
> Guys,
>
> I'll be at PyCon and would like to sprint on this. Maybe a tutorial
> with code. Anyone?
>
> Carlos de la Guardia
>
>
>
> On Thu, Mar 3, 2011 at 6:08 PM, Chris McDonough wrote:
> > On Thu, 2011-03-03 at 17:57 -0600, Joe Dallag
My wishlist for the manual:
1. searching for request.response_headers should pull up
request.response_headerlist
2. glossary for 'Configurator' etc. should link to function signatures
--
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To post to t
On Fri, Mar 4, 2011 at 9:39 AM, Chris McDonough wrote:
> Of these, the only ones to very easily *not* install would be Mako,
> Chameleon, PasteScript, Paste, and PasteDeploy. The others are core
> dependencies that really can't very easily be externalized.
>
> Doing that would take us down to 13
On Fri, Mar 4, 2011 at 12:11 AM, Chris McDonough wrote:
> So we should reorganize by moving chapters of the documentation around?
Maybe if we just rename the Pyramid manual to the Pyramid Reference
Manual it will set readers' expectations appropriately. I'm not sure
if there's anything that needs
I'm not really complaining as deploying with all the dependencies to ae is a
one time config thing for now. Just putting my "+" in there as i think it
would be nice to deploy with the bare minimum when you are deploying to
environments that have hard limits on things like file count and startup
On 02/03/2011 00:48, Michael Merickel wrote:
I noticed in your example you aren't specifying a context= or for_= in
the view_config, implying you maybe intended to use route_name instead
of name with url dispatch.
Nope, no routes here, these are just views hanging off /, not registered
against
Pasta is delicious. Choice is here to stay.
I think frustrated people tend to overestimate the cost of reading a
600-page book (the documentation) or installing 17 dependencies
(automatically). It will pay off to understand the tools you are using over
the lifetime of a significant application;
On 01/03/2011 16:59, Jean-Philippe wrote:
First off, I believe your views need to be named for this to work.
But views don't need to have names ;-)
That being said, the following would work from within a view callable:
url = request.route_path('history')
...not if I'm not using a route...
On 01/03/2011 21:21, Wichert Akkerman wrote:
This feels like a bug to me but I thought I'd throw it out here in case
I missed something...
Sounds like something that should be added here:
https://github.com/Pylons/venusian/issues . It might even be the same
problem as https://github.com/Pylons/
Sorry to jump in here at the end, but just wanted to put a word in.
The extra dependencies are due to the fact that pyramid integrates a lot of
other very good packages. This IS a GOOD thing, not bad. It makes pyramid
better and those other packages better because there are more "stakeholders"
in
On Mar 4, 2011, at 12:39 PM, Chris McDonough wrote:
> On Fri, 2011-03-04 at 04:43 -0800, Andrey Petrov wrote:
>> Re: Excessive dependencies.
>
>
> Of these, the only ones to very easily *not* install would be Mako,
> Chameleon, PasteScript, Paste, and PasteDeploy. The others are core
> dependen
On Fri, 2011-03-04 at 04:43 -0800, Andrey Petrov wrote:
> Re: Excessive dependencies.
>
>
> Right now when you 'pip install pyramid' on a fresh environment, you
> get 18 packages installed:
>
>
> Chameleon, Mako, MarkupSafe, Paste, PasteDeploy, PasteScript, WebOb,
> pyramid, repoze.lru, transla
For the record, Bottle takes this tact. It's full feature set actually
depends on many, many packages (many more than Pyramid does). But it
ships as a single file with no dependencies.
I'm not a huge fan of this. Maybe it's a successful marketing gimmick
but it doesn't actually reduce any compl
begin*
On Fri, Mar 4, 2011 at 11:07 AM, Joe Dallago wrote:
> Go with Pyramid. You have to think about your application 2-3 years
> down the road. You might be fine writing it in Pylons now, but as
> people start to convert, support will being to dwindle.
>
> On Thu, Mar 3, 2011 at 9:10 PM, Ravi
Go with Pyramid. You have to think about your application 2-3 years
down the road. You might be fine writing it in Pylons now, but as
people start to convert, support will being to dwindle.
On Thu, Mar 3, 2011 at 9:10 PM, Ravi wrote:
> Hi Group:
> I have started a new web based proj
that's not a bad idea. I'm using pyramid on app engine, and don't need
chameleon, but if I don't push chameleon up to the cloud the app fails to
load last time I tried it.
of course defining the bare minimum would probably be a challenge. :)
--
You received this message because you are subscr
On Thu, 2011-03-03 at 19:09 -0600, Carlos de la Guardia wrote:
> Guys,
>
> I'll be at PyCon and would like to sprint on this. Maybe a tutorial
> with code. Anyone?
I'd be up for that, although I'm also slated to help port WebOb to Py3k.
>
> Carlos de la Guardia
>
> On Thu, Mar 3, 2011 at 6:08
Hi Group:
I have started a new web based project and it is in its
early stage. So with pylons merging with pyramids, I have two
questions:
1) do you all suggest starting with Pyramids ? Or shall I wait for
some more months ?
2) Are there any DO/DON'T that I should follow for make sur
Hi all,
I just created a new project using the pyramid_sqla template (which
includes mako template engine).
Then followed the "run under mod_wsgi" instructions [1], but I get the
following error:
TopLevelLookupException: Cant locate template for uri 'index.html'
Does anybody have an idea about wh
Guys,
I'll be at PyCon and would like to sprint on this. Maybe a tutorial
with code. Anyone?
Carlos de la Guardia
On Thu, Mar 3, 2011 at 6:08 PM, Chris McDonough wrote:
> On Thu, 2011-03-03 at 17:57 -0600, Joe Dallago wrote:
>> So the thing we can carry away from this discussion is that we shou
The tyranny of choice study gets thrown around a lot, but when there
are familiar options it's less of a problem.
And there's the opposite problem, not enough choices also presents
problems. I can't find the study, but notice all the different kinds
of spaghetti sauce in the isle at the supermar
Psychologists have done a significant amount of research documenting the
"tyranny of choice" and famously served samples of exotic jams "when choice
is demotivating" (
http://www.columbia.edu/~ss957/articles/Choice_is_Demotivating.pdf). At
least for jam, 6 choices is OK, while 30 choices are demoti
I think the problem lies in the fact people think pyramid provides
rails and it's actually not the case. Not that pyramid should not
provide higher level tools but at this stage it's not pyramid goal. I
also think pyramid should be used for multiple higher level frameworks
with their own opinions,
Re: Excessive dependencies.
Right now when you 'pip install pyramid' on a fresh environment, you get 18
packages installed:
Chameleon, Mako, MarkupSafe, Paste, PasteDeploy, PasteScript, WebOb,
pyramid, repoze.lru, translationstring, venusian, zope.component,
zope.configuration, zope.deprecatio
Am 04.03.2011 09:11 schrieb mjmein:
In my mind we still need something that works on Django level, with
more constraints imposed, but I am expecting that the new version of
TurboGears based on Pyramid would address that.
That's also my understanding.
Our experience with the TG project is also
One also just needs to define what the ultimate goal is:
Is it to compete with Django/Rails? In that case I agree that alot of
work needs
to be done on simplifying and removing options. The power of Django/
Rails are that
they provide one way of doing things that works in the most cases. The
probl
On Thu, 2011-03-03 at 23:42 -0800, Peter Alexis wrote:
> >I mentioned "unless there are new magical docs", because I think 99%
> > of the problems with pyramid right now are the docs. They're hard to
> > sift through (rather dense) and easy to miss things in. Meanwhile,
> > docs for projects like
>I mentioned "unless there are new magical docs", because I think 99%
> of the problems with pyramid right now are the docs. They're hard to
> sift through (rather dense) and easy to miss things in. Meanwhile,
> docs for projects like Django and Rails are really light and breezy...
> and link to
48 matches
Mail list logo
