Re: pyramid CRUD
The screenshots look great. I'd be very interested in seeing this developed further. On 11 February 2011 15:45, Andrew Mleczko wrote: > Beeing a bfg user (now also pyramid) I was searching for crud > integration with rich UI. For our internal usage we have developed one > based on formalchemy (please see > http://blog.redturtle.it/redturtle-blog/2011/02/10/pyramid-crud > for details). It's just a proof-of-concept but it shows interesting > perspectives. I'm wondering if there is an interest in pyramid/pylons > community in having something similar? Or have I missed one? > > andrew > > -- > You received this message because you are subscribed to the Google Groups > "pylons-devel" group. > To post to this group, send email to pylons-devel@googlegroups.com. > To unsubscribe from this group, send email to > pylons-devel+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/pylons-devel?hl=en. > > -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: default permission overriding
As an aside, it would be a good idea to have a constant value instead of "__no_permission_required__". On 18 February 2011 17:14, Chris Withers wrote: > On 18/02/2011 16:48, Chris McDonough wrote: >>> >>> @view_config(context=Blog, name='add_entry.html', permission=None) >>> >>> ...seems an explicit and less cumbersome way of specifying the same >>> thing, what am I missing? >> >> You're missing the fact that the default value of the permission= >> argument to view_config is None, so there's no way to tell that from an >> explicit None being passed. > > Hmm, I guess I would have chosen to leave the ugliness in the framework code > and replace the default None with a marker object to leave None free for > explicit use, rather than chosing an ugly explicit identifier ;-) > > Chris > > -- > Simplistix - Content Management, Batch Processing & Python Consulting > - http://www.simplistix.co.uk > > -- > You received this message because you are subscribed to the Google Groups > "pylons-devel" group. > To post to this group, send email to pylons-devel@googlegroups.com. > To unsubscribe from this group, send email to > pylons-devel+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/pylons-devel?hl=en. > > -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Fwd: Some thoughts about Pyramid
I'm not sure the OP is trolling, it comes across as frustration. While some of the things he points out are unfair and suggest unfamiliarity with certain aspects of the framework, there are some valid points in here as well: 1. The usage of traversal vs dispatch. It's unclear even to those quite familiar with Pyramid which to use for a given situation, and often I find myself yo-yoing between the two in the same project. Traversal is seen by some as "the" way to do Pyramid, with dispatch as an afterthought bolted on for Pylons compatibility, others still think the opposite especially with SQLAlchemy projects. This is very confusing for people who just want to get on and build something as it is so fundamental to the structure and design of your project. 2. Zopeisms, aka the ZCA, ZCML, zope.interface etc. This I see more of a marketing issue, but there is a valid concern here - the amount of conceptual overhead required to fully grok (pardon the pun) the framework is a problem. We often don't get to pick and choose the code we deal with as much of the time we have to deal with projects where we didn't have a hand in, so while I may prefer to ignore the ZCA for example in my own projects, I might well have to deal with it in someone else's. As with traversal/dispatch, the multi-paradigm approach may please nobody in the attempt to please everybody. 3. The "lots of tiny little components" problem. Actually this is mostly unfair. Pyramid reuses existing stuff like WebOb and Paste, but it's not alone in this - the OP mentions Flask for example, which depends on Werkzeug and Jinja2. In this Django is unusual in having an in-house (or, more unkindly, NIH) approach to everything. Outside of Python, Rails 3 for example has moved more in the direction Pyramid is at with the merge of Merb. It makes sense when possible and practical not to reinvent the wheel - the problem for the Django developers was a lack of decent wheels half a decade ago, I'm sure they would not have taken the same approach today. That said, one trend that is the matter of some concern is spinning off of parts of the pyramid core - such as ZCML and handlers - into separate packages. This may reduce cohesion in the framework and lead to the "tower of dependencies" problem that TurboGears 2, for example, suffered greatly from. Not an immediate issue - and I've contradicted myself re: ZCML being part of the framework - but still a cause of concern. The code quality issue is bunk. I've found the Pyramid code remarkably easy to navigate and understand - try looking at some of the Django ORM/admin code in comparison. More importantly - as code quality is subjective - is the staggering number of unit tests. You may or may not agree with the design principles, but you can rely on the code you use. I don't really have any recommendations here or solutions to offer. All in all I do like Pyramid and appreciate its strengths more as I build more projects with it. It does however suffer from two things in particular: 1. A marketing problem. Django is for "perfectionists with deadlines". Flask is the fun, easy microframework. What problem does Pyramid solve ? If you could summarize it in a single phrase, what would it be ? Pylons had a brilliant tagline - the "Hacker's Framework". One thing Pyramid really needs is success stories - "we used Pyramid to build [insert awesome site here]". 2. TIMTOWTDI. This is the bigger issue. It's a real roadblock for people starting a project in Pyramid, because they don't know whether to decide between traversal or dispatch, which form library, ZCML or ini, which template engine etc. It's also a potential issue for people taking on legacy Pyramid projects as they don't know what to expect. This is of course a strength as it gives you ultimate flexibility, but is also a source of confusion for newcomers. This situation will hopefully improve with templates built on top of Pyramid, but we're a long way from there yet. On 3 March 2011 17:31, Ben Bangert wrote: > On Mar 3, 2011, at 9:28 AM, Chris McDonough wrote: > >> Sounds like (s)he is blowing off a little steam. All of these points >> are addressed in >> http://docs.pylonsproject.org/projects/pyramid/1.0/designdefense.html . > > Indeed, my comment is awaiting moderation on the blog, I cited that URL as > well. :) > > Cheers, > Ben > > -- > You received this message because you are subscribed to the Google Groups > "pylons-devel" group. > To post to this group, send email to pylons-devel@googlegroups.com. > To unsubscribe from this group, send email to > pylons-devel+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/pylons-devel?hl=en. > > -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more opti
Re: CSRF protection and session factories
I've got a simplistic example here: http://packages.python.org/pyramid_simpleform/#csrf-validation On 9 March 2011 06:47, Chris Withers wrote: > Hi All, > > First, the important question: If I use > http://docs.pylonsproject.org/projects/pyramid/1.0/narr/sessions.html#using-the-default-session-factory > is the CSRF protection provided by > http://docs.pylonsproject.org/projects/pyramid/1.0/narr/sessions.html#preventing-cross-site-request-forgery-attacks > still secure and effective? > > The less important question: which tracker should I use for documentation > feature requests? > > It sounds like > http://docs.pylonsproject.org/projects/pyramid/1.0/narr/sessions.html#preventing-cross-site-request-forgery-attacks > is important, but without a worked example of the dangerous use case, and > that same example shown with session.get_csrf_token saving the day, I > struggle to follow it. > > Ideally, I guess I'd like an example with a template and a view, showing > what could happen and the workflow of usinging the CSRF protection stuff... > > cheers, > > Chris > > -- > Simplistix - Content Management, Batch Processing & Python Consulting > - http://www.simplistix.co.uk > > -- > You received this message because you are subscribed to the Google Groups > "pylons-devel" group. > To post to this group, send email to pylons-devel@googlegroups.com. > To unsubscribe from this group, send email to > pylons-devel+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/pylons-devel?hl=en. > > -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Pyramid 2 ideas
Migration to Python 3 aside (which has to happen, sooner or later) my concern here is that moving to Pyramid 2 so quickly is a bit premature given the paint is barely dry on Pyramid 1. Should we not wait until there are some actual projects built with Pyramid, and we get feedback from real world usage ? The danger is that this ends up like TG2 - a continually moving target moving from one dependency to the next, depending on what's flavour of the month, with a small core of developers continually making changes but leaving behind those who need a stable framework to work on. I would suggest that any major changes to Pyramid should depend on what users actually want or need. Yes, YAML may be better than INI. But it's not something that people using Pyramid have any issues with at this point. Ditto moving bits hither and thither from Paste. People coming to Pyramid are already having issues understanding differences between URL dispatch and traversal, authentication, testing etc. That's OK as Pyramid is a low-level framework and the higher-level stuff is still being built on top of it. But to add yet another slew of huge and fundamental changes will confuse and turn away people from Pyramid altogether. -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: WebHelpers conflict #63 and #59
Check if items is a sqlalchemy query would be an immediate fix.
This can seriously kill a web server so paginate should be considered
unusable with sqlalchemy until this is resolved.
On 20 Mar 2011 08:04, "Mike Orr" wrote:
I got this bug report in WebHelpers 1.3b1:
On Sat, Mar 19, 2011 at 9:36 PM, Bitbucket
wrote:
> New issue 63: Regression: paginate loads whole table when given SqlAlchemy
object
>
https://bitbucket.org/bbangert/webhelpers/issue/63/regression-paginate-loads-whole-table-when
>
> nh2 on Sun, 20 Mar 2011 05:36:05 +0100:
>
> Description:
> The changeset <> replaces
> {{{
> list(obj[slice])
> }}}
> by
> {{{
> list(obj)[slice]
> }}}
>
> which results in **all** rows being loaded on e.g.
Page(Session.query(MyModel),filter(...)).
>
> Therefore, webhelpers 1.3b1 completely kills performance.
>
> Responsible:
> bbangert
This was done in order to solve this big report:
> #59, by dennysonique:
> While using TurboGears 2 which relies on Webhelpers (sprox forms) I
> found this bug:
> Line 434 has an error causing:
> Module webhelpers.paginate:434 in init view
> self.items = list(self.collection[self.first_item-1:self.last_item])
> TypeError: unhashable type
> The solution to fix this is to change:
> -- self.items = list(self.collection[self.first_item-1:self.last_item])
> ++ self.items = list(self.collection)[self.first_item-1:self.last_item]
In other words, different users have contradictory desires. Should I
revert #59 and change it to WONTFIX, or is there a way to reconcile
these two? Or is this a reason to overhaul how paginate handles lists
vs queries overall? If so, what would be a better algorithm?
--
Mike Orr
--
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-devel?hl=en.
--
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-devel?hl=en.
