[Repoze-dev] repoze.bfg 1.0a6 release
repoze.bfg 1.0a5 was a bit of a browbag release. 1.0a6 has been released to fix the feature added in 1.0a5. The changelog is: 1.0a6 (2009-06-29) == Bug Fixes - - Use ``caller_package`` function instead of ``caller_module`` function within ``templating`` to avoid needing to name the caller module in resource overrides (actually match docs). - Make it possible to override templates stored directly in a module with templates in a subdirectory of the same module, stored directly within another module, or stored in a subdirectory of another module (actually match docs). ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] repoze.bfg nginx mod_wsgi
Anyone ever deploy repoze.bfg on nginx with mod_wsgi? Right now I'm just using proxy_pass to the paster serve for repoze.bfg, but it just seems more natural if this could be done using mod_wsgi. Any thoughts? Thanks, Nathan ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] repoze.bfg 1.0 final to be released by Monday July 6.
If nobody finds any showstopper bugs, repoze.bfg 1.0 will be released on or before Monday July 6. Speak now or forever hold your peace wrt to API issues; after 1.0 the existing APIs will be frozen. - C ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.bfg 1.0 final to be released by Monday July 6.
Chris McDonough wrote: If nobody finds any showstopper bugs, repoze.bfg 1.0 will be released on or before Monday July 6. Speak now or forever hold your peace wrt to API issues; after 1.0 the existing APIs will be frozen. No comments on the stability of the release at all, but it seems a bit curious to rush from alpha 6 to final, skipping any beta or rc phase. At least in Plone land, we know that people often don't test until rc's, so bugs are often found in rc releases. Of course, BFG is a lot more comprehensively unit tested. ;) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] bfg form generation
Hi Iain I am using formish with some success at the moment. You need the latest copy from github, rather than whats in PyPI and if you want to use the FileUpload widget you may need to build a custom FileResource handler (I am running on GAE so write temp files to the filesystem is not an option ) Its pretty simple and lightweight does both the form generation from schemas defined using schemaish and validation. (I looked at ToscaWidgets and found it was going to harder to shoehorn into GAE and it didn't have my requirements to be able to specify readonly widgets) Rgds Tim On Sun, Jun 28, 2009 at 3:47 AM, Iain Duncan iaindun...@telus.net wrote: what are folks using to make forms and validation schemas with bfg? I am a big fan of formencode, but not sure how best to use it in the bfg context. I'm curious whether one can use zope form generation easily with formencode? thanks iain ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] bfg form generation
Hi Iain, At the time I started using BFG, the options I had didn't quite attracted me that much so I decided to roll it on my own. My main goal was to quickly create form widgets from python code using a XML factory ( template independent ). Today it's called repoze.etreeform [1] and although it doesn't have a stable release yet, we use it for all our internal apps (BFG, z3 and plone) with some decent stability. It also ships with some helper functions that will allow one to easily create fieldsets, groups and wizards. Validation is provided by a simple function that will use Formencode validators against request data. The entire library is loose coupled so nothing is connected to anything. The Form class is just a mean to put widgets together, pass values and errors to them and also render it. I also wrote some documentation [2]. Let me know if you experiment with it and run into problems, Regards, Fernando [1] http://svn.repoze.org/repoze.etreeform/trunk/ [2] http://svn.repoze.org/repoze.etreeform/trunk/repoze/etreeform/README.txt On Sat, Jun 27, 2009 at 4:47 PM, Iain Duncaniaindun...@telus.net wrote: what are folks using to make forms and validation schemas with bfg? I am a big fan of formencode, but not sure how best to use it in the bfg context. I'm curious whether one can use zope form generation easily with formencode? thanks iain ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] traversal vs url dispatch for rest'ish applications
On 6/29/09 8:26 PM, Iain Duncan wrote:
I'm wondering what the conventional wisdom is for doing bfg apps to
handle crud operations with urls like
/pet - list pets
/pet/1 - view pet model, id 1
/pet/1/view
/pet/1/edit - edit pet model, id 1
Is this something that can be handled well with both traversal and url
dispatch? Are there any examples of it?
Let's imagine a view pets:
from webob import Response
def pets(context, request):
return Response ('OK')
when a URL comes in that is for a paricular pet:
from webob import Response
def pets(context, request):
if request.subpath:
petnum = request.subpath[0]
return Response('OK with petnum %s' % petnum)
return Response ('OK')
when a URL comes in with a particular action for a pet:
from webob import Response
from repoze.bfg.chameleon_zpt import render_template_to_response
def pets(context, request):
if len(request.subpath) == 1:
petnum = request.subpath[0]
return Response('OK with petnum %s' % petnum)
elif request.subpath == 2:
petnum, action = request.subpath
return render_request_to_response('%s.html' % action,
petnum = petnum)
return Response ('OK')
That's at least one way to handle it. Another way is to register a view for
edit.html against a Pet model.
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] traversal vs url dispatch for rest'ish applications
Let's imagine a view pets:
from webob import Response
def pets(context, request):
return Response ('OK')
when a URL comes in that is for a paricular pet:
from webob import Response
def pets(context, request):
if request.subpath:
petnum = request.subpath[0]
return Response('OK with petnum %s' % petnum)
return Response ('OK')
when a URL comes in with a particular action for a pet:
from webob import Response
from repoze.bfg.chameleon_zpt import render_template_to_response
def pets(context, request):
if len(request.subpath) == 1:
petnum = request.subpath[0]
return Response('OK with petnum %s' % petnum)
elif request.subpath == 2:
petnum, action = request.subpath
return render_request_to_response('%s.html' % action,
petnum = petnum)
return Response ('OK')
That's at least one way to handle it. Another way is to register a view for
edit.html against a Pet model.
Thanks Chris, the latter is what I was thinking of. So, another
question, can the *context* object be a *class* instead of an instance?
IE, can the class Pet be the context, such that a class level
__getitem__ returns the actual instance I'm after, and edit becomes the
view ( action ).
Iain
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
