Re: [Repoze-dev] new to bfg

[Chris McDonough]

Hi, Elliot,

Elliot Gage wrote:
> Good morning,
> 
>  
> 
> I’ve been looking at bfg for some time. I am primarily a dotnet 
> developer and have a few web projects I am looking at migrating over to 
> a python framework.
> 
> I am aware of a few frameworks already out there including django, 
> turbogears(2) and pylons. I really like the approach taken particularly 
> by pylons and now bfg.

Great, hopefully we can help.

> I have seen reference to reusing applications within other applications 
> as long as some rules are followed. For example, my apps will need a web 
> based file manager. Is it possible to create something like this that 
> can be used from within other bfg applications? Another example might be 
> an authentication and authorization framework (including edit screens 
> for users and permissions etc) that would be used by other apps I will 
> be building.

I think the reference you're talking about is here:



This reference isn't specifically talking about creating an "application" to be 
used within another "application"; instead it's referring to writing an 
application in such a way that other people can modify and extend it without 
changing its source code.  The reference is aimed at a person who wants to 
develop an application in such a way that an arbitrary consumer can download it 
  and change or extend it ("personalize" it) without needing to maintain a fork 
of the code.  In other words, people who want to develop a framework or an 
extensible application.

I think you may be overloading the word "application" in your description. 
Maybe what you really mean is that you want to develop reusable "components" 
that can be used within separate applications?  The component is not itself an 
application, it can just be used by one?

Or maybe you really do mean "application" and you want to compose a system out 
of many cooperating processes, each representing a different application, but 
appearing to the user as if it's one seamless web site?

Either thing is possible, but you may need to clarify.

- C
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] Jython Support on 1.2

[Chris McDonough]

OK... its possible that zope.configuration doesn't work for some reason under 
Jython; I don't know that anyone has tried it recently.  I may give it a shot 
myself over the next week or so out of curiosity.

In the meantime, however, you can disuse "declarative" (ZCML) style 
configuration, which will subvert zope.configuration entirely.  To do so, 
change the body of the "app" function in run.py of the generated sample app 
from this:

 def app(global_config, **settings):
 """ This function returns a ``repoze.bfg`` application object.  It
 is usually called by the PasteDeploy framework during ``paster
 serve``"""
 zcml_file = settings.get('configure_zcml', 'configure.zcml')
 config = Configurator(root_factory=get_root, settings=settings)
 config.begin()
 config.load_zcml(zcml_file)
 config.end()
 return config.make_wsgi_app()

to:

 def app(global_config, **settings):
 """ This function returns a ``repoze.bfg`` application object.  It
 is usually called by the PasteDeploy framework during ``paster
 serve``"""
 zcml_file = settings.get('configure_zcml', 'configure.zcml')
 config = Configurator(root_factory=get_root, settings=settings)
 config.begin()
 config.add_view(context=MyModel, view=my_view,
  renderer='templates/mytemplate.pt')
 config.add_static_view(name='static', path='templates/static')
 config.end()
 return config.make_wsgi_app()

Diaz, Eduardo wrote:
> Yes, it does
> 
> :P
> 
> On Mon, Jan 4, 2010 at 10:42 AM, Chris McDonough  <mailto:chr...@plope.com>> wrote:
> 
> Diaz, Eduardo wrote:
> 
> Ok, I think I know why this is happening,
> 
> the exception raises in the _validate method of the Orderable
> class, this is where it happends:
> 
> if self.max is not None and value > self.max:
>raise TooBig(value, self.max)
> 
> Here, max is a ValidatedProperty it has a __set___ method which
> gives it a value, the problem with jython seems to be that it
> isn't getting the value from the instance dictionary, so I came
> up a workaround,
> 
> I define the __get__ method in the ValidatedPropertyClass like this:
> 
> 
> def __get__(self, inst, owner):
>name, check = self._info
>return inst.__dict__[name]
> 
> And now the tests run ok:
> 
> jython setup.py test -q
> 
> running test
> running egg_info
> writing MyProject.egg-info/PKG-INFO
> writing entry points to MyProject.egg-info/entry_points.txt
> writing requirements to MyProject.egg-info/requires.txt
> writing top-level names to MyProject.egg-info/top_level.txt
> writing dependency_links to MyProject.egg-info/dependency_links.txt
> reading manifest file 'MyProject.egg-info/SOURCES.txt'
> writing manifest file 'MyProject.egg-info/SOURCES.txt'
> running build_ext
> .
> --
> Ran 1 test in 0.005s
> 
> OK
> 
> I know it is not elegant, and I'll submit a bug to the jython
> developers... but for now, I want to go on and there's another
> problem with running the project, and here it is:
> 
> paster serve MyProject.ini
> Traceback (most recent call last):
>  File "/home/iamedu/Tests/jython/sys/bin/paster", line 7, in
> 
>sys.exit(
>  File
> 
> "/home/iamedu/Tests/jython/sys/Lib/site-packages/PasteScript-1.7.3-py2.5.egg/paste/script/command.py",
> line 84, in run
>invoke(command, command_name, options, args[1:])
>  File
> 
> "/home/iamedu/Tests/jython/sys/Lib/site-packages/PasteScript-1.7.3-py2.5.egg/paste/script/command.py",
> line 123, in invoke
>exit_code = runner.run(args)
>  File
> 
> "/home/iamedu/Tests/jython/sys/Lib/site-packages/PasteScript-1.7.3-py2.5.egg/paste/script/command.py",
> line 123, in invoke
>exit_code = runner.run(args)
>  File
> 
> "/home/iamedu/Tests/jython/sys/Lib/site-packages/PasteScript-1.7.3-py2.5.egg/paste/script/command.py",
> line 218, in run
>result = self.command()
>  File
> 
> "/home/iamedu/Tests/jython/sys/L

Re: [Repoze-dev] Jython Support on 1.2

[Chris McDonough]

Diaz, Eduardo wrote:
> Ok, I think I know why this is happening,
> 
> the exception raises in the _validate method of the Orderable class, 
> this is where it happends:
> 
> if self.max is not None and value > self.max:
> raise TooBig(value, self.max)
> 
> Here, max is a ValidatedProperty it has a __set___ method which gives it 
> a value, the problem with jython seems to be that it isn't getting the 
> value from the instance dictionary, so I came up a workaround,
> 
> I define the __get__ method in the ValidatedPropertyClass like this:
> 
> 
> def __get__(self, inst, owner):
> name, check = self._info
> return inst.__dict__[name]
> 
> And now the tests run ok:
> 
> jython setup.py test -q
> 
> running test
> running egg_info
> writing MyProject.egg-info/PKG-INFO
> writing entry points to MyProject.egg-info/entry_points.txt
> writing requirements to MyProject.egg-info/requires.txt
> writing top-level names to MyProject.egg-info/top_level.txt
> writing dependency_links to MyProject.egg-info/dependency_links.txt
> reading manifest file 'MyProject.egg-info/SOURCES.txt'
> writing manifest file 'MyProject.egg-info/SOURCES.txt'
> running build_ext
> .
> --
> Ran 1 test in 0.005s
> 
> OK
> 
> I know it is not elegant, and I'll submit a bug to the jython 
> developers... but for now, I want to go on and there's another problem 
> with running the project, and here it is:
> 
> paster serve MyProject.ini
> Traceback (most recent call last):
>   File "/home/iamedu/Tests/jython/sys/bin/paster", line 7, in 
> sys.exit(
>   File 
> "/home/iamedu/Tests/jython/sys/Lib/site-packages/PasteScript-1.7.3-py2.5.egg/paste/script/command.py",
>  
> line 84, in run
> invoke(command, command_name, options, args[1:])
>   File 
> "/home/iamedu/Tests/jython/sys/Lib/site-packages/PasteScript-1.7.3-py2.5.egg/paste/script/command.py",
>  
> line 123, in invoke
> exit_code = runner.run(args)
>   File 
> "/home/iamedu/Tests/jython/sys/Lib/site-packages/PasteScript-1.7.3-py2.5.egg/paste/script/command.py",
>  
> line 123, in invoke
> exit_code = runner.run(args)
>   File 
> "/home/iamedu/Tests/jython/sys/Lib/site-packages/PasteScript-1.7.3-py2.5.egg/paste/script/command.py",
>  
> line 218, in run
> result = self.command()
>   File 
> "/home/iamedu/Tests/jython/sys/Lib/site-packages/PasteScript-1.7.3-py2.5.egg/paste/script/serve.py",
>  
> line 275, in command
> app = self.loadapp(app_spec, name=app_name,
>   File 
> "/home/iamedu/Tests/jython/sys/Lib/site-packages/PasteScript-1.7.3-py2.5.egg/paste/script/serve.py",
>  
> line 311, in loadapp
> return loadapp(
>   File 
> "/home/iamedu/Tests/jython/sys/Lib/site-packages/PasteDeploy-1.3.3-py2.5.egg/paste/deploy/loadwsgi.py",
>  
> line 204, in loadapp
> return loadobj(APP, uri, name=name, **kw)
>   File 
> "/home/iamedu/Tests/jython/sys/Lib/site-packages/PasteDeploy-1.3.3-py2.5.egg/paste/deploy/loadwsgi.py",
>  
> line 225, in loadobj
> return context.create()
>   File 
> "/home/iamedu/Tests/jython/sys/Lib/site-packages/PasteDeploy-1.3.3-py2.5.egg/paste/deploy/loadwsgi.py",
>  
> line 625, in create
> return self.object_type.invoke(self)
>   File 
> "/home/iamedu/Tests/jython/sys/Lib/site-packages/PasteDeploy-1.3.3-py2.5.egg/paste/deploy/loadwsgi.py",
>  
> line 110, in invoke
> return fix_call(context.object, context.global_conf, 
> **context.local_conf)
>   File 
> "/home/iamedu/Tests/jython/sys/Lib/site-packages/PasteDeploy-1.3.3-py2.5.egg/paste/deploy/util/fixtypeerror.py",
>  
> line 57, in fix_call
> val = callable(*args, **kw)
>   File 
> "/home/iamedu/Tests/jython/sys/Lib/site-packages/PasteDeploy-1.3.3-py2.5.egg/paste/deploy/util/fixtypeerror.py",
>  
> line 57, in fix_call
> val = callable(*args, **kw)
>   File "/home/iamedu/Tests/jython/MyProject/myproject/run.py", line 11, 
> in app
> config.load_zcml(zcml_file)
>   File 
> "/home/iamedu/Tests/jython/sys/Lib/site-packages/repoze.bfg-1.2a10-py2.5.egg/repoze/bfg/configuration.py",
>  
> line 424, in load_zcml
> xmlconfig.file(filename, package, execute=True)
>   File 
> "/home/iamedu/Tests/jython/sys/Lib/site-packages/zope.configuration-3.6.0-py2.5.egg/zope/configuration/xmlconfig.py",
>  
> line 647, in file
> include(context, name, package)
>   File 
> "/home/iamedu/Tests/jython/sys/Lib/site-packages/zope.configuration-3.6.0-py2.5.egg/zope/configuration/xmlconfig.py",
>  
> line 546, in include
> processxmlfile(f, context)
>   File 
> "/home/iamedu/Tests/jython/sys/Lib/site-packages/zope.configuration-3.6.0-py2.5.egg/zope/configuration/xmlconfig.py",
>  
> line 378, in processxmlfile
> parser.parse(src)
>   File 
> "/home/iamedu/Tests/jython/sys/Lib/site-packages/zope.configuration-3.6.0-py2.5.egg/zope/configuration/xmlconfig.py",
>  
> line 378, in processxmlfile
> parser.parse(src)
>   File 
> "/home/iamedu/Tools/jython2.5.1/Lib/xml/sax/drivers2/drv_javasax.py", 
> line 141

[Repoze-dev] repoze.bfg 1.2a10 released...

[Chris McDonough]

repoze.bfg 1.2a10 has been released.

The documentation at http://docs.repoze.org/bfg/1.2 has been updated.

It is installable via:

   easy_install -i http://dist.repoze.org/bfg/1.2/simple repoze.bfg

Or via PyPI.

The changelog follows.

1.2a10 (2010-01-04)
===

Features


- The ``Configurator.add_view`` method now accepts an argument named
   ``context``.  This is an alias for the older argument named
   ``for_``; it is preferred over ``for_``, but ``for_`` will continue
   to be supported "forever".

- The ``view`` ZCML directive now accepts an attribute named
   ``context``.  This is an alias for the older attribute named
   ``for``; it is preferred over ``for``, but ``for`` will continue to
   be supported "forever".

- The ``Configurator.add_route`` method now accepts an argument named
   ``view_context``.  This is an alias for the older argument named
   ``view_for``; it is preferred over ``view_for``, but ``view_for``
   will continue to be supported "forever".

- The ``route`` ZCML directive now accepts an attribute named
   ``view_context``.  This is an alias for the older attribute named
   ``view_for``; it is preferred over ``view_for``, but ``view_for``
   will continue to be supported "forever".

Documentation and Paster Templates
--

- LaTeX rendering tweaks.

- All uses of the ``Configurator.add_view`` method that used its
   ``for_`` argument now use the ``context`` argument instead.

- All uses of the ``Configurator.add_route`` method that used its
   ``view_for`` argument now use the ``view_context`` argument instead.

- All uses of the ``view`` ZCML directive that used its ``for``
   attribute now use the ``context`` attribute instead.

- All uses of the ``route`` ZCML directive that used its ``view_for``
   attribute now use the ``view_context`` attribute instead.

- Add a (minimal) tutorial dealing with use of ``repoze.catalog`` in a
   ``repoze.bfg`` application.

Documentation Licensing
---

- Loosen the documentation licensing to allow derivative works: it is
   now offered under the `Creative Commons
   Attribution-Noncommercial-Share Alike 3.0 United States License
   `_.  This is
   only a documentation licensing change; the ``repoze.bfg`` software
   continues to be offered under the Repoze Public License at
   http://repoze.org/license.html (BSD-like).
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] [bfg 1.29a] render_template_to_response returning the view class?

[Chris McDonough]

I'm not sure which version of bfg you're contrasting this against, but if the 
view is a class, constructing the class just constructs the class.  It's not 
until the class' __call__ is invoked that a response is potentially generated. 
  If a previous BFG version worked differently, it was a bug.

In general, when you're testing code in BFG 1.1+, test the code as it appears 
in your editor buffer without taking any bfg_view decorators into account. 
bfg_view decorators don't actually influence the behavior of the code in 1.1+, 
so you need to test the code "literally".  In the case of a class-based view, 
this means constructing the class with a context and a request, then invoking 
its __call__ method.

- C


Andreas Jung wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Running the zopyx.smartprintng.server tests with Repoze 1.2a9:
> 
> Calling the index() view no longer returns a response object with
> a status attribute:
> 
> 
> /data/develop/repository/svn.zope.org/zopyx.smartprintng.server/trunk/zopyx/smartprintng/server/tests.py(96)test_index()
> - -> self.assertEqual(result.status, '200 OK')
> (Pdb) list
>  91  def test_index(self):
>  92  from zopyx.smartprintng.server.views import index
>  93  context = Server()
>  94  request = testing.DummyRequest()
>  95  result = index(context, request)
>  96  ->self.assertEqual(result.status, '200 OK')
>  97  body = result.app_iter[0]
>  98  self.assertEqual(len(result.headerlist), 2)
>  99  self.assertEqual(result.headerlist[0],
> 100   ('Content-Type', 'text/html;
> charset=UTF-8'))
> 101  self.assertEqual(result.headerlist[1], ('Content-Length',
> (Pdb) print result
> 
> 
> So 'result' is now the view class itself?
> 
> 
>  36 @bfg_view(for_=Server, request_method='GET', permission='read')
>  37 class index(object):
>  38 """ The default view providing some system information """
>  39
>  40 def __init__(self, context, request):
>  41 self.context = context
>  42 self.request = request
>  43
>  44 def __call__(self):
>  45 converters = self.context.availableConverters()
>  46 version =
> pkg_resources.require('zopyx.smartprintng.server')[0].version·
>  47 return render_template_to_response('templates/index.pt',
>  48context=self.context,
>  49converters=converters,
>  50request=self.request,
>  51version=version,
>  52   
> project='zopyx.smartprintng.server')
> 
> Andreas
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAks/f9gACgkQCJIWIbr9KYxEpACfWsrY42pivfgSJJX5d0GtL8fC
> dWgAoJu2McNlFv7BlTmDC4hz9oWttwTA
> =Cibm
> -END PGP SIGNATURE-
> 
> 
> ___
> 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 documentation stuff

[Chris McDonough]

Ricardo Mendes wrote:
> Hello,
> 
> I've found minor errors in the following pages
> 
> URL dispatch, page 66
> -  foo/abc/def -> {’baz’:u’abc’, ’bar’:u’*2*’}
> + foo/abc/def -> {’baz’:u’abc’, ’bar’:u’*def*’}
> 
> URL dispatch, page 67
> -  foo/abc/def/a/b/c -> {’baz’:abc, ’bar’:*2*, ’traverse’:(’a’, ’b’, ’c’)}
> + foo/abc/def/a/b/c -> {’baz’:abc, ’bar’:*def*, ’traverse’:(’a’, ’b’, ’c’)}
> 
> peace,
> Ricardo Mendes

Thank you!  Fixed in SVN...

- C


> 
> 2009/12/27 Chris McDonough mailto:chr...@plope.com>>
> 
> The most recent release (1.2a9) of repoze.bfg contains a documentation
> licensing modification.
> 
> Previous releases of the documentation stated no explicit license.
>  The most
> recent release of repoze.bfg asserts that the documentation has the
> Creative
> Commons Attribution-Noncommercial-No Derivative Works 3.0 United
> States License
> as described by http://creativecommons.org/licenses/by-nc-nd/3.0/us/ .
> 
> This licensing modification has no impact on the BFG *software*
> itself; the
> software continues to be offered under the BSD-like "Repoze Public
> License" at
> http://repoze.org/license.html .
> 
> Why the change?  Mostly it's because I'm going to publish the
> documentation in
> dead-tree form, and the CC license is a friendlier license for this
> task.
> 
> I've prepared a PDF of the documentation from the latest release
> BFG, which is
> roughly what will be available in dead-tree form at
> http://static.repoze.org/bfg-1.2a9.pdf .
> 
> It would be extremely useful to have some technical review of the
> PDF before I
> create the first publishing batch.  Technical review consists of
> reading and
> reviewing the entire PDF and providing feedback in email form on
> comprehensibility, sentence structure, omissions, errors, and rendering
> improvement suggestions.  If anyone would be willing to volunteer
> for such a
> task, I'd be happy to send them a copy of the first printed book
> edition.
> 
> - C
> ___
> Repoze-dev mailing list
> Repoze-dev@lists.repoze.org <mailto: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

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] repoze.vhm and repoze.zope2 odd behavior

[Chris McDonough]

Martin Aspeli wrote:
>>
>> I assumed it was just acquisition trickery. Looking more closely,
>> z2bob.py uses the repoze.vhm.virtual_root via the getVirtualRoot in the
>> repoze.vhm.utils package to get the virtual root and it seems to create
>> the correct path for traversal regardless of the issue. Just some small
>> things are off, like content actions and I just noticed that related
>> items don't show also.
> 
> Well, if ACTUAL_URL is wrong, then that's a serious bug.

TBH, I never really understood what ACTUAL_URL was supposed to do.  Limi added 
it at some point, but I'm pretty sure he never really understood what it was 
supposed to do either. ;-)  Or at least he'll deny knowing anything about it.

>> If PATH_INFO is how it decides on what object to traverse to, then we
>> should be explicitly setting it in the xheader filter like is done in
>> the xpath filter.
> 
> I think that'd be safer, but you  may want to ask Chris what he thinks 
> as well. Looking at how plain Zope 2 behaves, PATH_INFO is meant to 
> contain the full path that Zope is traversing to, virtual hosting or 
> not. So maybe, by setting PATH_INFO correctly, we can avoid the 
> interplay between repoze.zope2 and repoze.vhm entirely, or at least 
> reduce it. I guess setting ACTUAL_URL is still a repoze.zope2 
> responsibility, but beyond that, trying to get bits of information from 
> repoze.vhm creates a slightly weird dependency across two packages.

I'm going to defer to the professionals here; I don't use this package much 
anymore, so you'll need to use some judgment and check in a fix that is more 
correct I think.

- C

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] BFG documentation stuff

[Chris McDonough]

The most recent release (1.2a9) of repoze.bfg contains a documentation 
licensing modification.

Previous releases of the documentation stated no explicit license.  The most 
recent release of repoze.bfg asserts that the documentation has the Creative 
Commons Attribution-Noncommercial-No Derivative Works 3.0 United States License 
as described by http://creativecommons.org/licenses/by-nc-nd/3.0/us/ .

This licensing modification has no impact on the BFG *software* itself; the 
software continues to be offered under the BSD-like "Repoze Public License" at 
http://repoze.org/license.html .

Why the change?  Mostly it's because I'm going to publish the documentation in 
dead-tree form, and the CC license is a friendlier license for this task.

I've prepared a PDF of the documentation from the latest release BFG, which is 
roughly what will be available in dead-tree form at 
http://static.repoze.org/bfg-1.2a9.pdf .

It would be extremely useful to have some technical review of the PDF before I 
create the first publishing batch.  Technical review consists of reading and 
reviewing the entire PDF and providing feedback in email form on 
comprehensibility, sentence structure, omissions, errors, and rendering 
improvement suggestions.  If anyone would be willing to volunteer for such a 
task, I'd be happy to send them a copy of the first printed book edition.

- C
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] repoze.bfg 1.2a9 released

[Chris McDonough]

repoze.bfg 1.2a9 has been released.

Install it via:

easy_install -i http://dist.repoze.org/bfg/1.2/simple repoze.bfg

Or via PyPI.

The documentation at http://docs.repoze.org/docs/bfg/1.2 have been updated.

This is a release without any software changes; just documentation changes. 
The changelog follows:

1.2a9 (2009-12-27)
==

Documentation Licensing
---

- The *documentation* (the result of ``make ``
   within the ``docs`` directory) in this release is now offered under
   the Creative Commons Attribution-Noncommercial-No Derivative Works
   3.0 United States License as described by
   http://creativecommons.org/licenses/by-nc-nd/3.0/us/ .  This is only
   a licensing change for the documentation; the ``repoze.bfg``
   software continues to be offered under the Repoze Public License
   at http://repoze.org/license.html (BSD-like).

Documentation
-

- Added manual index entries to generated index.

- Document the previously existing (but non-API)
   ``repoze.bfg.configuration.Configurator.setup_registry`` method as
   an official API of a ``Configurator``.

- Fix syntax errors in various documentation code blocks.

- Created new top-level documentation section: "ZCML Directives".
   This section contains detailed ZCML directive information, some of
   which was removed from various narrative chapters.

- The LaTeX rendering of the documentation has been improved.

- Added a "Fore-Matter" section with author, copyright, and licensing
   information.

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] repoze.bfg 1.2a8 released

[Chris McDonough]

repoze.bfg 1.2a8 has been released.

Install it via:

easy_install -i http://dist.repoze.org/bfg/1.2/simple repoze.bfg

Or via PyPI.

The docs at http://docs.repoze.org/bfg/1.2 have been updated.

The changelog follows:

1.2a8 (2009-12-24)
==

Features


- Add a ``**kw`` arg to the ``Configurator.add_settings`` API.

- Add ``hook_zca`` and ``unhook_zca`` methods to the ``Configurator``
   API.

- The ``repoze.bfg.testing.setUp`` method now returns a
   ``Configurator`` instance which can be used to do further
   configuration during unit tests.

Bug Fixes
-

- The ``json`` renderer failed to set the response content type to
   ``application/json``.  It now does, by setting
   ``request.response_content_type`` unless this attribute is already
   set.

- The ``string`` renderer failed to set the response content type to
   ``text/plain``.  It now does, by setting
   ``request.response_content_type`` unless this attribute is already
   set.

Documentation
-

- General documentation improvements by using better Sphinx roles such
   as "class", "func", "meth", and so on.  This means that there are
   many more hyperlinks pointing to API documentation for API
   definitions in all narrative, tutorial, and API documentation
   elements.

- Added a description of imperative configuration in various places
   which only described ZCML configuration.

- A syntactical refreshing of various tutorials.

- Added the ``repoze.bfg.authentication``,
   ``repoze.bfg.authorization``, and ``repoze.bfg.interfaces`` modules
   to API documentation.

Deprecations


- The ``repoze.bfg.testing.registerRoutesMapper`` API (added in an
   early 1.2 alpha) was deprecated.  Its import now generates a
   deprecation warning.
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] repoze.bfg 1.2a7 released

[Chris McDonough]

repoze.bfg 1.2a7 has been released

Install via:


   easy_install -U http://dist.repoze.org/bfg/1.2/simple repoze.bfg

The docs at http://docs.repoze.org/bfg/1.2 have been updated.

The changelog follows:

1.2a7 (2009-12-20)
==

Features


- Add four new testing-related APIs to the
   ``repoze.bfg.configuration.Configurator`` class:
   ``testing_securitypolicy``, ``testing_models``,
   ``testing_add_subscriber``, and ``testing_add_template``.  These
   were added in order to provide more direct access to the
   functionality of the ``repoze.bfg.testing`` APIs named
   ``registerDummySecurityPolicy``, ``registerModels``,
   ``registerEventListener``, and ``registerTemplateRenderer`` when a
   configurator is used.  The ``testing`` APIs named are nominally
   deprecated (although they will likely remain around "forever", as
   they are in heavy use in the wild).

- Add a new API to the ``repoze.bfg.configuration.Configurator``
   class: ``add_settings``.  This API can be used to add "settings"
   (information returned within via the
   ``repoze.bfg.settings.get_settings`` API) after the configurator has
   been initially set up.  This is most useful for testing purposes.

- Add a ``custom_predicates`` argument to the ``Configurator``
   ``add_view`` method, the ``bfg_view`` decorator and the attribute
   list of the ZCML ``view`` directive.  If ``custom_predicates`` is
   specified, it must be a sequence of predicate callables (a predicate
   callable accepts two arguments: ``context`` and ``request`` and
   returns ``True`` or ``False``).  The associated view callable will
   only be invoked if all custom predicates return ``True``.  Use one
   or more custom predicates when no existing predefined predicate is
   useful.  Predefined and custom predicates can be mixed freely.

- Add a ``custom_predicates`` argument to the ``Configurator``
   ``add_route`` and the attribute list of the ZCML ``route``
   directive.  If ``custom_predicates`` is specified, it must be a
   sequence of predicate callables (a predicate callable accepts two
   arguments: ``context`` and ``request`` and returns ``True`` or
   ``False``).  The associated route will match will only be invoked if
   all custom predicates return ``True``, else route matching
   continues.  Note that the value ``context`` will always be ``None``
   when passed to a custom route predicate.  Use one or more custom
   predicates when no existing predefined predicate is useful.
   Predefined and custom predicates can be mixed freely.

Internal


- Remove the ``repoze.bfg.testing.registerTraverser`` function.  This
   function was never an API.

Documenation


- Doc-deprecated most helper functions in the ``repoze.bfg.testing``
   module.  These helper functions likely won't be removed any time
   soon, nor will they generate a warning any time soon, due to their
   heavy use in the wild, but equivalent behavior exists in methods of
   a Configurator.

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] IRC Questions

[Chris McDonough]

Steve Schmechel wrote:
> Sorry, if some of these questions are inane, but I am try to 
> get proficient at participating in IRC again after many years 
> away.  (There is apparently more activity on the Repoze IRC channel
> than on this list, so I guess I better learn if I want to participate.)
> 
> General searches for IRC related info tend to return things from people
> who spend maybe too much of their life "chatting".  So, I thought I 
> would ask other developers who use IRC as a communication tool more
> than a social recreation.
> 
> I noticed that the channel archive at 
> http://irclog.turbogears.org/archive/freenode/repoze 
> only provides the last 100 messages.  Since I didn't stay connected 
> to the channel yesterday, I missed a possible response to someone else's
> question about the status of Chameleon and Google App Engine.
> By the time I looked at the archive the window had rolled past so I
> don't know if anyone answered.  (I know I could ask again; just trying
> to get things configured so that this doesn't happen often.)

At http://irclog.turbogears.org/archive/freenode/repoze# if you click on 
"Browse Archive", then click the forward arrow that shows up, you will see the 
entire day's traffic.  Unfortunately the month/day/year dropdowns don't work, 
but you can change the URL to see previous days.

> Judging from the channel name list, most people here are connected to
> freenode at all times.
> 
> So, the ChatZilla Firefox plugin I started with is probably is not 
> going to serve me well.  I tried toying with Pidgin and now irssi.
> What are most people here using as a client?

I use a Mac, so I use Colloquy myself.  When I used Linux, I used XChat.  But 
anything works.

> Is there some other way to use the channel archive or a different 
> archive?  Hopefully, there will always be a live (awake) person
> to talk to, but with different timezones and such and network 
> connections that might go out, I hate to end up asking "Did someone
> answer my question?".  (Or repost the same question to the mailing
> list because I missed the answer.)

Hopefully the archive trick above helps.

> I apologize if there is some simple technical solution to all this
> that I missed (magic IRC proxy server or something), but I do 
> appreciate a quick point in the right direction.



- C

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] repoze.bfg 1.2a6 released

[Chris McDonough]

repoze.bfg 1.2a6 has been released

Install via:

   easy_install -i http://dist.repoze.org/bfg/1.2/simple repoze.bfg

Or via PyPI.

The docs at http://docs.repoze.org/bfg/1.2 have been updated.

The changelog follows:

1.2a6 (2009-12-18)
==

Features


- The ``Configurator`` object now has two new methods: ``begin`` and
   ``end``.  The ``begin`` method is meant to be called before any
   "configuration" begins (e.g. before ``add_view``, et. al are
   called).  The ``end`` method is meant to be called after all
   "configuration" is complete.

   Previously, before there was imperative configuration at all (1.1
   and prior), configuration begin and end was invariably implied by
   the process of loading a ZCML file.  When a ZCML load happened, the
   threadlocal data structure containing the request and registry was
   modified before the load, and torn down after the load, making sure
   that all framework code that needed ``get_current_registry`` for the
   duration of the ZCML load was satisfied.

   Some API methods called during imperative configuration, (such as
   ``Configurator.add_view`` when a renderer is involved) end up for
   historical reasons calling ``get_current_registry``.  However, in
   1.2a5 and below, the Configurator supplied no functionality that
   allowed people to make sure that ``get_current_registry`` returned
   the registry implied by the configurator being used.  ``begin`` now
   serves this purpose.  Inversely, ``end`` pops the thread local
   stack, undoing the actions of ``begin``.

   We make this boundary explicit to reduce the potential for confusion
   when the configurator is used in different circumstances (e.g. in
   unit tests and app code vs. just in initial app setup).

   Existing code written for 1.2a1-1.2a5 which does not call ``begin``
   or ``end`` continues to work in the same manner it did before.  It
   is however suggested that this code be changed to call ``begin`` and
   ``end`` to reduce the potential for confusion in the future.

- All ``paster`` templates which generate an application skeleton now
   make use of the new ``begin`` and ``end`` methods of the
   Configurator they use in their respective copies of ``run.py`` and
   ``tests.py``.

Documentation
-

- All documentation that makes use of a ``Configurator`` object to do
   application setup and test setup now makes use of the new ``begin``
   and ``end`` methods of the configurator.

Bug Fixes
-

- When a ``repoze.bfg.exceptions.NotFound`` or
   ``repoze.bfg.exceptions.Forbidden`` *class* (as opposed to instance)
   was raised as an exception within a root factory (or route root
   factory), the exception would not be caught properly by the
   ``repoze.bfg.`` Router and it would propagate to up the call stack,
   as opposed to rendering the not found view or the forbidden view as
   would have been expected.

- When Chameleon page or text templates used as renderers were added
   imperatively (via ``Configurator.add_view`` or some derivative),
   they too-eagerly attempted to look up the ``reload_templates``
   setting via ``get_settings``, meaning they were always registered in
   non-auto-reload-mode (the default).  Each now waits until its
   respective ``template`` attribute is accessed to look up the value.

- When a route with the same name as a previously registered route was
   added, the old route was not removed from the mapper's routelist.
   Symptom: the old registered route would be used (and possibly
   matched) during route lookup when it should not have had a chance to
   ever be used.

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] repoze.bfg 1.2a5 released

[Chris McDonough]

repoze.bfg 1.2a5 has been released.

Install via:

easy_install -i http://dist.repoze.org/bfg/1.2/simple repoze.bfg

Or via PyPI.

The changelog follows.

1.2a5 (2009-12-10)
==

Features


- When the ``repoze.bfg.exceptions.NotFound`` or
   ``repoze.bfg.exceptions.Forbidden`` error is raised from within a
   custom root factory or the ``factory`` of a route, the appropriate
   response is now sent to the requesting user agent (the result of the
   notfound view or the forbidden view, respectively).  When these
   errors are raised from within a root factory, the ``context`` passed
   to the notfound or forbidden view will be ``None``.  Also, the
   request will not be decorated with ``view_name``, ``subpath``,
   ``context``, etc. as would normally be the case if traversal had
   been allowed to take place.

Internals
-

- The exception class representing the error raised by various methods
   of a ``Configurator`` is now importable as
   ``repoze.bfg.exceptions.ConfigurationError``.

Documentation
-

- General documentation freshening which takes imperative
   configuration into account in more places and uses glossary
   references more liberally.

- Remove explanation of changing the request type in a new request
   event subscriber, as other predicates are now usually an easier way
   to get this done.

- Added "Thread Locals" narrative chapter to documentation, and added
   a API chapter documenting the ``repoze.bfg.threadlocals`` module.

- Added a "Special Exceptions" section to the "Views" narrative
   documentation chapter explaining the effect of raising
   ``repoze.bfg.exceptions.NotFound`` and
   ``repoze.bfg.exceptions.Forbidden`` from within view code.

Dependencies


- A new dependency on the ``twill`` package was added to the
   ``setup.py`` ``tests_require`` argument (Twill will only be
   downloaded when ``repoze.bfg`` ``setup.py test`` or ``setup.py
   nosetests`` is invoked).

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] repoze.bfg 1.1.5 and 1.2a4 released

[Chris McDonough]

repoze.bfg 1.1.5 and 1.2a4 have been released.

Install 1.2a4 via:

easy_install -i http://dist.repoze.org/bfg/1.2/simple repoze.bfg


Install 1.1.5 via:

easy_install -i http://dist.repoze.org/bfg/1.1/simple repoze.bfg

1.1.5 is a backport bugfix release.  1.2a4 is a bigfix and minor feature 
release.

Change logs follow.

1.1.5 (2009-12-07)
==

- Operation on GAE was broken, presumably because the
   ``repoze.bfg.includes`` ``configure.zcml`` file began to attempt to
   import the ``repoze.bfg.chameleon_zpt`` and
   ``repoze.bfg.chameleon_text`` modules, and these cannot be used on
   non-CPython platforms.  It now tolerates startup time import
   failures for these modules, and only raise an import error when a
   template from one of these packages is actually used (backport from
   trunk).


1.2a4 (2009-12-07)
==

Features


- ``repoze.bfg.testing.DummyModel`` now accepts a new constructor
   keyword argument: ``__provides__``.  If this constructor argument is
   provided, it should be an interface or a tuple of interfaces.  The
   resulting model will then provide these interfaces (they will be
   attached to the constructed model via
   ``zope.interface.alsoProvides``).

Bug Fixes
-

- Operation on GAE was broken, presumably because the
   ``repoze.bfg.configuration`` module began to attempt to import the
   ``repoze.bfg.chameleon_zpt`` and ``repoze.bfg.chameleon_text``
   modules, and these cannot be used on non-CPython platforms.  It now
   tolerates startup time import failures for these modules, and only
   raise an import error when a template from one of these packages is
   actually used.

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue112] Only getting registry over get_current_registry() in view (bfg 1.2X)

[Chris McDonough]

Chris McDonough  added the comment:

This is by design.  In 1.2, if you don't use "repoze.bfg.router.make_app" to 
create your BFG 
WSGI application (instead using a Configurator and config.make_wsgi_app) and 
you need to 
use the ZCA "thread local API" (getUtiility, getAdapter, getSiteManager, etc), 
you must put this 
code somewhere in your run.py:

from zope.component import getSiteManager
from repoze.bfg import get_current_registry
getSiteManager.sethook(get_current_registry)

--
status: unread -> resolved

__
Repoze Bugs 
<http://bugs.repoze.org/issue112>
__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] Running repoze.bfg on Google’s A pp Engine

[Chris McDonough]

Hi Darryl,

I've made changes to the trunk:

   http://svn.repoze.org/repoze.bfg/trunk/CHANGES.txt

And to the 1.1 branch:

   http://svn.repoze.org/repoze.bfg/branches/1.1/CHANGES.txt

That hopefully will solve this issues.

Thanks again!

- C



Darryl Cousins wrote:
> Hi Chris
> 
> On Thu, Dec 3, 2009 at 8:11 PM, Chris McDonough  wrote:
>> Darryl Cousins wrote:
>>> Hi All,
>>>
>>> I found that the recipe [1] to run repoze.bfg on gae **almost** works.
>> Thanks for the analysis!
>>
>> I think the best solution would be to make all imports of Chameleon
>> conditional.This actually *used* to be the case; something must have
>> broken it since 1.0 (the last time I tested that tutorial).
>>
>> Can you provide the traceback that is emitted when "the wrong thing"
>> happens?
> 
> Yes. App starts ok, on first request the following traceback:
> 
> Mac OS X 10.5.8 - using python2.5 mac ports
> 
> Hope that helps, best,
> Darryl
> 
> darrylcous...@lyrrad:~/projects/placerama $ dev_appserver.py app
> INFO 2009-12-03 07:53:00,113 appengine_rpc.py:157] Server:
> appengine.google.com
> WARNING  2009-12-03 07:53:00,118 datastore_file_stub.py:443] Could not
> read datastore data from
> /var/folders/I+/I+TKAJhUHkGqvthbu07a-U+++TI/-Tmp-/dev_appserver.datastore
> INFO 2009-12-03 07:53:00,162 dev_appserver_main.py:478] Running
> application placerama on port 8080: http://localhost:8080
> WARNING  2009-12-03 07:53:06,429 py_zipimport.py:103] Can't open
> zipfile 
> /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/setuptools-0.6c11-py2.5.egg:
> IOError: [Errno 13] file not accessible:
> '/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/setuptools-0.6c11-py2.5.egg'
> ERROR2009-12-03 07:53:07,652 dev_appserver.py:3009] Exception
> encountered handling request
> Traceback (most recent call last):
>  File 
> "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver.py",
> line 2978, in _HandleRequest
>base_env_dict=env_dict)
>  File 
> "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver.py",
> line 411, in Dispatch
>base_env_dict=base_env_dict)
>  File 
> "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver.py",
> line 2244, in Dispatch
>self._module_dict)
>  File 
> "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver.py",
> line 2162, in ExecuteCGI
>reset_modules = exec_script(handler_path, cgi_path, hook)
>  File 
> "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver.py",
> line 2058, in ExecuteOrImportScript
>exec module_code in script_module.__dict__
>  File "/Users/darrylcousins/projects/placerama/app/runner.py", line
> 56, in 
>application = application(*(config_args or ()), **(config_kwargs or {}))
>  File "/Users/darrylcousins/projects/placerama/app/placerama/run.py",
> line 10, in app
>return make_app(get_root, placerama, options=kw)
>  File 
> "/Users/darrylcousins/projects/placerama/app/lib/python/repoze.bfg-1.1.3-py2.5.egg/repoze/bfg/router.py",
> line 183, in make_app
>settings)
>  File 
> "/Users/darrylcousins/projects/placerama/app/lib/python/repoze.bfg-1.1.3-py2.5.egg/repoze/bfg/configuration.py",
> line 107, in make_registry
>zcml_configure(filename, package)
>  File 
> "/Users/darrylcousins/projects/placerama/app/lib/python/repoze.bfg-1.1.3-py2.5.egg/repoze/bfg/configuration.py",
> line 147, in zcml_configure
>xmlconfig.include(context, name, package)
>  File 
> "/Users/darrylcousins/projects/placerama/app/lib/python/zope.configuration-3.6.0-py2.5.egg/zope/configuration/xmlconfig.py",
> line 546, in include
>processxmlfile(f, context)
>  File 
> "/Users/darrylcousins/projects/placerama/app/lib/python/zope.configuration-3.6.0-py2.5.egg/zope/configuration/xmlconfig.py",
> line 378, in processxmlfile
>parser.parse(src)
>  File 
> "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/xml/sax/expatreader.py",
> line 107, in parse

Re: [Repoze-dev] Running repoze.bfg on Google’s A pp Engine

[Chris McDonough]

Darryl Cousins wrote:
> Hi All,
> 
> I found that the recipe [1] to run repoze.bfg on gae **almost** works.

Thanks for the analysis!

I think the best solution would be to make all imports of Chameleon 
conditional.This actually *used* to be the case; something must have broken 
it since 1.0 (the last time I tested that tutorial).

Can you provide the traceback that is emitted when "the wrong thing" happens?

> 
> The failure was that the resulting fresh application loads Chameleon via:
> 
> 
> 
> which is included in paster jinja2 template configure.zcml [2]
> 
> Just removing this line gets the app up and running but is missing
> directives from repoze.zcml:meta.zcml
> 
> I see 2 options:
> 
> 1. replace the above mentioned include with the following in the
> jinja2 paster template (attached patch.diff)
> 
> 
> 
> ... which has the drawback that those using the paster template do not
> have Chameleon (desirable in gae but perhaps not in other scenarios).
> 
> 2. Make a mention in the tutorial (perhaps as in attached doc.diff)
> 
> Hope that is helpful,
> Darryl Cousins
> 
> [1] http://docs.repoze.org/bfg/1.2/tutorials/gae/index.html
> [2] 
> http://svn.repoze.org/repoze.bfg.jinja2/trunk/repoze/bfg/jinja2/paster_template/+package+/configure.zcml
> 
> 
> 
> 
> ___
> 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

[Repoze-dev] repoze.bfg 1.1.4 and 1.2a3 released

[Chris McDonough]

Two new releases of repoze.bfg are out.

Install 1.1.4 via:

easy_install -i http://dist.repoze.org/bfg/1.1/simple repoze.bfg

Install 1.2a3 via:

easy_install -i http://dist.repoze.org/bfg/1.2/simple repoze.bfg

Or either is available via PyPI.

These are bugfix releases.   No release notice for for 1.1.3 went out, so I 
include it here.

1.1.4 (2009-12-02)
==

- When two views were registered with differering ``for`` interfaces
   or classes, and the ``for`` of first view registered was a
   superclass of the second, the ``repoze.bfg` view machinery would
   incorrectly associate the two views with the same "multiview".
   Multiviews are meant to be collections of views that have *exactly*
   the same for/request/viewname values, without taking inheritance
   into account.  Symptom: wrong view callable found even when you had
   correctly specified a ``for_`` interface/class during view
   configuration for one or both view configurations (backport from
   trunk).

1.1.3 (2009-12-02)
==

Bug Fixes
-

- The ``repoze.bfg.url.route_url`` function inappropriately passed
   along ``_query`` and/or ``_anchor`` arguments to the
   ``mapper.generate`` function, resulting in blowups (backport from
   trunk).

1.2a3 (2009-01-02)
==

Bug Fixes
-

- The ``repoze.bfg.url.route_url`` function inappropriately passed
   along ``_query`` and/or ``_anchor`` arguments to the
   ``mapper.generate`` function, resulting in blowups.

- When two views were registered with differering ``for`` interfaces
   or classes, and the ``for`` of first view registered was a
   superclass of the second, the ``repoze.bfg` view machinery would
   incorrectly associate the two views with the same "multiview".
   Multiviews are meant to be collections of views that have *exactly*
   the same for/request/viewname values, without taking inheritance
   into account.  Symptom: wrong view callable found even when you had
   correctly specified a ``for_`` interface/class during view
   configuration for one or both view configurations.

Backwards Incompatibilities
---

- The ``repoze.bfg.templating`` module has been removed; it had been
   deprecated in 1.1 and never actually had any APIs in it.

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] authorization debug problem

[Chris McDonough]

Wichert Akkerman wrote:
> I use a custom authorization problem, but noticed that when I enable 
> BFG_DEBUG_AUTHORIZATION it always reports "no authorization policy in 
> use". I am guessing this happens because the authorization policy is 
> registered after the routes are setup, so the queryUtility calls in 
> authdebug_view happen too early. If I move them inside the 
> _authdebug_view method things work properly. I'm not sure what the right 
> fix is: reordering the configuration, or moving those queryUtility calls.

A better fix is to actually move to the 1.2 series and pass the authorization 
policy to the "Configurator" at startup time: 
http://docs.repoze.org/bfg/1.2/api/configuration.html

- C

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] fun benchmarks.

[Chris McDonough]

And in the spirit of 

 
a Chameleon hello world benchmark, rendering a template from a view that calls 
"repoze.bfg.chameleon_zpt.render_template_to_response" filling a slot in a 
macro from another template:

The view:

   from repoze.bfg.chameleon_zpt import render_template_to_response
   from repoze.bfg.chameleon_zpt import get_template

   master = get_template('templates/master.pt')

   def my_view(request):
   return render_template_to_response('templates/mytemplate.pt',
   project='starter', master=master)

The mytemplate.pt template:

   http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
   http://www.w3.org/1999/xhtml";
 xmlns:tal="http://xml.zope.org/namespaces/tal";
 xmlns:metal="http://xml.zope.org/namespaces/metal";>
   
   
  
   Lorem ipsum dolor sit amet, consecteteur adipiscing elit nisi 
ultricies. Condimentum vel, at augue nibh sed. Diam praesent metus ut eros, sem 
penatibus. Pellentesque. Fusce odio posuere litora non integer habitant proin. 
Metus accumsan nibh facilisis nostra lobortis cum diam tellus. Malesuada nostra 
a volutpat pede primis congue nisl feugiat in fermentum. Orci in hymenaeos. Eni 
tempus mi mollis lacinia orci interdum lacus. Sollicitudin aliquet, etiam. Ac. 
Mi, nullam ligula, tristique penatibus nisi eros nisl pede pharetra congue, 
aptent nulla, rhoncus tellus morbi, ornare. Magna condimentum erat turpis. 
Fusce arcu ve suscipit nisi phasellus rutrum a dictumst leo, laoreet dui, 
ultricies platea. Porta venenatis fringilla vestibulum arcu etiam condimentum 
non.
   
   
   
   

The master.pt template:

   http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
   http://www.w3.org/1999/xhtml";
 xmlns:tal="http://xml.zope.org/namespaces/tal";
 xmlns:metal="http://xml.zope.org/namespaces/metal";>
   
 
   Hello ${project}
 
   
   

running ab -n1 -c10 against such a setup (as per the referenced blog entry):

   Server Software:Apache/2.2.12
   Server Hostname:127.0.0.1
   Server Port:80

   Document Path:  /starter
   Document Length:989 bytes

   Concurrency Level:  10
   Time taken for tests:   1.528 seconds
   Complete requests:  1
   Failed requests:0
   Write errors:   0
   Total transferred:  11801180 bytes
   HTML transferred:   9890989 bytes
   Requests per second:6544.78 [#/sec] (mean)
   Time per request:   1.528 [ms] (mean)
   Time per request:   0.153 [ms] (mean, across all concurrent requests)
   Transfer rate:  7542.59 [Kbytes/sec] received

Siege results (1000 reps, 10 concurrent in benchmark mode) against same:

   ** SIEGE 2.68
   ** Preparing 10 concurrent users for battle.
   The server is now under siege..  done.
   Transactions:   1 hits
   Availability:  100.00 %
   Elapsed time:1.81 secs
   Data transferred:5.69 MB
   Response time:   0.00 secs
   Transaction rate: 5524.86 trans/sec
   Throughput:  3.15 MB/sec
   Concurrency: 9.84
   Successful transactions:   1
   Failed transactions:0
   Longest transaction: 0.01
   Shortest transaction:0.00

Between 5500 - 6500 rps depending on whom you believe.

If you take for granted that the box described at 

 
  is roughly half as fast as this box that this test was performed on, and you 
take for granted that those tests are roughly accurate:  BFG beats everybody 
else benchmarked by between 2X and 3X except for Bottle, which is slightly 
faster in this test than BFG.  Bottle beats BFG by 10% with Bottle+Mako vs 
BFG+Chameleon, and by about 20% with no templating system involved.

- C

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] fun benchmarks.

[Chris McDonough]

We just got a new box in and I did some benchmarks on it just to see how it 
worked.  It's an Intel i5 (dual core, hyperthreading enabled, so it appears to 
have four cores to the OS) running 64-bit Ubuntu 9.10.  Each core reports 
something like this from /proc/cpuinfo:

   processor: 3
   vendor_id: GenuineIntel
   cpu family   : 6
   model: 30
   model name   : Intel(R) Core(TM) i5 CPU 750  @ 2.67GHz
   stepping : 5
   cpu MHz  : 1197.000
   cache size   : 8192 KB
   physical id  : 0
   siblings : 4
   core id  : 3
   cpu cores: 4
   apicid   : 6
   initial apicid   : 6
   fpu  : yes
   fpu_exception: yes
   cpuid level  : 11
   wp   : yes
   flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov   pat 
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm 
constant_tsc arch_perfmon pebs bts rep_good xtopology tsc_reliable nonstop_tsc 
pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 
popcnt lahf_lm ida tpr_shadow vnmi flexpriority ept vpid
   bogomips : 5333.41
   clflush size : 64
   cache_alignment  : 64
   address sizes: 36 bits physical, 48 bits virtual

For the static file rendered at / we get this from ab -n1001 -c15:

   Server Software:Apache/2.2.12
   Server Hostname:127.0.0.1
   Server Port:80

   Document Path:  /
   Document Length:177 bytes

   Concurrency Level:  15
   Time taken for tests:   0.088 seconds
   Complete requests:  1001
   Failed requests:0
   Write errors:   0
   Total transferred:  452904 bytes
   HTML transferred:   177354 bytes
   Requests per second:11339.31 [#/sec] (mean)
   Time per request:   1.323 [ms] (mean)
   Time per request:   0.088 [ms] (mean, across all concurrent requests)
   Transfer rate:  5010.24 [Kbytes/sec] received

That would be somewhere around 11K requests per second or so.

For the followng "bare" WSGI app:

   def application(environ, start_response):
  start_response('200 OK', [('Content-Type', 'text/plain'),
('Content-Length', '5')])
  return ['hello']

ab -n1001 -c15 returns:

   Server Software:Apache/2.2.12
   Server Hostname:127.0.0.1
   Server Port:80

   Document Path:  /bareapp
   Document Length:5 bytes

   Concurrency Level:  15
   Time taken for tests:   0.090 seconds
   Complete requests:  1001
   Failed requests:0
   Write errors:   0
   Total transferred:  180720 bytes
   HTML transferred:   5020 bytes
   Requests per second:11129.89 [#/sec] (mean)
   Time per request:   1.348 [ms] (mean)
   Time per request:   0.090 [ms] (mean, across all concurrent requests)
   Transfer rate:  1962.29 [Kbytes/sec] received

That's about 11K requests per second too.

For the "helloworld" program at http://svn.repoze.org/whatsitdoing/bfg using 
mod_wsgi 1.2a2 under Python 2.6 configured using mod_wsgi 2.5 in daemon mode 
with 4 processes and 15 threads, we get the following from ab -n1001 -c15:

   Server Software:Apache/2.2.12
   Server Hostname:127.0.0.1
   Server Port:80

   Document Path:  /helloworld
   Document Length:5 bytes

   Concurrency Level:  15
   Time taken for tests:   0.111 seconds
   Complete requests:  1001
   Failed requests:0
   Write errors:   0
   Total transferred:  179537 bytes
   HTML transferred:   5015 bytes
   Requests per second:9021.27 [#/sec] (mean)
   Time per request:   1.663 [ms] (mean)
   Time per request:   0.111 [ms] (mean, across all concurrent requests)
   Transfer rate:  1580.11 [Kbytes/sec] received

Using "siege" (http://freshmeat.net/projects/siege/) for the BFG app we get 
similar results (1000 reps, 20 concurrent users in benchmark mode):

   ** SIEGE 2.68
   ** Preparing 20 concurrent users for battle.
   The server is now under siege..  done.
   Transactions:   2 hits
   Availability:  100.00 %
   Elapsed time:2.48 secs
   Data transferred:0.48 MB
   Response time:   0.00 secs
   Transaction rate: 8064.52 trans/sec
   Throughput:  0.19 MB/sec
   Concurrency:19.61
   Successful transactions:   2
   Failed transactions:0
   Longest transaction: 0.02
   Shortest transaction:0.00

That would be somewhere around 8K - 9K requests per second, depending on whom 
you believe.

That's pretty snappy hardware for not much money.  I don't think we have much 
excuse for slow web apps anymore.

- C
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.r

[Repoze-dev] [issue110] unexpected keyword argument 'level' repoze.bfg.jinja2 (bfg 1.2a2)

[Chris McDonough]

Chris McDonough  added the comment:

Thanks; I've fixed this in the 0.6 release, now on PyPI.

--
status: unread -> resolved

__
Repoze Bugs 
<http://bugs.repoze.org/issue110>
__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] repoze.bfg 1.2a2 released

[Chris McDonough]

repoze.bfg 1.2a2 is out.  Install via:

   easy_install -i http://dist.repoze.org/bfg/1.2/simple repoze.bfg

Or via PyPI.

This is a pure bugfix release.  The changelog follows.

1.2a2 (2009-11-29)
==

Bug Fixes
-

- The the long description of this package (as shown on PyPI) was not
   valid reStructuredText, and so was not renderable.

- Trying to use an HTTP method name string such as ``GET`` as a
   ``request_type`` predicate argument caused a startup time failure
   when it was encountered in imperative configuration or in a
   decorator (symptom: ``Type Error: Required specification must be a
   specification``).  This now works again, although ``request_method``
   is now the preferred predicate argument for associating a view
   configuration with an HTTP request method.

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] [bfg 1.2a1] Required specification must be a specification or class.

[Chris McDonough]

Andreas Jung wrote:
> Tried to get zopyx.smartprintng.server working w/ BFG 1.2a1. This fails
> badly.
> Anything I am missing?

Thanks for trying it.  I have fixed this on the trunk and your server now 
starts.

For maximum forward compatibility, you'll probably eventually want to change:

@bfg_view(for_=Server, request_type='GET', permission='read')

to:

@bfg_view(for_=Server, request_method='GET', permission='read')

(ie. request_type -> request_method)

> 
> Andreas
> 
> 
> aj...@suxmac2:~/src/svn.zope.org/zopyx.smartprintng.server/trunk
> bin/paster serve server.ini
> SmartPrintNG server started
> Temp directory:
> /var/folders/Ov/OvU++3BsFOaXK0Lrm8F4CTI/-Tmp-/zopyx.smartprintng.server
> Spool directory:
> /var/folders/Ov/OvU++3BsFOaXK0Lrm8F4CTI/-Tmp-/zopyx.smartprintng.server-spool
> Available converters: ebook-calibre, fo, odt-xfc, ooxml-xfc, pdf-prince,
> pdf-xinc, rtf-xfc, wml-xfc
> No auth module found - serving for anonymous
> Traceback (most recent call last):
>   File "bin/paster", line 8, in 
> load_entry_point('PasteScript==1.7.3', 'console_scripts', 'paster')()
>   File
> "/Users/ajung/src/svn.zope.org/zopyx.smartprintng.server/trunk/lib/python2.6/site-packages/PasteScript-1.7.3-py2.6.egg/paste/script/command.py",
> line 84, in run
> invoke(command, command_name, options, args[1:])
>   File
> "/Users/ajung/src/svn.zope.org/zopyx.smartprintng.server/trunk/lib/python2.6/site-packages/PasteScript-1.7.3-py2.6.egg/paste/script/command.py",
> line 123, in invoke
> exit_code = runner.run(args)
>   File
> "/Users/ajung/src/svn.zope.org/zopyx.smartprintng.server/trunk/lib/python2.6/site-packages/PasteScript-1.7.3-py2.6.egg/paste/script/command.py",
> line 218, in run
> result = self.command()
>   File
> "/Users/ajung/src/svn.zope.org/zopyx.smartprintng.server/trunk/lib/python2.6/site-packages/PasteScript-1.7.3-py2.6.egg/paste/script/serve.py",
> line 276, in command
> relative_to=base, global_conf=vars)
>   File
> "/Users/ajung/src/svn.zope.org/zopyx.smartprintng.server/trunk/lib/python2.6/site-packages/PasteScript-1.7.3-py2.6.egg/paste/script/serve.py",
> line 313, in loadapp
> **kw)
>   File
> "/Users/ajung/src/svn.zope.org/zopyx.smartprintng.server/trunk/lib/python2.6/site-packages/PasteDeploy-1.3.3-py2.6.egg/paste/deploy/loadwsgi.py",
> line 204, in loadapp
> return loadobj(APP, uri, name=name, **kw)
>   File
> "/Users/ajung/src/svn.zope.org/zopyx.smartprintng.server/trunk/lib/python2.6/site-packages/PasteDeploy-1.3.3-py2.6.egg/paste/deploy/loadwsgi.py",
> line 225, in loadobj
> return context.create()
>   File
> "/Users/ajung/src/svn.zope.org/zopyx.smartprintng.server/trunk/lib/python2.6/site-packages/PasteDeploy-1.3.3-py2.6.egg/paste/deploy/loadwsgi.py",
> line 625, in create
> return self.object_type.invoke(self)
>   File
> "/Users/ajung/src/svn.zope.org/zopyx.smartprintng.server/trunk/lib/python2.6/site-packages/PasteDeploy-1.3.3-py2.6.egg/paste/deploy/loadwsgi.py",
> line 110, in invoke
> return fix_call(context.object, context.global_conf,
> **context.local_conf)
>   File
> "/Users/ajung/src/svn.zope.org/zopyx.smartprintng.server/trunk/lib/python2.6/site-packages/PasteDeploy-1.3.3-py2.6.egg/paste/deploy/util/fixtypeerror.py",
> line 57, in fix_call
> val = callable(*args, **kw)
>   File
> "/Users/ajung/src/svn.zope.org/zopyx.smartprintng.server/trunk/zopyx/smartprintng/server/run.py",
> line 38, in app
> return make_app(get_root, zopyx.smartprintng.server, options=kw)
>   File
> "/Users/ajung/src/svn.zope.org/zopyx.smartprintng.server/trunk/lib/python2.6/site-packages/repoze.bfg-1.2a1-py2.6.egg/repoze/bfg/configuration.py",
> line 1523, in make_app
> config.load_zcml(zcml_file)
>   File
> "/Users/ajung/src/svn.zope.org/zopyx.smartprintng.server/trunk/lib/python2.6/site-packages/repoze.bfg-1.2a1-py2.6.egg/repoze/bfg/configuration.py",
> line 323, in load_zcml
> xmlconfig.file(filename, package, execute=True)
>   File
> "/Users/ajung/src/svn.zope.org/zopyx.smartprintng.server/trunk/lib/python2.6/site-packages/zope.configuration-3.6.0-py2.6.egg/zope/configuration/xmlconfig.py",
> line 649, in file
> context.execute_actions()
>   File
> "/Users/ajung/src/svn.zope.org/zopyx.smartprintng.server/trunk/lib/python2.6/site-packages/zope.configuration-3.6.0-py2.6.egg/zope/configuration/config.py",
> line 605, in execute_actions
> callable(*args, **kw)
>   File
> "/Users/ajung/src/svn.zope.org/zopyx.smartprintng.server/trunk/lib/python2.6/site-packages/repoze.bfg-1.2a1-py2.6.egg/repoze/bfg/configuration.py",
> line 897, in scan
> register_decorations(name, ob)
>   File
> "/Users/ajung/src/svn.zope.org/zopyx.smartprintng.server/trunk/lib/python2.6/site-packages/repoze.bfg-1.2a1-py2.6.egg/repoze/bfg/configuration.py",
> line 885, in register_decorations
> self.add_view(view=ob, _info=_info, **setting)
>   File
> "/Users/ajung/src/svn.zope.org/zopyx.smartprintng.server/trunk/lib/python2.6/site-packages/repoze.bfg-1.2

[Repoze-dev] repoze.bfg 1.2a1 released

[Chris McDonough]

repoze.bfg 1.2a1 is now released.  It can be installed via:

easy_install -i http://dist.repoze.org/bfg/1.2/simple repoze.bfg

Or via PyPI.

Documentation for this release exists at:

http://docs.repoze.org/bfg/1.2/

This is a major feature release.  The new features of the release are detailed 
in a "What's New" document available at 
http://docs.repoze.org/bfg/1.2/whatsnew-1.2.html

In particular, this release has a new "imperative configuration" mode that 
makes it possible to create the simplest repoze.bfg application as a single 
Python file.

Enjoy,

- C
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] 1.2a1 imminent...

[Chris McDonough]

Tim Hoffman wrote:
> Hi Chris
> 
> I think this is a good direction to go in.  I am already starting to
> do something similair  this with repoze (I am still on 1.0.1) but plan
> to upgrade in the next few weeks,.
> 
> The advantage of this style of configuration really comes into its own
> when you are running on appengine.
> With appengine you really can't rely on long running apps, so being
> able to defer some of the declerations/registrations until you
> actually need them
> (for instance only bother registering stuff for an admin user if an
> admin user is logged in) is really important because its startup time
> of a cold instance
> that will kill you at times.
> 
> Using ZCML means is difficult to choose when to register things
> (without jumping through hoops) and view decorators are just as bad.

For the record, in IRC, Daniel Holth measured startup time of his repoze.bfg 
app and found that most of the startup time was chewed up (in his case) by the 
behavior of pkg_resources namespace packages when lots and lots of egg packages 
are on sys.path.  He was able to reduce his application startup time from 
something like 5 seconds to 1 second (or sub-1-second maybe) by just getting 
rid of unused packages on sys.path.

I think he also discovered that ZCML parsing time was negligible (at least 
relative to the time chewed up by pkg_resources).

> Thanks for the great work.

Thanks,

- C


___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] 1.2a1 imminent...

[Chris McDonough]

Hi folks,

I've been working on the next minor revision to repoze.bfg, which will be 1.2.

1.2 will be a slightly more important release than the previous 1.1 release, 
because it involves exposing an "imperative" API for configuration (adding 
routes/views, etc).

In particular, it means that the simplest repoze.bfg application can be 
represented as a single file:

from webob import Response
from wsgiref import simple_server
from repoze.bfg.configuration import Configurator

def hello_world(request):
return Response('Hello world!')

if __name__ == '__main__':
config = Configurator()
config.add_view(hello_world)
app = config.make_wsgi_app()
simple_server.make_server('', 8080, app).serve_forever()

As far as I can tell, aside from package dependencies, such a configuration 
mode puts repoze.bfg in the same category as "microframeworks" (such as Bottle 
and Tornado), because applications can start as a single file, then evolve into 
a package, then maybe "grow" declarative configuration in the form of ZCML, and 
so on.  repoze.bfg, on the other hand, has a good deal of functionality that 
microframeworks lack, so I like to think of this functionality as sort of the 
"best of both worlds" feature.

Thankfully, the 1.2 release will be almost 100% b/w compatible with previous 
releases, so I don't think we lost anything to obtain this feature (except for 
my time ;-) ).

If anyone has time, it would be great for folks to read the two new chapters of 
the repoze.bfg documentation available at:

- http://docs.repoze.org/bfg/trunk/narr/configuration.html

- http://docs.repoze.org/bfg/trunk/narr/scanning.html

.. and provide feedback and edits before I release an alpha.  In general, I 
think we'd all like the docs to be 100% clear on how all this works.

- C

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] repoze.bfg 1.1.2 released

[Chris McDonough]

Happy Thanksgiving folks.

repoze.bfg 1.1.2 has been released.  Install it via:

easy_install -i http://dist.repoze.org/bfg/1.1/simple repoze.bfg

Or via PyPI.

It is a pure bugfix release.  The changelog follows:

1.1.2 (2009-11-26)
==

Bug Fixes
-

- When two views were registered with the same ``accept`` argument,
   but were otherwise registered with the same arguments, if a request
   entered the application which had an ``Accept`` header that accepted
   *either* of the media types defined by the set of views registered
   with predicates that otherwise matched, a more or less "random" one
   view would "win".  Now, we try harder to use the view callable
   associated with the view configuration that has the most specific
   ``accept`` argument.  Thanks to Alberto Valverde. (backport from
   trunk).

- The ACL authorization policy debugging output when
   ``debug_authorization`` console debugging output was turned on
   wasn't as clear as it could have been when a view execution was
   denied due to an authorization failure resulting from the set of
   principals passed never having matched any ACE in any ACL in the
   lineage.  Now in this case, we report  as the ACE
   value and either the root ACL or  if no ACL was found. (backport from trunk).
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] Possible "accept" view-predicate enhancement?

[Chris McDonough]

Alberto Valverde wrote:
> Hello,
> 
> I'm trying to make use of the new-in-1.1 "accept" view predicate to 
> register several views with the same name for the same context object to 
> render a response in the content-type requested by the user but the 
> result is not quite what I expect. The zcml looks like this:
> 
>   for="sigym.propag.interfaces.IPropagator"
> permission="view"
> request_method="GET"
> accept="text/html"
> renderer="sigym.ogcserver:views/templates/index.html"
> />
>   for="sigym.propag.interfaces.IPropagator"
> view="sigym.ogcserver.views.viewpanels.config_view"
> permission="view"
> request_method="GET"
> accept="application/json+xconfig"
> renderer="json"
> />
>   for="sigym.propag.interfaces.IPropagator"
> view=".views.list_propagations"
> permission="view"
> request_method="GET"
> accept="application/json"
> renderer="json"
> />
> 
> Everything works fine when I request the application/json and 
> application/json+xconfig mimetypes with a xhr since I can control the 
> "Accept" header, however, when a browser makes a "normal" request the 
> result is unpredictable (in practice) since '*/* is sent in the accept 
> header so all of the view predicates evaluate positively.
> 
> I made a quick POC patch so the best match is taken into account 
> (attached). It modifies MultiView.__call__() so it narrows down the 
> predicates that it will evaluate using the request.accept.best_match() 
> method and it seems to work (all bfg tests still pass and the result is 
> as expected when I manually test my bfg app). The patch is against the 
> 1.1 branch in SVN.
> 
> Is this the right approach? If so I would like to finish it up with 
> tests to reach full coverage and contribute it :)

The more I think about it Alberto, I think the patch you sent over is pretty 
much correct (definitely more correct than the current behavior; it must have 
taken a lot of thought, thank you).

I think we might want to change view registration so it operates like this:

- If there's not already a view callable registered for this
   context/request/viewname (this is the first view being registered for
   this particular triad), register a view callable with
   the accept value as a *predicate*, except also set __accept__ on the view
   callable like your patch does (in case another view gets registered for
   the same triad, resulting in a MultiView; we need to keep the value handy).
   Derived views without an "accepts=" in the set of registration arguments
   will be registered with "__accepts__ = None" attribute, while derived
   views with an "accepts=" in the set of registration arguments will be
   registered with an "__accepts__ = 'text/html'" (or whatever).

- If there is already a *non-MultiView* view callable registered for this
   triad, unregister the old view, and register a MultiView with both the old
   view and the new view.

- If there is already a *MultiView* view callable registered for this triad,
   add the new view to the multiview.

A MultiView will keep all views it represents that have the same "accepts" 
value in a "bucket" representing that accepts value.  Each "bucket" will be a 
sequence of (score, view_callable) ordered by score.  The buckets will be kept 
as the values of a dictionary attribute of the multiview.  The dictionary will 
be keyed by accept value.

The __call__ of a MultiView will do this:

- Find the "best" Accepts value for the currently registered set of accepts
   values for this multiview (the keys of the dictionary) by asking
   request.accept.best_match.

- Retrieve the subset of views in this multiview that match the best accept
   value, and iterate over each of those, testing the predicates of each.
   If a view callable matches, call it and return the response.  If a no
   view callable matches, however, retest "best_match" *without* the previously
   tested "accepts" value to find the "next best" match, ad infinitum until
   we either find a view that matches or we run out of subsets to test.  If
   "best_match" does its job right, the very last subset we test will be the
   set of views that do not have *any* "accepts" value (the subset of views
   keyed on the None accepts value).

Obviously we'll put some shortcut logic in here so it will "go fast" when all 
views in the multiview are registered with "accepts=None".

Hows that?

- C

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] Possible "accept" view-predicate enhancement?

[Chris McDonough]

Alberto Valverde wrote:
> Chris McDonough wrote:
>> Alberto Valverde wrote:
>>> Hello,
>>>
>>> I'm trying to make use of the new-in-1.1 "accept" view predicate to 
>>> register several views with the same name for the same context object 
>>> to render a response in the content-type requested by the user but 
>>> the result is not quite what I expect. The zcml looks like this:
>>>
>>>  >> for="sigym.propag.interfaces.IPropagator"
>>> permission="view"
>>> request_method="GET"
>>> accept="text/html"
>>> renderer="sigym.ogcserver:views/templates/index.html"
>>> />
>>>  >> for="sigym.propag.interfaces.IPropagator"
>>> view="sigym.ogcserver.views.viewpanels.config_view"
>>> permission="view"
>>> request_method="GET"
>>> accept="application/json+xconfig"
>>> renderer="json"
>>> />
>>>  >> for="sigym.propag.interfaces.IPropagator"
>>> view=".views.list_propagations"
>>> permission="view"
>>> request_method="GET"
>>> accept="application/json"
>>> renderer="json"
>>> />
>>>
>>> Everything works fine when I request the application/json and 
>>> application/json+xconfig mimetypes with a xhr since I can control the 
>>> "Accept" header, however, when a browser makes a "normal" request the 
>>> result is unpredictable (in practice) since '*/* is sent in the 
>>> accept header so all of the view predicates evaluate positively.
>>>
>>> I made a quick POC patch so the best match is taken into account 
>>> (attached). It modifies MultiView.__call__() so it narrows down the 
>>> predicates that it will evaluate using the 
>>> request.accept.best_match() method and it seems to work (all bfg 
>>> tests still pass and the result is as expected when I manually test 
>>> my bfg app). The patch is against the 1.1 branch in SVN.
>>>
>>> Is this the right approach? If so I would like to finish it up with 
>>> tests to reach full coverage and contribute it :)
>>
>> Thanks a lot for the patch!  This is definitely something that we 
>> should be accounting for.  I'm not sure that the patch is exactly 
>> right; if there are "views_for_mimes", even if the current 
>> configuration doesn't have a view that matches the "best" accept 
>> header, it should continue trying to look for other views that don't 
>> specify an accept argument instead of raising a NotFound I think.  At 
>> least I think.  Let me think on it a little bit.
> Hmm, after thinking more about it and reading the relevant section of 
> the http spec [1] I found this snippet:
> 
> "... If no Accept header field is present, then it is assumed that the 
> client accepts all media types. If an Accept header field is present, 
> and if the server cannot send a response which is acceptable according 
> to the combined Accept field value, then the server SHOULD send a 406 
> (not acceptable) response"
> 
> Which I think it means that the rest of the views (those with no accept 
> predicate) should not be checked since the client explicitly asked for a 
> content-type and no view has declared that it can provide it. In this 
> case, according to the spec, I think, a 406 response should be returned 
> instead of raising a NotFound.

I don't think so.  This bit of RFC compliance might be expected by the client 
of a particular application, and a particular application might want to satisfy 
that expectation, but I don't think it's BFG's job to mandate that it must; 
instead we just want to allow application developers to make that decision 
themselves by allowing them to register a less specific view (one *without* an 
accepts=) that perhaps returns a 406.

> So perhaps we should consider what's the desired behavior in this 
> scenario? I mean, the meaning of not declaring an "accept" predicate 
> *when* other possible candidates have. Should it be "*/*" and continue 
> searching or the opposite? Hmm, I think you're right since "*/*" is the 
> meaning when no candidate has declared it which I guess it's more 
> intuitive

I think view lookup should continue even if views are registered with accept 
predicates and found, but none of those view match.

- C
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] would like to registerViews in python but not via decorator

[Chris McDonough]

Tim Hoffman wrote:
> Hi Chris
> 
> I am trying to register some views directly through python and not
> using the view decorator,
> I have tried using code very similiar to repoze.bfg.testing.
> 
> However after doing so, whilst I can look the view up by doing
> a zope.component.queryMultiAdapter((context,request),IView,name="myview")
> and alternately getting the site manager first.
> 
> However the router never seems to be able to find the views I have
> registered in this fashion.

Sorry for not responding sooner Tim.

I'm not sure how this is; it may be that your registrations are getting in to 
the "wrong" registry.  Try using repoze.bfg.threadlocal.get_current_registry() 
instead of zope.component.getSiteManager() to retrieve the registry before you 
add stuff to it maybe?

Note that the trunk has facilities out of the box for this (although it's still 
under heavy development):




- C

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] Possible "accept" view-predicate enhancement?

[Chris McDonough]

Alberto Valverde wrote:
> Hello,
> 
> I'm trying to make use of the new-in-1.1 "accept" view predicate to 
> register several views with the same name for the same context object to 
> render a response in the content-type requested by the user but the 
> result is not quite what I expect. The zcml looks like this:
> 
>   for="sigym.propag.interfaces.IPropagator"
> permission="view"
> request_method="GET"
> accept="text/html"
> renderer="sigym.ogcserver:views/templates/index.html"
> />
>   for="sigym.propag.interfaces.IPropagator"
> view="sigym.ogcserver.views.viewpanels.config_view"
> permission="view"
> request_method="GET"
> accept="application/json+xconfig"
> renderer="json"
> />
>   for="sigym.propag.interfaces.IPropagator"
> view=".views.list_propagations"
> permission="view"
> request_method="GET"
> accept="application/json"
> renderer="json"
> />
> 
> Everything works fine when I request the application/json and 
> application/json+xconfig mimetypes with a xhr since I can control the 
> "Accept" header, however, when a browser makes a "normal" request the 
> result is unpredictable (in practice) since '*/* is sent in the accept 
> header so all of the view predicates evaluate positively.
> 
> I made a quick POC patch so the best match is taken into account 
> (attached). It modifies MultiView.__call__() so it narrows down the 
> predicates that it will evaluate using the request.accept.best_match() 
> method and it seems to work (all bfg tests still pass and the result is 
> as expected when I manually test my bfg app). The patch is against the 
> 1.1 branch in SVN.
> 
> Is this the right approach? If so I would like to finish it up with 
> tests to reach full coverage and contribute it :)

Thanks a lot for the patch!  This is definitely something that we should be 
accounting for.  I'm not sure that the patch is exactly right; if there are 
"views_for_mimes", even if the current configuration doesn't have a view that 
matches the "best" accept header, it should continue trying to look for other 
views that don't specify an accept argument instead of raising a NotFound I 
think.  At least I think.  Let me think on it a little bit.


- C

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] starter request

[Chris McDonough]

Iain Duncan wrote:
> Wondering if it would be possible to add a paster starter template for
> bgf_routes ( no sqlalchemy )? Seems to be a missing piece.

Instead of adding another a paster template, we could just answer whatever 
concrete questions you have about routing?  Each paster template we add to the 
system currently has a nontrivial cost in terms of maintenance (they are 
currently maintained 100% by-hand, as changes are made to the system).

- C

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] doc question

[Chris McDonough]

Iain Duncan wrote:
> Am I missing something terribly obvious, or is that not just a regular
> instance method in the example? Or am I misunderstanding the point?
> Perhaps this part could be clearer, it's confused me at any rate.

I'm not really clear how to make changes to make it clearer.  What are your 
expectations?

- C

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] using the pylons/weberror interfactive debugger in bfg apps?

[Chris McDonough]

Iain Duncan wrote:
> Hey all, one thing I miss in Pylons is the out of the box integration
> with the interactive debugger in your browser. I'll confess ignorance as
> to how this is hooked up, but it's *really* helpful to people learning
> pylons. Wondering if it would be a good plan to put this 'in the box'
> for bfg or maybe to add something to the docs demonstrating how to do
> so? I realize it's not a hard thing to add yourself, but when learning a
> new framework, the less you have to do to get a setup that is
> learning-positive, the better, IMHO.

I'd prefer docs explaining how to do it; I'd rather be responsible for knowing 
that people know how to enable it than for them to not know it's a security 
hole and leave it enabled in a production app cobbled together from the paster 
template.

Essentially it's just replacing (in the starter app config):

[app:main]
use = egg:{{project}}#app
reload_templates = true
debug_authorization = false
debug_notfound = false

With:

[app:starter]
use = egg:starter#app
reload_templates = true
debug_authorization = false
debug_notfound = false

[pipeline:main]
pipeline =
egg:weberror#evalerror
starter

And making sure to remember to "easy_install WebError".

- C

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] repoze.bfg future plans?

[Chris McDonough]

Iain Duncan wrote:
> Hey Chris et. al, I'm seriously considering switching my main platform
> for our inhouse framework to mostly repoze.bfg with auxillary pylons
> bits from the other way around, but have a few concerns that mostly
> relate to making sure that clients buy into our platform of choice and
> feel like they aren't all up the creek if we get hit by a truck (we're
> small, one big truck could do it!) Have you guys considered adding to
> the (wonderful) docs some sort of general bfg 'mission statement', long
> range plan, future directions kind of deal? I think this would really
> help bfg adoption, *if* that is a concern of yours and I'm not sure
> whether it is.

We do have http://bfg.repoze.org/trac/wiki/RoadMap but it's not very 
"PHB-consumable" or very specific.  Lately, framework direction has been 
dictated almost entirely by my own whims.  My whims lately have been informed 
mostly by community input, as opposed to by "Agendaless customer" input, as was 
the case several months ago, but still it's just my own whims.

> What I am afraid of is the (mis?)-perception that a framework might just
> hit the point where the core team says "well it does what we want, no
> need for it to grow anymore". I totally respect an author's right to do
> that, but as happened with Mochikit, it means the framework essentially
> becomes a once off library and it becomes much harder to convince other
> stakeholders that they are not investing money on a dying horse, and
> thus harder for us to justify using it. ( Now dojo has ported most of
> Mochikit's best bits, and it's essentially a legacy project.) 

I don't think BFG 1.X is in danger of becoming too stale, at least for the next 
six months or a year or so.  The point where what folks currently think of as 
"BFG" is more likely to become stale is when we make changes to it that require 
a major version number switch (e.g. 1.X -> 2.X).  In such changeovers, there 
might be backwards incompatibilities that leave early adopters stranded on a 
1.X series that receives less attention than a newer, "cooler" 2.X.

Hopefully we don't fall victim to this for stupid reasons, but nothing is set 
in stone; often there turn out to be not-stupid reasons to ditch some portion 
b/w compat in order to take advantage of some newer set of libraries or some 
new platform, or whatever.

The best way to avoid problems if this happens is to make sure that the 1.X 
series has a big enough userbase that folks step up to take over maintenance of 
the 1.X series should it become "legacy".  So it's something of a chicken and 
egg scenario.

> Right now it's easy for me to sell my clients on Pylons because we have
> decent books on Pylons, SQLAlchemy, etc, and that is reassuring to them
> ( it must be really easy for Django ). It's harder with repoze.bfg
> because I can kind of point at zope, kind of point at the docs, kind of
> point at the zope credentials of the team behind it, but nothing as
> solid as a bound hunk of paper. So any marketing signs that this is
> serious and won't be going away any time soon would help. I would also
> be interested in seeing on there any mentions of future possible
> collaborations with Pylons or Grok, as that also reassures people that
> this won't just stop! ;-)

I'd actually like to get a book out there on the market based on the current 
BFG documentation, if the licensing terms were right.  I haven't shopped this 
idea around at all to any publishers, but if anyone should know any who would 
be interested in such a deal, I'd like to talk to them.  I don't think there's 
currently a big enough market, though, so I don't expect folks to be knocking 
the door down.  On the other hand, I don't have much doubt that there *will* be 
a big enough market pretty soon, so it would be nice to get some sort of deal 
lined up.

We are also loosely collaborating with Ben Bangert of Pylons, and we're hoping 
to share more technology at the base.  I think maybe there will be more to talk 
about with respect to this around US PyCon time.

> So I guess I'm asking for some sort of write up on the website
> addressing those sorts of things *if* they are a concern of yours, and
> if not, a clarification that they aren't and that it's a "use if it's
> useful but don't complain about our choices" kind of deal, which is
> absolutely an author's prerogative.

I'd be happy to put the stuff I put in this email up there if you think it 
would help.  Or if you have wording suggestions?

But any official proclamation that includes something like "this version will 
be maintained until this date" or "feature X will be in version X" we put up 
there would be at least a half-lie or a guess.  The folks who want long-term 
certainty will need to purchase it, as they do with any open source projects.

- C

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] repoze.bfg 1.1.1 released

[Chris McDonough]

repoze.bfg 1.1.1 has been released

Install via:

easy_install -i http://dist.repoze.org/bfg/1.1/simple repoze.bfg

The docs at http://docs.repoze.org/bfg/1.1 have been updated.

This is a pure bugfix release.  The changelog follows:

1.1.1 (2009-11-21)
==

Bug Fixes
-

- "Hybrid mode" applications (applications which explicitly used
   traversal *after* url dispatch via  paths containing the
   ``*traverse`` element) were broken in 1.1-final and all 1.1 alpha
   and beta releases.  Views registered without a ``route_name`` route
   shadowed views registered with a ``route_name`` inappropriately.
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] repoze.bfg 1.1 final released

[Chris McDonough]

repoze.bfg 1.1 has been released.  You can install it via:

 easy_install -i http://dist.repoze.org/bfg/current/simple repoze.bfg

Or via PyPI.

The "What's New In repoze.bfg 1.1" document details the changes made since the 
1.0 release:  http://docs.repoze.org/bfg/1.1/whatsnew-1.1.html

The docs at http://docs.repoze.org/bfg/1.1 have been updated.

The changelog from the prior 1.1b4 release follows:

1.1 (2009-11-15)


Internals
-

- Remove dead IRouteRequirement interface from ``repoze.bfg.zcml``
   module.

Documentation
-

- Improve the "Extending an Existing Application" narrative chapter.

- Add more sections to the "Defending Design" chapter.

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] About location-aware object in Traversal

[Chris McDonough]

Hey Tim,

You'll want to subscribe your gmail.com address to the list if you want these 
emails to make it to the list.

Forwarding this one for you.

- C

Tim Hoffman wrote:
> HI George
> 
> Glad you found it, I didn't know if what I was saying was particularly
> of interest so didn't bother with the link.
> Have a look in pages.models, specifically FolderishMixin, Folder, and
> QueryView and StaticList for some examples.
> 
> That code is going through a lot of changes at the moment and is the
> foundation for a fairly large project at the moment,
> as I mention on the site somewhere, once we finish that project I will
> be re-packaging all of bfg-pages into something a bit more useable
> 
> We are actually using it in conjunction with Plone - most of the
> authoring content is being done in plone and then published
> to appengine.  And we are using solr for the text search.
> 
> See ya
> 
> Tim
> 
> 
>>> Hi Tim
>>>
>>> These are eye-opener cases for me, would you gimme the address of code
>>> repository so I can get the details?
>>>
>>> Thanks
>>>
>>> George Hu
>>>
>> Well, I got it, http://code.google.com/p/bfg-pages
>>
>> Thanks
>>
>> George Hu
>>

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] About location-aware object in Traversal

[Chris McDonough]

Resending this because it was discarded by Mailman (sent from an unsubscribed 
address, apparently).

- C

Tim Hoffman wrote:
> HI George
> 
> You can really have a number of ways of supporting traversal and
> __name__, __parent__
> 
> I am running repoze.bfg on app engine to implement a simple cms which models a
> folder/page heirarchy.
> 
> In this case the parent child relationship is held in the data
> representing the instances
> (ie the parent holds a list of datastore keys of children and the
> names of the children)
> than as we traverse done the folder path, the __getitem__ in the parent folder
> actually sets __parent__ on object retrieval (non persistently). (In
> gae you can't make properties with __ be
> persistent in the datastore whith its hi-level api), so __name__ is a
> @property that actually is a method (most of the time)
> that fetchs the "name" property of the entity.
> 
> I have a seperate case also where I have query objects (think stored
> queries or collections/topics in plone)
> When we do a search for an entity in the datastore, the search object
> can, when retrieving an entity
> found, chose to set __parent__ if I want that entity to look as if it
> lives in the context of the query object
> rather than generating a link to the object where it lives in the
> folder heirarchy.
> 
> Rgds
> 
> T
> 
> 
> 
> 
> On Sat, Nov 14, 2009 at 6:19 AM, george hu  wrote:
>> As BFG document stated, all the object instances of model graph in Traversal
>> must have __name__ and __parent__ attribute, and they should be
>> hierarchically "linked". As the traversal wiki example reveals, page objects
>> are implementing this rule. But when I look at the source code of bfgsite,
>> I can't see the rule is followed. The WebSite is the root object so it has
>> __name__=__parent__=None, but none of it's sub objects (PasteBin/PasteEntry,
>> TutorialBin/Tutorial) has code of assigning __name__ and __parent__, neither
>> in object initializing nor object adding part, and I don't find the usage of
>> traversalwrapper as mentioned in document, in which case we can avoid mange
>> location aware objects "by hand". So is it a rule of "Must"?
>>
>> ___
>> 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] About location-aware object in Traversal

[Chris McDonough]

george hu wrote:
> As BFG document stated, all the object instances of model graph in 
> Traversal must have __name__ and __parent__ attribute, and they should 
> be hierarchically "linked". As the traversal wiki example reveals, page 
> objects are implementing this rule. But when I look at the source code 
> of bfgsite,  I can't see the rule is followed. The WebSite is the root 
> object so it has __name__=__parent__=None, but none of it's sub objects 
> (PasteBin/PasteEntry, TutorialBin/Tutorial) has code of assigning 
> __name__ and __parent__, neither in object initializing nor object 
> adding part, and I don't find the usage of traversalwrapper as mentioned 
> in document, in which case we can avoid mange location aware objects "by 
> hand". So is it a rule of "Must"?

It's not a complete must, but if you want the repoze.bfg.url.model_url API to 
work, these attribute must be assigned.

bfgite uses repoze.folder.Folder, which assigns these attributes at __setitem__ 
time, that's why you don't see these assignments in the bfgsite package itself.

There's an alternate BFG "traverser" implementation which wraps traversed 
objects in proxies.  It prevents you from needing to think about this, at the 
cost of decreased performance and more dependencies: 
http://pypi.python.org/pypi/repoze.bfg.traversalwrapper

- C

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] repoze.bfg 1.1b4 released

[Chris McDonough]

repoze.bfg 1.1b4 has been released.  You can install it via:

easy_install -i http://dist.repoze.org/bfg/dev/simple repoze.bfg

Or via PyPI.

The docs at http://docs.repoze.org/bfg/1.1 have been updated.

The changelog follows:

1.1b4 (2009-11-12)
==

Bug Fixes
-

- Use ``alsoProvides`` in the urldispatch module to attach an
   interface to the request rather than ``directlyProvides`` to avoid
   disturbing interfaces set in a NewRequest event handler.

Documentation
-

- Move 1.0.1 and previous changelog to HISTORY.txt.

- Add examples to ``repoze.bfg.url.model_url`` docstring.

- Add "Defending BFG Design" chapter to frontpage docs.

Templates
-

- Remove ``ez_setup.py`` and its import from all paster templates,
   samples, and tutorials for ``distribute`` compatibility.  The
   documentation already explains how to install virtualenv (which will
   include some ``setuptools`` package), so these files, imports and
   usages were superfluous.

Deprecations


- The ``options`` kw arg to the ``repoze.bfg.router.make_app``
   function is deprecated.  In its place is the keyword argument
   ``settings``.  The ``options`` keyword continues to work, and a
   deprecation warning is not emitted when it is detected.  However,
   the paster templates, code samples, and documentation now make
   reference to ``settings`` rather than ``options``.  This
   change/deprecation was mainly made for purposes of clarity and
   symmetry with the ``get_settings()`` API and dicussions of
   "settings" in various places in the docs: we want to use the same
   name to refer to the same thing everywhere.
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue31] New blog backend

[Chris McDonough]

Chris McDonough  added the comment:

We rolled our own finally.

--
status: done-cbb -> resolved

__
Repoze Bugs 
<http://bugs.repoze.org/issue31>
__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue9] repoze.grok: create 'addgrokapp' script

[Chris McDonough]

Chris McDonough  added the comment:

dead.

--
status: chatting -> resolved

__
Repoze Bugs 
<http://bugs.repoze.org/issue9>
__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue8] repoze.grok: create 'addgrokuser' script

[Chris McDonough]

Chris McDonough  added the comment:

Dead.

--
status: chatting -> resolved

__
Repoze Bugs 
<http://bugs.repoze.org/issue8>
__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue98] repoze.who Identifier Issue

[Chris McDonough]

Chris McDonough  added the comment:

For the record, in repoze.who 1.1, the userid string gets base64 encoded in the 
cookie so this 
should not be a problem.  Old cookies continue to work via a b/c shim.  I'm 
going to close this 
issue as a result.

--
status: chatting -> resolved

__
Repoze Bugs 
<http://bugs.repoze.org/issue98>
__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue102] PluggableAuthenticationMiddleware throws exception on challenge()

[Chris McDonough]

Chris McDonough  added the comment:

This is fixed in the trunk and will be available in the 1.1 release; thanks for 
the report!

--
status: unread -> resolved

__
Repoze Bugs 
<http://bugs.repoze.org/issue102>
__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue104] AuthTktCookiePlugin deconnection doesn't work with Opera

[Chris McDonough]

Chris McDonough  added the comment:

Closing.

--
status: chatting -> resolved

__
Repoze Bugs 
<http://bugs.repoze.org/issue104>
__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] object graph traversal question

[Chris McDonough]

F. Oliver Gathmann wrote:
> I am really impressed by the number and quality of the comments I got on 
> my little newbie question! Seems we made the right choice by basing our 
> new server framework on repoze.bfg ;-)

Sure, it was a great question that isn't really covered by the docs.  Hopefully 
BFG works out for you.

- C

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] object graph traversal question

[Chris McDonough]

F. Oliver Gathmann wrote:
> 
> On 11/12/09 1:00 PM, Tim Hoffman wrote:
>> Hi
>>
>> I have done some fairly extensive projects using traversal over a
>> relational model and we did use intermediate container classes alot.
>> Mainly because each major entity could have about 6 different classes
>> of sub items that we needed to group into containers anyway
>>
>> I reverse engineered the entire relational model from the existing
>> database and then autogenerated all of the intermediate classes.
>> Quite easy to do.  I was using storm as an orm over the top, which
>> made things a lot easier
> Hmm... still, this feels like an artifact to me. Presumably, in most 
> cases what you want to return when the URL asks for a collection of 
> sub-items is the very collection you already defined in your ORM on the 
> model object that is the current context (we are using SQLAlchemy, BTW). 
> I cannot help but think that there should be a way to automatically 
> return an adapted collection that supports further traversal if 
> necessary... but I'm not sure of all the ramifications of that idea.

I suspect there should be a pattern for this.  This pattern might be a good 
one, though I don't know to what extent it can be generalized:

class TraversableCollection(object):
 def __init__(self, parent, name, collection):
 self.__parent__ = parent
 self.__name__ = name
 self.collection = collection

 def __getitem__(self, name):
 return getattr(self.collection, name) # or whatever the API is

class Cars(object):
 def __getitem__(self, name):
 collection = get_collection(model, name) # some helper thing
 return TraversableCollection(self, name, collection)

Might be generalizable via a subclass:

class Collection(object):
 def __getitem__(self, name):
 collection = get_collection(model, name) # some helper thing
 return self.collection_class(self, name, collection)

class Cars(Collection):
 collection_class = TraversableCollection

Or via Zope-style adaptation.

- C

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] object graph traversal question

[Chris McDonough]

F. Oliver Gathmann wrote:
> Hello!
> 
> Coming from Pylons, I'm a newbie to the object graph traversal world, so 
> this question might be slightly misplaced (but hopefully a no-brainer 
> for the bfg gurus...).
> 
> I very much like the concept of looking up my model object before 
> dispatching to a view that operates on it. However, what bothers me 
> about the standard traversal algorithm is that, for a URL like
> 
> /cars/beetle/wheels/front_left
> 
> I have to promote the containers ("cars" and "wheels") to first class 
> citizens in my model (by defining CarContainer and WheelContainer 
> classes that I can then instantiate and return as the context object 
> from the parent's __getitem__), where in fact they are just collections 
> held by their mutual parent model objects (the Root object in case of 
> the cars collection - which is in itself artificial, but I'm willing to 
> pay that price for traversability - and the Car object in case of the 
> wheels collection).

Great question.

The short answer is "yes, you have to define the intermediate artificial 
objects if you want to use traversal".

There are number of ways to conceptualize this.

The first way would be to not consider this a traversal problem at all and do 
it as you might in Pylons by registering a route that had static parts and 
dynamic parts:



Then the URL to a wheel model might be:

/cars/beetle/front_wheel

You can choose to inject a "wheels" collection in there too should you want, 
but since objects have a type in this setup, it's not strictly necessary.

The paster template closest to this model is "bfg_alchemy" (or "bfg_zodb" but 
that uses ZODB rather than SQL).

Those are the two sanest ways to do this.  There's another mode that combines 
both traversal and url dispatch (routes), but I don't think it helps much here.

Malthe suggested that you can also use request.subpath.  This is the 
"remainder" of the path (as a tuple) when a traversal falls off the graph. 
Another (much cruder) way to getting this done would be to one root model and a 
single view and use request.subpath as a cue to that view about "what needs to 
be done".  You could of course have a "cars" model that resolved a car and a 
view against the car, then use the remainder of the subpath to figure out which 
part to show; dialing use of request.subpath up or down in length.

> 
> I guess I'm asking if there is a standard, "bfg-approved" way of 
> avoiding artificial container model classes - or did I just "not get it" 
> yet?!

No, you got it.

- C

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue36] editing a file in ZMI fails

[Chris McDonough]

Chris McDonough  added the comment:

Long dead.

--
status: chatting -> resolved

__
Repoze Bugs 
<http://bugs.repoze.org/issue36>
__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue20] Word-wrapping in roundup is awful

[Chris McDonough]

Chris McDonough  added the comment:

Filed under "replace bugtracker at some point". ;-)

--
status: chatting -> resolved

__
Repoze Bugs 
<http://bugs.repoze.org/issue20>
__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue26] traceback attempting to edit an image in plone

[Chris McDonough]

Chris McDonough  added the comment:

Long dead.

--
status: chatting -> resolved

__
Repoze Bugs 
<http://bugs.repoze.org/issue26>
__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue93] bfg_alchemy tests broken

[Chris McDonough]

Chris McDonough  added the comment:

Get this off the open bugs list.

--
status: done-cbb -> resolved

__
Repoze Bugs 
<http://bugs.repoze.org/issue93>
__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue97] Macro support for repoze.bfg.jinja2

[Chris McDonough]

Chris McDonough  added the comment:

In the meantime, we've made repoze.bfg.jinja2 0.5 (available from pypi) provide 
macro support in 
a slightly different way.  Thanks for the patches, however!

--
status: chatting -> resolved

__
Repoze Bugs 
<http://bugs.repoze.org/issue97>
__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue94] Can't start shell in bfg_alchemy or bfg_routesalchemy projects

[Chris McDonough]

Chris McDonough  added the comment:

Get this off the open bugs list.

--
status: done-cbb -> resolved

__
Repoze Bugs 
<http://bugs.repoze.org/issue94>
__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue105] View resolution ordering differences between BFG 1.1a8 and 1.1b3

[Chris McDonough]

Chris McDonough  added the comment:

This turned out to be an application issue, not a framework issue.

--
status: in-progress -> resolved

__
Repoze Bugs 
<http://bugs.repoze.org/issue105>
__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue105] View resolution ordering differences between BFG 1.1a8 and 1.1b3

[Chris McDonough]

Chris McDonough  added the comment:

I cant replicate this with the following configuration on 1.1b3:

In views.py:
---

from webob import Response

def my_view(context, request):
return {'project':'starter'}

def one(context, request):
return Response('one')

def two(context, request):
return Response('two')

In configure.zcml:
-

http://namespaces.repoze.org/bfg";>

  
  

  
  
  

  
  
  
  



No matter where I move the "" line, I 
get the "right" 
answer from the webserver.

Also, for the record, no multiviews are ever registered in this configuration 
(in the zcml handler, 
"old_view" is always None).

I don't understand the issue yet.

__
Repoze Bugs 
<http://bugs.repoze.org/issue105>
__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue105] View resolution ordering differences between BFG 1.1a8 and 1.1b3

[Chris McDonough]

New submission from Chris McDonough :

mcdonc: so malthe wrt this difference between 1.1a8 and 1.1b3, can you send me 
some 
sample view config zcml so i can figure out wtf happened because i cant see 
anything obvious 
in the changelong
[5:00pm] malthe: mcdonc: http://pastie.org/692761
[5:00pm] malthe: if I switch the order, it breaks.
[5:00pm] malthe: the "general" view is taken over the one that names a 
``route_name``, even if 
the request has the interface of that route.
[5:02pm] mcdonc: thanks
[5:02pm] malthe: i tried to test it, but everything just passed
[5:02pm] malthe: let me send you the diff
[5:03pm] malthe: mcdonc: http://pastebin.com/m10e658b6
[5:04pm] mcdonc: k

--
assignedto: chrism
messages: 297
nosy: chrism
priority: bug
status: in-progress
title: View resolution ordering differences between BFG 1.1a8 and 1.1b3

__
Repoze Bugs 
<http://bugs.repoze.org/issue105>
__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] Question about repoze.bfg.formish

[Chris McDonough]

george hu wrote:
> Where should I put the css for the formish widgets?

To be honest, I dont really have a good answer.  I ported all that stuf more or 
less mechanically from mako.  I guess just make them resolve using a  
directive in ZCML.  Basically, wherever the CSS is used, it specifies a URL, 
make the URL resolve.

- C


> 
> 
> 
> 
> ___
> 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] Using bfgshell with a ZODB based project.

[Chris McDonough]

Steve Schmechel wrote:
I caught that from advice you gave on another post and that was 
exactly the command from the second example in my original post.


Unfortunately, that does not work either.

(Ref: http://www.mail-archive.com/repoze-dev@lists.repoze.org/msg01422.html It may have worked for George Hu, but he never 
replied back.  He appears to be using some sort of SQL database.)


I am new to BFG, but I am trying to do my research before I ask a 
question.


Sorry, I didn't see Steve's second example.

This was actually a BFG bug.  I'm attaching a patch that will compile against 
1.1b2 to this mail; 1.1b3 (or 1.1 final, if we don't manage another beta) will 
have this patch in it.


Thanks!

- C

Index: repoze/bfg/scripting.py
===
--- repoze/bfg/scripting.py (revision 6933)
+++ repoze/bfg/scripting.py (working copy)
@@ -1,4 +1,6 @@
-def get_root(app, environ=None):
+from repoze.bfg.request import FakeRequest
+
+def get_root(app, request=None):
 """ Return a tuple composed of ``(root, closer)`` when provided a
 ``repoze.bfg.router.Router`` instance as the ``app`` argument.
 The ``root`` returned is the application root object.  The
@@ -8,13 +10,13 @@
 environment passed to the BFG application root factory.  An empty
 environ is constructed and passed to the root factory if
 ``environ`` is None."""
+if request is None:
+request = FakeRequest({})
 registry = app.registry
-threadlocals = {'registry':registry, 'request':None}
+threadlocals = {'registry':registry, 'request':request}
 app.threadlocal_manager.push(threadlocals)
-if environ is None:
-environ = {}
-def closer(environ=environ): # keep environ alive via this function default
+def closer(request=request): # keep request alive via this function default
 app.threadlocal_manager.pop()
-root = app.root_factory(environ)
+root = app.root_factory(request)
 return root, closer
 
Index: repoze/bfg/traversal.py
===
--- repoze/bfg/traversal.py (revision 6933)
+++ repoze/bfg/traversal.py (working copy)
@@ -14,6 +14,7 @@
 
 from repoze.bfg.location import lineage
 from repoze.bfg.encode import url_quote
+from repoze.bfg.request import FakeRequest
 
 def find_root(model):
 """ Find the root node in the graph to which ``model``
@@ -631,8 +632,3 @@
 def _join_path_tuple(tuple):
 return tuple and '/'.join([quote_path_segment(x) for x in tuple]) or '/'
 
-class FakeRequest(dict):
-def __init__(self, environ):
-self.environ = environ
-self.update(environ)
-
Index: repoze/bfg/tests/test_scripting.py
===
--- repoze/bfg/tests/test_scripting.py  (revision 6933)
+++ repoze/bfg/tests/test_scripting.py  (working copy)
@@ -1,29 +1,29 @@
 import unittest
 
 class TestGetRoot(unittest.TestCase):
-def _callFUT(self, app, environ=None):
+def _callFUT(self, app, request=None):
 from repoze.bfg.paster import get_root
-return get_root(app, environ)
+return get_root(app, request)
 
-def test_it_noenviron(self):
+def test_it_norequest(self):
 app = DummyApp()
 root, closer = self._callFUT(app)
 self.assertEqual(len(app.threadlocal_manager.pushed), 1)
 pushed = app.threadlocal_manager.pushed[0]
 self.assertEqual(pushed['registry'], dummy_registry)
-self.assertEqual(pushed['request'], None)
+self.assertEqual(pushed['request'].environ, {})
 self.assertEqual(len(app.threadlocal_manager.popped), 0)
 closer()
 self.assertEqual(len(app.threadlocal_manager.popped), 1)
 
-def test_it_withenviron(self):
+def test_it_withrequest(self):
 app = DummyApp()
-environ = {}
-root, closer = self._callFUT(app, environ)
+request = DummyRequest({})
+root, closer = self._callFUT(app, request)
 self.assertEqual(len(app.threadlocal_manager.pushed), 1)
 pushed = app.threadlocal_manager.pushed[0]
 self.assertEqual(pushed['registry'], dummy_registry)
-self.assertEqual(pushed['request'], None)
+self.assertEqual(pushed['request'], request)
 self.assertEqual(len(app.threadlocal_manager.popped), 0)
 closer()
 self.assertEqual(len(app.threadlocal_manager.popped), 1)
@@ -54,3 +54,7 @@
 def pop(self):
 self.popped.append(True)
 
+class DummyRequest:
+def __init__(self, environ):
+self.environ = environ
+
Index: repoze/bfg/tests/test_traversal.py
===
--- repoze/bfg/tests/test_traversal.py  (revision 6933)
+++ repoze/bfg/tests/test_traversal.py  (working copy)
@@ -970,23 +970,6 @@
 self.assertEqual(result['view_name'], '')
 self.assertEqual(r

Re: [Repoze-dev] Using bfgshell with a ZODB based project.

[Chris McDonough]

Steve Schmechel wrote:
> Is there a proper way to invoke bfgshell in a ZODB project?
> (The code and configuration I am using is exactly from the tutorial 
> and everything else works fine.)

The last argument you pass, "main" needs to change.. it needs to match the name 
of the "app" section in the ini file.  The .ini file generated for ZODB 
projects has an app section that looks something like:

[app:zodb]
use = egg:bfgzodb#app
reload_templates = true
debug_authorization = false
debug_notfound = false
zodb_uri = file://%(here)s/Data.fs?connection_cache_size=2

Therefore, for projects generated using the ZODB template, this name is "zodb".

$ bin/paster --plugin=repoze.bfg bfgshell tutorial.ini zodb

- C

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] Package naming

[Chris McDonough]

Graham Dumpleton wrote:
> 
> On Nov 3, 8:33 am, Malthe Borch  wrote:
>> 2009/11/2 Martin Aspeli :
>>
>>> I think it's better to use top-level namespaces to indicate ownership,
>>> if nothing else to avoid the chance of things clashing. For the repoze
>>> project to "claim" the wsgi.* namespace seems both a bit presumteuous
>>> and clash-prone.
>> It does not a claiming of a namespace, it's a usage. Obviously other
>> parties are free to use it too.
> 
> If you are talking about package/module naming then no others aren't
> really free to use it. Once someone uses it, becomes impossible for
> others to use it, including the Python distribution itself or any
> package which comes out of any specifications/standards based process
> from the Python WEB-SIG. Even in other contexts it would be a bad
> idea.
> 
> So, leave unadorned 'wsgi' specifically for Python WEB-SIG and any
> standards associated with original WSGI PEP 333. One should even avoid
> quite generic variations on the name, ie. prefixes or suffixes added,
> as again the Python WEB-SIG can also seen to have some prior/higher
> rights on those as well.

While I'm not the arbiter of prior art wrt to the "wsgi" namespace, I do agree 
that if you don't want to use the repoze namespace, don't use it.

- C

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] Package naming

[Chris McDonough]

Nathan Van Gheem wrote:
> Hello all,
> 
> I realize my opinion may not matter very much, but as one who uses many 
> of the repoze packages often, I often wondered why the repoze namespace 
> was used for many of the packages.

Because we're lazy and unoriginal.  And we like being able to name a package:

   repoze.cms

Rather than needing to come up with a name like:

   PhantasmaCMS

> I am of the opinion that it hurts the potential adoption of some of the 
> great packages and is a little misleading in some cases.

It does, and it is.

> So I am in agreement with Malthe on this. I have thought the very same 
> thing he is talking about here often.

TBH, I'm not really very worried about it for middleware packages and such. 
For larger things like BFG, yeah.  But we have bw compat concerns, and so on 
and so on.  So.. it is what it is.

- C

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] repoze.bfg 1.1b2 released

[Chris McDonough]

repoze.bfg 1.1b2 has been released.  Yes, I know the releases have been coming 
at an unreasonable pace, sorry.

You can install it via:

easy_install -i http://dist.repoze.org/bfg/1.1/simple repoze.bfg

*or*, now that I've worked out a niggling bug that made installing it from PyPI 
  a bit painful, you can use PyPI rather than the dist.repoze.org index:

easy_install repoze.bfg

The docs at http://docs.repoze.org/bfg/1.1 have been updated.

This release has the following major features:

- PyPI installation fixed

- A "What's New In BFG 1.1" document:
   http://docs.repoze.org/bfg/1.1/whatsnew-1.1.html

- Depend on repackaged "Chameleon" distribution rather than individual
   chameleon.core and chameleon.zpt packages.

The detailed changelog follows:

1.1b2 (2009-11-02)
==

Bug Fixes
-

- Prevent PyPI installation failure due to ``easy_install`` trying way
   too hard to guess the best version of Paste.  When ``easy_install``
   pulls from PyPI it reads links off various pages to determine "more
   up to date" versions. It incorrectly picks up a link for an ancient
   version of a package named "Paste-Deploy-0.1" (note the dash) when
   trying to find the "Paste" distribution and somehow believes it's
   the latest version of "Paste".  It also somehow "helpfully" decides
   to check out a version of this package from SVN.  We pin the Paste
   dependency version to a version greater than 1.7 to work around
   this ``easy_install`` bug.

Documentation
-

- Fix "Hybrid" narrative chapter: stop claiming that 
   statements that mention a route_name need to come afer (in XML
   order) the  statement which creates the route.  This
   hasn't been true since 1.1a1.

- "What's New in ``repoze.bfg`` 1.1" document added to narrative
   documentation.

Features


- Add a new event type: ``repoze.bfg.events.AfterTraversal``.  Events
   of this type will be sent after traversal is completed, but before
   any view code is invoked.  Like ``repoze.bfg.events.NewRequest``,
   This event will have a single attribute: ``request`` representing
   the current request.  Unlike the request attribute of
   ``repoze.bfg.events.NewRequest`` however, during an AfterTraversal
   event, the request object will possess attributes set by the
   traverser, most notably ``context``, which will be the context used
   when a view is found and invoked.  The interface
   ``repoze.bfg.events.IAfterTraversal`` can be used to subscribe to
   the event.  For example::

 

   Like any framework event, a subscriber function should expect one
   parameter: ``event``.

Dependencies


- Rather than depending on ``chameleon.core`` and ``chameleon.zpt``
   distributions individually, depend on Malthe's repackaged
   ``Chameleon`` distribution (which includes both ``chameleon.core``
   and ``chameleon.zpt``).

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] repoze.bfg 1.1b1 released

[Chris McDonough]

Graham Dumpleton wrote:
> 
> On Nov 2, 9:17 am, Chris McDonough  wrote:
>> repoze.bfg 1.1b1 has been released.
>>
>> ...
>>
>> - If a BFG app that had a route matching the root URL was mounted
>>under a path in modwsgi, ala ``WSGIScriptAlias /myapp
>>/Users/chrism/projects/modwsgi/env/bfg.wsgi``, the home route (a
>>route with the path of ``'/'`` or ``''``) would not match when the
>>path ``/myapp`` was visited (only when the path ``/myapp/`` was
>>visited).  This is now fixed: if the urldispatch root factory notes
>>that the PATH_INFO is empty, it converts it to a single slash before
>>trying to do matching.
> 
> Hmmm, not sure if that sounds right. Internally adding in a slash like
> that can possibly stuff up relative URLs generated in that page in as
> much as browser will interpret them incorrectly.

The change log entry was worded badly.  The code I added doesn't actually 
mutate PATH_INFO or SCRIPT_NAME (or any environment value), and it doesn't 
effect URL generation in any way or do any redirection; it just adjusts an 
internal value used only within the scope of a method.  This value is used as 
input to the route matching code.

Mapping '' to '/' internally in this way was just easier than changing the 
route matching code itself.  The change log entry should probably have read 
something like this:

- Changed route matching code to deal properly with empty PATH_INFO.

> For example, if browser requested '/myapp' and that page had relative
> URL 'page.html' where you expected browser to interpret that as '/
> myapp/page.html', you will be disappointed as browser will instead
> interpret it as '/page.html'.
> 
> Normally one would send a redirect back to the browser to tell it to
> request again with the trailing slash added. This way the browser is
> aware of the correct base URL and so relative URLs in the response
> will work properly.
> 
> That said, I know nothing about how your stuff works, so what I say
> may not be relevant in your system.

Thanks.  You're right to be suspicious given the wording in the changelog.

- C
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] repoze.bfg 1.1b1 released

[Chris McDonough]

repoze.bfg 1.1b1 has been released.

It may be installed via:

   easy_install -i http://dist.repoze.org/bfg/1.1/simple repoze.bfg

The docs at http://docs.repoze.org/bfg/1.1 have been updated.

This is the first beta release in the 1.1 series.  It is only bugfixes.

The changelog is as follows:

1.1b1 (2009-11-01)
==

Bug Fixes
-

- The routes root factory called route factories and the default route
   factory with an environ rather than a request.  One of the symptoms
   of this bug: applications generated using the ``bfg_zodb`` paster
   template in 1.1a9 did not work properly.

- Reinstate ``renderer`` alias for ``view_renderer`` in the
    ZCML directive (in-the-wild 1.1a bw compat).

- ``bfg_routesalchemy`` paster template: change 
   declarations: rename ``renderer`` attribute to ``view_renderer``.

- Header values returned by the ``authtktauthenticationpolicy``
   ``remember`` and ``forget`` methods would be of type ``unicode``.
   This violated the WSGI spec, causing a ``TypeError`` to be raised
   when these headers were used under ``mod_wsgi``.

- If a BFG app that had a route matching the root URL was mounted
   under a path in modwsgi, ala ``WSGIScriptAlias /myapp
   /Users/chrism/projects/modwsgi/env/bfg.wsgi``, the home route (a
   route with the path of ``'/'`` or ``''``) would not match when the
   path ``/myapp`` was visited (only when the path ``/myapp/`` was
   visited).  This is now fixed: if the urldispatch root factory notes
   that the PATH_INFO is empty, it converts it to a single slash before
   trying to do matching.

Documentation
-

- In  declarations in tutorial ZCML, rename ``renderer``
   attribute to ``view_renderer`` (fwd compat).

- Fix various tutorials broken by 1.1a9  directive changes.

Internal


- Deal with a potential circref in the traversal module.
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] SQLAlchemy and Traversal

[Chris McDonough]

It looks ok to me, at least to the extent that I don't know if there one way of 
implementing __getitem__ is better than any other for purposes of traversal, 
as long as it returns the right answer.

- C

Nikos Papagrigoriou wrote:
> Hi everyone,
> 
> I used the bfg_alchemy paster template to create a default project  
> with Traversal and SQLAlchemy. This gave me an initial insight on how  
> to use traversal with an ORM and support URLs like 
> http://example.com/projects/{project_id}.
> 
> In order to support something like:
> 
>   - http://example.com/tasks (all the tasks)
>   - http://example.com/projects/{project_id}/tasks (all the tasks by  
> project)
>   - http://example.com/projects/{project_id}/tasks/{task_id}
> 
> where projects/tasks are collections of resources and {projects_id}/ 
> {task_id} represents one particular project resource, I came up with  
> the following idea:
> 
>   - Create SQLAlchemy aware containers that expect a DBSession and  
> "filter_by" keyword arguments.
>   - Adapt the contained items when there are subordinate containers.
> 
> Of course I could just make a contained item (e.g. a project resource)  
> traversable and avoid the adaption but I wanted to keep the individual  
> resources unaware from the fact that the current application framework  
> supports traversal (which I actually like a lot :-) ). Besides with  
> adaption the subordinate contents of one resource may vary based on  
> the parent container.
> 
> I am enclosing part of the code but you can download an experimental  
> application from http://dl.getdropbox.com/u/260650/bfg_alchemy.zip  
> (temporary location)
> 
> Do you think my approach makes sense or is it too complicated?
> 
> Cheers,
> 
> Nikos.
> 
> -- example code  
> --
> 
> class TraversableMapping(Contained):
>  implements(ITraversable)
> 
>  title = u''
>  description = u''
> 
>  def __init__(self):
>  self._contents = self._create_contents()
>  for name in self._contents:
>  locate(self._contents[name], self, name)
> 
>  def __getitem__(self, key):
>  return self._contents[key]
> 
>  def get(self, key, default=None):
>  return self._contents.get(key, default)
> 
>  def items(self):
>  return self._contents.items()
> 
>  def iteritems(self):
>  return self._contents.iteritems()
> 
>  def values(self):
>  return self._contents.values()
> 
>  def itervalues(self):
>  return self._contents.itervalues()
> 
>  def __len__(self):
>  return len(self._contents)
> 
>  def _create_contents(self):
>  raise NotImplementedError
> 
> 
> class TraversableEntity(Contained):
>  implements(ITraversable)
> 
>  _entity = None
> 
>  def __init__(self, db_session, **filters):
>  self.__db_session = db_session
>  self.__filters = filters
> 
>  def __getitem__(self, key):
>  try:
>  key = int(key)
>  except (ValueError, TypeError):
>  raise KeyError(key)
>  query = self._query.filter_by(id=key)
>  try:
>  item = query.one()
>  except NoResultFound:
>  raise KeyError(key)
>  else:
>  item = queryMultiAdapter((self, item), default=item)
>  locate(item, self, key)
>  return item
> 
>  def __len__(self):
>  return self._query.count()
> 
>  def get(self, key, default=None):
>  try:
>  item = self.__getitem__(key)
>  except KeyError:
>  item = default
>  return item
> 
>  def items(self):
>  result = []
>  for obj in self._query.all():
>  locate(obj, self, obj.id)
>  result.append((obj.id, obj))
>  return result
> 
>  def iteritems(self):
>  for obj in self._query:
>  locate(obj, self, obj.id)
>  yield (obj.id, obj)
> 
>  def values(self):
>  result = []
>  for obj in self._query.all():
>  locate(obj, self, obj.id)
>  result.append(obj)
>  return result
> 
>  def itervalues(self):
>  for obj in self._query:
>  locate(obj, self, obj.id)
>  yield obj
> 
>  @property
>  def _query(self):
>  session = self.__db_session()
>  query = session.query(self._entity)
>  if len(self.__filters) > 0:
>  query = query.filter_by(**self.__filters)
>  return query
> 
> 
> class TraversableProject(TraversableMapping):
>  implements(IProject)
>  adapts(IProjectContainer, IProject)
> 
>  def __init__(self, parent, child):
>  self._parent = parent
>  self._child = child
>  self.title = self._child.title
>  self.description = self._child.description
>  TraversableMapping.__init__(self)
> 
>  

[Repoze-dev] BFG 1.1 / 2.X roadmap

[Chris McDonough]

Here's what's going to happen with BFG in the next few months:

- BFG 1.1 will be released.  This will happen fairly soon, hopefully within
   the next two weeks or so.

- After BFG 1.1 is released, work will begin on BFG 2.0.

- A small amount of backwards compatibility shedding will occur in BFG 2.0,
   but applications which do not use ZCML "hooks" and which use only documented
   APIs should run unchanged.  This is the goal, in any case.

- The 1.X series and 2.X series will be maintained in parallel for the
   foreseeable future.  For instance, there will almost certainly be
   a BFG 1.2, a BFG 1.3, etc.  However, changes made to the code in the
   1.X series will be more likely to be bugfixes and forward compatibility
   changes than ambitious feature addititions.

I'm hopeful that we'll be collaborating more closely with folks from the Pylons 
project during the development of BFG 2.0, and that our respective projects can 
begin to share more core code than they currently do.  This will be the major 
focus of 2.0 development.

- C
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] repoze.bfg 1.1a9 released

[Chris McDonough]

repoze.bfg 1.1a9 has been released

It may be installed via:

easy_install -i http://dist.repoze.org/bfg/1.1/simple repoze.bfg

The documentation at http://docs.repoze.org/bfg/1.1/ have been updated.

This release is hopefully the last alpha release in the 1.1 series (hopefully 
only betas and a final will follow).

1.1a9 includes a number of important design changes.

- Root factories are now passed a "request" rather than a WSGI environ 
dictionary.

- Traversers are now passed a request rather than a WSGI environ dictionary.

- There is now such a thing as a "route predicate".

Note that there are no major backwards incompatibilities in passing a request 
to root factories and traversers, as the request has been equipped with a 
dictlike interface that queries and mutates the underlying environment (the 
request "acts like an environ").

The detailed changelog follows.

1.1a9 (2009-10-31)
==

Bug Fixes
-

- An incorrect ZCML conflict would be encountered when the
   ``request_param`` predicate attribute was used on the ZCML ``view``
   directive if any two otherwise same-predicated views had the
   combination of a predicate value with an ``=`` sign and one without
   (e.g. ``a`` vs. ``a=123``).

Features


- In previous versions of BFG, the "root factory" (the ``get_root``
   callable passed to ``make_app`` or a function pointed to by the
   ``factory`` attribute of a route) was called with a "bare" WSGI
   environment.  In this version, and going forward, it will be called
   with a ``request`` object.  The request object passed to the factory
   implements dictionary-like methods in such a way that existing root
   factory code which expects to be passed an environ will continue to
   work.

- The ``__call__`` of a plugin "traverser" implementation (registered
   as an adapter for ``ITraverser`` or ``ITraverserFactory``) will now
   receive a *request* as the single argument to its ``__call__``
   method.  In previous versions it was passed a WSGI ``environ``
   object.  The request object passed to the factory implements
   dictionary-like methods in such a way that existing traverser code
   which expects to be passed an environ will continue to work.

- The ZCML ``route`` directive's attributes ``xhr``,
   ``request_method``, ``path_info``, ``request_param``, ``header`` and
   ``accept`` are now *route* predicates rather than *view* predicates.
   If one or more of these predicates is specified in the route
   configuration, all of the predicates must return true for the route
   to match a request.  If one or more of the route predicates
   associated with a route returns ``False`` when checked during a
   request, the route match fails, and the next match in the routelist
   is tried.  This differs from the previous behavior, where no route
   predicates existed and all predicates were considered view
   predicates, because in that scenario, the next route was not tried.

Documentation
-

- Various changes were made to narrative and API documentation
   supporting the change from passing a request rather than an environ
   to root factories and traversers.

Internal


- The request implements dictionary-like methods that mutate and query
   the WSGI environ.  This is only for the purpose of backwards
   compatibility with root factories which expect an ``environ`` rather
   than a request.

- The ``repoze.bfg.request.create_route_request_factory`` function,
   which returned a request factory was removed in favor of a
   ``repoze.bfg.request.route_request_interface`` function, which
   returns an interface.

- The ``repoze.bfg.request.Request`` class, which is a subclass of
   ``webob.Request`` now defines its own ``__setattr__``,
   ``__getattr__`` and ``__delattr__`` methods, which override the
   default WebOb behavior.  The default WebOb behavior stores
   attributes of the request in ``self.environ['webob.adhoc_attrs']``,
   and retrieves them from that dictionary during a ``__getattr__``.
   This behavior was undesirable for speed and "expectation" reasons.
   Now attributes of the ``request`` are stored in ``request.__dict__``
   (as you otherwise might expect from an object that did not override
   these methods).

- The router no longer calls ``repoze.bfg.traversal._traverse`` and
   does its work "inline" (speed).

- Reverse the order in which the router calls the request factory and
   the root factory.  The request factory is now called first; the
   resulting request is passed to the root factory.

- The ``repoze.bfg.request.request_factory`` function has been
   removed.  Its functionality is no longer required.

- The "routes root factory" that wraps the default root factory when
   there are routes mentioned in the configuration now attaches an
   interface to the request via ``zope.interface.directlyProvides``.
   This replaces logic in the (now-gone)
   ``repoze.bfg.request.request_factory`` function.

- The ``route`` and 

Re: [Repoze-dev] Question about using repoze.bfg.formish in url dispatch

[Chris McDonough]

georgehu wrote:
> Chris McDonough wrote:
>> You need something like 
>>
> Regarding to the request.form(),  I've tried to find document explaining 
> the usage but no luck. Can you give it more explaination?
> 

There's probably nothing in the docs about it (the docs are accurate but 
incomplete currently).

The views manufactured as a result of using the  tag in ZCML 
construct a form, and a formish.Schema and some other stuff, and attach these 
variables to the request before invoking the "renderer" (the template).

These request attributes include:

form: the formish Form object

form_schema: the schemaish Schema object

form_controller: the form controller object itself

form_fields: the fields returned from the form controller form_fields method

form_actions: the formish actions implied by the ZCML

form_widgets: the widgets returned by the form controller form_widgets method

form_defaults: the data returned by the form controller form_defaults method

Please see repoze.bfg.formish.zcml.FormView for the implementation.

- C

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg + logging

[Chris McDonough]

Andreas Reuleaux wrote:
> Yes, I can have a look (not immediately though).
> Should I just provide some patches or do you
> want to give me svn write access (should I sign
> some contributor agreement)?

Either is fine, really.  The contributor agreement page at 
http://repoze.org/contributing.html

Thanks!

- C

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg + logging

[Chris McDonough]

Andreas Reuleaux wrote:
> 
> Maybe it would be good to have this in the bfg docs ?
> - I mean: just a basic example to get something running 
> and a link to this tutorial - no details of how to make
> a more complicated configuration - or is it just me,
> that didn't know of this "hidden feature" of PasteDeploy ?

Probably.  Do you think you could take a stab at changing the docs in a fashion 
that suited this problem?  (http://svn.repoze.org/repoze.bfg/trunk/docs).

- C

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg + logging

[Chris McDonough]

A "hidden feature" of PasteDeploy (the package which defines the .ini format 
for a BFG .ini file) is that you can just inject something in the .ini 
format found at e.g. http://www.red-dove.com/python_logging.html#config into 
the BFG app .ini file (literally just paste it in to the BFG app .ini file) and 
PasteDeploy will configure the logging module.  Then you can use the logging 
API to log to the loggers you've defined in the BFG config file.

Andreas Reuleaux wrote:
> I am wondering if there a any examples of using logging in bfg out
> there ?
> 
> I have about the simplest bfg web app possible (can certainly give
> more details if necessary) and have so far done some debugging by
> print, i. e.
> 
> * I call print 'blah' in views.py, models.py once in a while
> 
> * I can see the output in paster.log
> 
> but would like to replace this with something like
> 
>   import logging
>   logging.debug("blah")
> 
> or a little bit fancier (in run.py):
> 
>   import logging
>   logger = logging.getLogger("mylogger")
>   h = logging.StreamHandler()
>   h.setLevel(logging.DEBUG)
>   formatter = ...
>   h.setFormatter(formatter)
>   logger.addHandler(h)
> 
> then in views.py
> 
>   logger = logging.getLogger("mylogger")
>   logger.debug("blah")
> 
> 
> but can't see the output in my paster.log, any advice ?
> do I have to set up a wsgi pipeline just for the logging ?
> 
> Alternatively I tried to configure this in the (paster) 
> website.ini file of my app
> 
>   ...
>   [app:main]
>   use = egg:website#app
>   reload_templates = true
> 
>   log_stream = sys.stdout
>   log_level = logging.DEBUG
>   ...
> 
> (I run my app with ./bin/paster serve ./website.ini)
> - no success either: can't see any logging output
> 
> Any advice / docs / examples ?
> 
> 
> 
> 
> -Andreas
> ___
> 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] Question about using repoze.bfg.formish in url dispatch

[Chris McDonough]

Chris McDonough wrote:
> The contract for what the __call__ may return a webob Response object or a 
> dictionary.  This is the same contract as required of "views with renderers". 
> See 
> http://docs.repoze.org/bfg/1.1/narr/views.html#writing-views-which-use-a-renderer

This is maybe a better description:

http://docs.repoze.org/bfg/1.1/narr/views.html#pt-or-txt-chameleon-template-renderers

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] Question about using repoze.bfg.formish in url dispatch

[Chris McDonough]

george hu wrote:
> Now I have no problem of setting up the configure.zcml, my new problem 
> is to wiring template and form together, I think I may write something 
> in the .pt file:
> 
> AForm

You need something like 

> 
> and place something in the __call__ method of form controller. When I do 
> it in pure formish way, I use:
> 
> ...
> form=formish.Form(schema)
> return {'AForm':form()}
> 
> the __call__ of the controller is also expected to return a dictionary, 
> but what am I supposed to put into it?  I tried return 
> {'AForm':Additem(self.context,self.request)} but it doesn't work.


The contract for what the __call__ may return a webob Response object or a 
dictionary.  This is the same contract as required of "views with renderers". 
See 
http://docs.repoze.org/bfg/1.1/narr/views.html#writing-views-which-use-a-renderer

> 
> 
> On Tue, Oct 27, 2009 at 12:44 PM, Chris McDonough  <mailto:chr...@plope.com>> wrote:
> 
> Something like this might work:
> 
> 
> 
>name=""
>   route_name="add"
>   controller=".forms.AddItem"/>
> 
> george hu wrote:
> 
> I'm trying to use the repoze.bfg.formish by checking out the
> code from svn. I have configured the configure.zcml successfully
> and using formish:form directive in the file. According to the
> document, the formish:form is kind of mirror of view directive,
> now I could not figure out how to map a url to the formish:form,
> because the "view" attribute in the route directive can only be
> referred to  "a function that will be used as a view callable
> when this route matched", that is a function in "views.py". Is
> there any way to do this? Can I write something like this:
> 
>   path = "add"
>  view = "AddItem"
> 
>  >
> 
> and the AddItem is in the formish:form
> 
>   for=".models.Item"
>  name="AddItem"
>  controller=".forms.AddItem"
> ...
>  >
> 
> 
> 
> 
> 
> ___
> Repoze-dev mailing list
> Repoze-dev@lists.repoze.org <mailto: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

[Repoze-dev] repoze.bfg 1.1a8 released

[Chris McDonough]

repoze.bfg web framework 1.1a8 has been released

You can install it via:

easy_install -i http://dist.repoze.org/bfg/dev/simple repoze.bfg

The 1.1-series docs have been updated and are available at:

http://docs.repoze.org/bfg/1.1/

This release is a general mishmash of bufgixes, features, and refactorings. 
The changes that are between 1.1a7 and 1.1a8 follow:

1.1a8 (2009-10-27)
==

Features


- Add ``path_info`` view configuration predicate.

- ``paster bfgshell`` now supports IPython if it's available for
   import.  Thanks to Daniel Holth for the initial patch.

- Add ``repoze.bfg.testing.registerSettings`` API, which is documented
   in the "repoze.bfg.testing" API chapter.  This allows for
   registration of "settings" values obtained via
   ``repoze.bfg.settings.get_settings()`` for use in unit tests.

- The name ``root`` is available as an attribute of the request
   slightly earlier now (before a NewRequest event is emitted).
   ``root`` is the result of the application "root factory".

- Added ``max_age`` parameter to ``authtktauthenticationpolicy`` ZCML
   directive.  If this value is set, it must be an integer representing
   the number of seconds which the auth tkt cookie will survive.
   Mainly, its existence allows the auth_tkt cookie to survive across
   browser sessions.

Bug Fixes
-

- Fix bug encountered during "scan" (when  directive is
   used in ZCML) introduced in 1.1a7.  Symptom: ``AttributeError:
   object has no attribute __provides__`` raised at startup time.

- The ``reissue_time`` argument to the ``authtktauthenticationpolicy``
   ZCML directive now actually works.  When it is set to an integer
   value, an authticket set-cookie header is appended to the response
   whenever a request requires authentication and 'now' minus the
   authticket's timestamp is greater than ``reissue_time`` seconds.

Documentation
-

- Add a chapter titled "Request and Response" to the narrative
   documentation, content cribbed from the WebOb documentation.

- Call out predicate attributes of ZCML directive within "Views"
   chapter.

- Fix route_url documentation (``_query`` argument documented as
   ``query`` and ``_anchor`` argument documented as ``anchor``).

Backwards Incompatibilities
---

- The ``authtkt`` authentication policy ``remember`` method now no
   longer honors ``token`` or ``userdata`` keyword arguments.

Internal


- Change how ``bfg_view`` decorator works when used as a class method
   decorator.  In 1.1a7, the``scan``directive actually tried to grope
   every class in scanned package at startup time, calling ``dir``
   against each found class, and subsequently invoking ``getattr``
   against each thing found by ``dir`` to see if it was a method.  This
   led to some strange symptoms (e.g. ``AttributeError: object has no
   attribute __provides__``), and was generally just a bad idea.  Now,
   instead of groping classes for methods at startup time, we just
   cause the ``bfg_view`` decorator itself to populate the method's
   class' ``__dict__`` when it is used as a method decorator.  This
   also requires a nasty _getframe thing but it's slightly less nasty
   than the startup time groping behavior.  This is essentially a
   reversion back to 1.1a6 "grokking" behavior plus some special magic
   for using the ``bfg_view`` decorator as method decorator inside the
   ``bfg_view`` class itself.

- The router now checks for a ``global_response_headers`` attribute of
   the request object before returning a response.  If this value
   exists, it is presumed to be a sequence of two-tuples, representing
   a set of headers to append to the 'normal' response headers.  This
   feature is internal, rather than exposed externally, because it's
   unclear whether it will stay around in the long term.  It was added
   to support the ``reissue_time`` feature of the authtkt
   authentication policy.

- The interface ITraverserFactory is now just an alias for ITraverser.



___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] Question about using repoze.bfg.formish in url dispatch

[Chris McDonough]

Something like this might work:





george hu wrote:
> I'm trying to use the repoze.bfg.formish by checking out the code from 
> svn. I have configured the configure.zcml successfully and using 
> formish:form directive in the file. According to the document, the 
> formish:form is kind of mirror of view directive, now I could not figure 
> out how to map a url to the formish:form, because the "view" attribute 
> in the route directive can only be referred to  "a function that will be 
> used as a view callable when this route matched", that is a function in 
> "views.py". Is there any way to do this? Can I write something like this:
> 
>   path = "add"
>  view = "AddItem"
> 
>  >
> 
> and the AddItem is in the formish:form
> 
>for=".models.Item"
>   name="AddItem"
>   controller=".forms.AddItem"
> ...
>  >
> 
> 
> 
> 
> ___
> 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

[Repoze-dev] [issue100] Configurable character set support for repoze.who and repoze.what

[Chris McDonough]

Chris McDonough  added the comment:

I mean that I personally don't know how to change the software based on your 
suggestions so 
far in a way that adds significant value, and that if WSGI2 will handle the 
encoding and 
decoding issues, maybe this should just do something better with r.who then.  
OTOH, I'd 
encourage a set of patches against the WSGI 1 version that implement what you 
believe would 
help.

In any case, let's at least please stop talking via the bugtracker about this 
issue; it would be 
better to take it to the repoze-dev maillist or the #repoze IRC channel on 
irc.freenode.net (I am 
"mcdonc" there).

--
status: chatting -> resolved

__
Repoze Bugs 
<http://bugs.repoze.org/issue100>
__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue100] Configurable character set support for repoze.who and repoze.what

[Chris McDonough]

Chris McDonough  added the comment:

I don't think this is actionable on any realistic level within our current 
implementation.  This should 
be solved at lower layers.

--
status: chatting -> resolved

__
Repoze Bugs 
<http://bugs.repoze.org/issue100>
__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue101] AuthTktCookie should not try to decode userid based on value types

[Chris McDonough]

Chris McDonough  added the comment:

Apologies, I see no reason that the way the current authtkt plugin encodes 
userids needs to 
change.  Given that this is a plugin, if you need alternate behavior, you can 
of course copy and 
change the implementation and distribute the modified version.

--
status: chatting -> resolved

__
Repoze Bugs 
<http://bugs.repoze.org/issue101>
__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue101] AuthTktCookie should not try to decode userid based on value types

[Chris McDonough]

Chris McDonough  added the comment:

I need to take back the assumption of "monstrous, disastrous security hole" 
wrt. using the 
pickle module (or eval, as you suggest) because in this particular case, the 
cookie content is 
hashed and compared against a digest that includes a secret, so it's unlikely 
that anything not 
explicitly put into the cookie by the software will be unpickled.

On the other hand, however, for the sake of future maintainers, who may not get 
this particular 
joke (and who may end up innocently changing the code in a way that introduces 
a security 
hole), I think it's probably wise to stay clear of passing values obtained from 
a cookie (even 
though the data isn't 100% 'untrusted' due to the digest) to any Python 
function that has the 
capability to run arbitrary code based on the value that is passed to it such 
as eval or 
pickle.loads.

For the record, the current implementation already has a bug that is going to 
require us to set 
the userid value to something other than a plain unencoded bytestring anyway  
(http://bugs.repoze.org/issue98).  This will need to be fixed at some point, 
and at that point, the 
userid will become even more opaque (probably base64 encoded).

I don't understand the problem you're trying to solve by removing the type 
declaration.  As it 
stands, if the userid used by your application and passed into the plugin 
(let's say, via 
"plugin.remember") is unicode, you'll get unicode back as the value of 
environ['repoze.who.identity']['repoze.who.userid'] when there's an authtkt 
cookie present at 
ingress.  If it's an integer you pass in, you'll get an integer back.  If it's 
a bytestring, you'll get a 
bytestring back.

A 'charset' value is immaterial here: if the value is unicode, you won't need 
it; if the value is a 
bytestring, you *already* need to handle the decoding explicitly.  What am I 
missing?

__
Repoze Bugs 
<http://bugs.repoze.org/issue101>
__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue101] AuthTktCookie should not try to decode userid based on value types

[Chris McDonough]

Chris McDonough  added the comment:

The plugin does too much.  But it doesn't do so entirely stupidly: it does too 
much because 
people *wanted* it to do too much, and the casting magic is useful.  People 
wanted the value 
of environ['repoze.who.identity']['repoze.who.userid'] to be of a type that 
made sense for their 
app so they didn't have to cast the userid explictly from whatever type it is 
within their 
application (often integer or unicode; not always a bytestring) to a bytestring 
to set a "user id"; 
inversely they didn't want to have to cast the userid explicitly to the 
application type from a 
bytestring when reading it out of the identity dictionary.

I am not talking about XSS when I refer to "security hole"; XSS is unrelated.  
I was talking about 
being able to retain the above (useful) property of being able to attach a type 
declaration to the 
userid.  One way to do so would be of course to use the pickle module and just 
pickle the 
object: it would be a disastrous, monstrous security hole to unpickle data 
obtained from a 
cookie, but it would not require any type declarations in the user data.  Is 
there a better way 
that wasnt a monstrous security hole but would offend your sensibilities less?

__
Repoze Bugs 
<http://bugs.repoze.org/issue101>
__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue101] AuthTktCookie should not try to decode userid based on value types

[Chris McDonough]

Chris McDonough  added the comment:

There is support in the plugin right now for the userid as an integer, as a 
long, as a unicode 
type, and as a string; if another type should become necessary to use as a user 
id, the plugin 
allows for it.  The mechanism that turns the userid into bytes is opaque, yes, 
but it *has* to be 
if we want to allow the encoding of arbitrary types.  Given that we're 
generating a cookie value, 
and the cookie value obviously needs to be bytes, is there a better way to 
encode arbitrary 
types to a bytestring that does not open up a security hole?

__
Repoze Bugs 
<http://bugs.repoze.org/issue101>
__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue100] Configurable character set support for repoze.who and repoze.what

[Chris McDonough]

Chris McDonough  added the comment:

I believe this.

On the other hand, I'm not sure that a 'charset' setting dedicated "to 
repoze.who" or "to 
repoze.what" is really sufficient.  Who will set the charset?  What will it be 
set to?  What does it 
mean to individual plugins?  What would they need to do to "comply with the 
charset"?What 
does "holistically support" mean?  This is a bit of a minefield.

There is a fundamental lack of support at very basic levels for charset 
support.  Even HTML 
form posts don't send along the charset of the posted data: it's presumed that 
the POST data 
will be in the charset of the HTML page which contained the rendered form.  If 
your form 
handler doesn't know what that charset is, you're out of luck.  So I'm not sure 
WSGI can really 
do much here in general.

In short: what would you change, concretely to make this any better?

--
status: unread -> chatting

__
Repoze Bugs 
<http://bugs.repoze.org/issue100>
__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue101] AuthTktCookie should not try to decode userid based on value types

[Chris McDonough]

Chris McDonough  added the comment:

Thanks for the report.

So to be honest, I can't find an issue with the current strategy.  The 
mod_auth_tkt README 
actually contradicts itself here, saying in one section that it checks 
"user_data" for internal 
data, then in another section it checks "tokens" for internal data:

"""
2.4 If a TKTAuthToken is also required for this url/area, mod_auth_tkt 
will then check the first field of the user_data (which has been
checked via the MD5 checksum in the previous step) for a comma-
separated list of tokens for this user. If the required token is
not found in this list, the request is redirected to a configurable
unauthorised URL.
"""

Then later:

"""
cookie := digest + hextimestamp + user_id + '!' + token_list + '!' + user_data

token_list is an optional comma-separated list of access tokens 
for this user. This list is checked if TKTAuthToken is set for a
particular area.

user_data is optional
"""

So I'm not sure what to believe.  OTOH, fidelity with mod_auth_tkt (and being 
able to use 
mod_auth_tkt to parse r.who authtkt cookies) is not really a goal here, so even 
if the placement 
of the encoding is technically wrong, it's probably OK.

On the subject of cookie encoding if the userid is of type unicode, I don't 
quite understand 
what the issue is.  If the userid is of type unicode, we encode unicode to 
utf-8 to turn it into a 
bytestring, we put the bytestring in the cookie, then we decode it later when 
we have the 
cookie data and need the userid info back.  The mechanism we use to do this 
encoding/decoding is opaque to WSGI and opaque to the application which uses 
the plugin 
and we only do it when the userid value is unicode.  We don't encode the value 
at all if it's a 
bytestring, so if you use a bytestring as a userid, like in any encoding 
scenario, you will need to 
know its charset to decode it.  Does it really matter how the unicode smuggling 
is done?

--
status: unread -> chatting

__
Repoze Bugs 
<http://bugs.repoze.org/issue101>
__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] Predicates on routes vs views

[Chris McDonough]

Malthe Borch wrote:
> 2009/10/22 Chris McDonough :
>> Do we just need to change the path matching syntax instead to get your
>> *.html case to work?  Is there another case for predicates?
> 
> I think that in general, predicates make sense without the view on
> s. Is there anything in the way of letting them act upon
> ``route.match`` instead of ``view.predicate_checker``?

I don't think there's anything in particular in the way.  I'd like to have some 
concrete use cases before we add the code, because it could be difficult to 
document.

- C

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] Predicates on routes vs views

[Chris McDonough]

Malthe Borch wrote:
> 2009/10/22 Tres Seaver :
>> The view predicates are there to allow selecting a particular view among
>> several registered for the route or context:  e.g., to dispatch to
>> different views for GET versus POST for the same route / context and
>> view name.
> 
> It makes perfect sense with .
> 
> With , however, I think predicates make sense without
> specifying a view. And currently, predicates are silently ignored if
> you don't provide a view directly when you define a route.

Do we just need to change the path matching syntax instead to get your *.html 
case to work?  Is there another case for predicates?

- C

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] repoze.bfg 1.1a7 released

[Chris McDonough]

repoze.bfg 1.1a7 has been released.

Install via:

easy_install -i http://dist.repoze.org/bfg/dev/simple repoze.bfg

The documentation at http://docs.repoze.org/bfg has been updated.

This release is a pure feature release, there are no backwards 
incompatibilities or deprecations: "bfg_view" decorators can be used against 
class methods, and "bfg_view" decorators can now be "stacked" on any given 
method or function.  Also, some previously undocumented ZCML "hooks" have now 
been documented.

The changelog of differences from 1.1a6 follows:

Features


- More than one `...@bfg_view`` decorator may now be stacked on top of
   any number of others.  Each invocation of the decorator registers a
   single view configuration.  For instance, the following combination
   of decorators and a function will register two view configurations
   for the same view callable::

 from repoze.bfg.view import bfg_view

 @bfg_view(name='edit')
 @bfg_view(name='change')
 def edit(context, request):
 pass

   This makes it possible to associate more than one view configuration
   with a single callable without requiring any ZCML.

- The `...@bfg_view`` decorator can now be used against a class method::

 from webob import Response
 from repoze.bfg.view import bfg_view

 class MyView(object):
 def __init__(self, context, request):
 self.context = context
 self.request = request

 @bfg_view(name='hello')
 def amethod(self):
 return Response('hello from %s!' % self.context)

   When the bfg_view decorator is used against a class method, a view
   is registered for the *class* (it's a "class view" where the "attr"
   happens to be the name of the method it is attached to), so the
   class it's defined within must have a suitable constructor: one that
   accepts ``context, request`` or just ``request``.

Documentation
-

- Added ``Changing the Traverser`` and ``Changing How
   :mod:`repoze.bfg.url.model_url` Generates a URL`` to the "Hooks"
   narrative chapter of the docs.

Internal


- Remove ``ez_setup.py`` and imports of it within ``setup.py``.  In
   the new world, and as per virtualenv setup instructions, people will
   already have either setuptools or distribute.

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] repoze.bfg 1.1a6 released

[Chris McDonough]

Hi,

The repoze.bfg web framework version 1.1a6 has been released.

You can install it via:

easy_install -i http://dist.repoze.org/bfg/dev/simple repoze.bfg

Highlights: new "xhr", "accept", and "header" predicates in view directives, 
internal changes to supports the Python dictionary API against the ZCA registry 
(forward compatibility with BFG 2.0, which will be based on a system which will 
make use of this feature).

Features


- Add ``xhr``, ``accept``, and ``header`` view configuration
   predicates to ZCML view declaration, ZCML route declaration, and
   ``bfg_view`` decorator.  See the ``Views`` narrative documentation
   chapter for more information about these predicates.

- Add ``setUp`` and ``tearDown`` functions to the
   ``repoze.bfg.testing`` module.  Using ``setUp`` in a test setup and
   ``tearDown`` in a test teardown is now the recommended way to do
   component registry setup and teardown.  Previously, it was
   recommended that a single function named
   ``repoze.bfg.testing.cleanUp`` be called in both the test setup and
   tear down.  ``repoze.bfg.testing.cleanUp`` still exists (and will
   exist "forever" due to its widespread use); it is now just an alias
   for ``repoze.bfg.testing.setUp`` and is nominally deprecated.

- The BFG component registry is now available in view and event
   subscriber code as an attribute of the request
   ie. ``request.registry``.  This fact is currently undocumented
   except for this note, because BFG developers never need to interact
   with the registry directly anywhere else.

- The BFG component registry now inherits from ``dict``, meaning that
   it can optionally be used as a simple dictionary.  *Component*
   registrations performed against it via e.g. ``registerUtility``,
   ``registerAdapter``, and similar API methods are kept in a
   completely separate namespace than its dict members, so using the
   its component API methods won't effect the keys and values in the
   dictionary namespace.  Likewise, though the component registry
   "happens to be" a dictionary, use of mutating dictionary methods
   such as ``__setitem__`` will have no influence on any component
   registrations made against it.  In other words, the registry object
   you obtain via e.g. ``repoze.bfg.threadlocal.get_current_registry``
   or ``request.registry`` happens to be both a component registry and
   a dictionary, but using its component-registry API won't impact data
   added to it via its dictionary API and vice versa.  This is a
   forward compatibility move based on the goals of "marco".

- Expose and document ``repoze.bfg.testing.zcml_configure`` API.  This
   function populates a component registry from a ZCML file for testing
   purposes.  It is documented in the "Unit and Integration Testing"
   chapter.

Documentation
-

- Virtual hosting narrative docs chapter updated with info about
   ``mod_wsgi``.

- Point all index URLs at the literal 1.1 index (this alpha cycle may
   go on a while).

- Various tutorial test modules updated to use
   ``repoze.bfg.testing.setUp`` and ``repoze.bfg.testing.tearDown``
   methods in order to encourage this as best practice going forward.

- Added "Creating Integration Tests" section to unit testing narrative
   documentation chapter.  As a result, the name of the unittesting
   chapter is now "Unit and Integration Testing".

Backwards Incompatibilities
---

- Importing ``getSiteManager`` and ``get_registry`` from
   ``repoze.bfg.registry`` is no longer supported.  These imports were
   deprecated in repoze.bfg 1.0.  Import of ``getSiteManager`` should
   be done as ``from zope.component import getSiteManager``.  Import of
   ``get_registry`` should be done as ``from repoze.bfg.threadlocal
   import get_current_registry``.  This was done to prevent a circular
   import dependency.

- Code bases which alternately invoke both
   ``zope.testing.cleanup.cleanUp`` and ``repoze.bfg.testing.cleanUp``
   (treating them equivalently, using them interchangeably) in the
   setUp/tearDown of unit tests will begin to experience test failures
   due to lack of test isolation.  The "right" mechanism is
   ``repoze.bfg.testing.cleanUp`` (or the combination of
   ``repoze.bfg.testing.setUp`` and
   ``repoze.bfg.testing.tearDown``). but a good number of legacy
   codebases will use ``zope.testing.cleanup.cleanUp`` instead.  We
   support ``zope.testing.cleanup.cleanUp`` but not in combination with
   ``repoze.bfg.testing.cleanUp`` in the same codebase.  You should use
   one or the other test cleanup function in a single codebase, but not
   both.

Internal


- Created new ``repoze.bfg.configuration`` module which assumes
   responsibilities previously held by the ``repoze.bfg.registry`` and
   ``repoze.bfg.router`` modules (avoid a circular import dependency).

- The result of the ``zope.component.getSiteManager`` function in unit
   tests set up with ``repoze.bfg.testing.cleanUp`` or

Re: [Repoze-dev] trying to apply "row-level" security in SQLAlchemy + URL Dispatch

[Chris McDonough]

george hu wrote:
> Okay, now I tried to change the RootFactory class as this:
> 
> def __init__(self,environ):
>   matchdict = environ['bfg.routes.matchdict']
>   page = matchdict.get('pagename',None)
>   if page == "APage":
>  self.__acl__=[(Allow,Everyone,'view'),(Allow,'editor','edit')]
> 
> What I want is to popup a login page for a specific pagename (APage) and 
> when it is authenticated it brings me to the edit page. It did when I 
> tried to access APage. But it did this on other pages and I couldn't 
> access the edit page even I provided correct user/password. Should I add 
> a new factory directive in ZCML say GetPage and create a Factory class 
> GetPage in model.py  and put
> page = session.query(Page).filter_by(name=matchdict['pagename']).one()
> also the acl part in it and return the page?

I don't know what this means in terms of your specific application, but the 
context you return (the result of the "factory") should have "the right" ACL 
based on the elements that are matched in the matchdict.  So for instance, for 
the URL pattern "/pages/:pagename"

- For the URL /pages/1, "pagename" is "1".

- For the URL /pages/2, "pagename" is "2".

Let's say when the pagename is "1" you want to allow editors to edit and 
everyone else to view.  But when the pagename is any other page name, you want 
to allow only editors to view and edit.  This means that you'd do something 
like:

class TheFactory(object):
 def __init__(self, environ):
matchdict = environ['bfg.routes.matchdict']
page = matchdict.get('pagename')
if page == '1':
self.__acl__ = [(Allow, 'editor', 'edit'),
(Allow, Everyone, 'view')]
else:
self.__acl__ = [(Allow, 'editor', 'view'),
(Allow, Everyone, 'view')]

Obviously this won't scale for arbitrary values of "pagename" over time, so 
you'll want to keep some sort of lookup table in your database that maps page 
names to "acl names" or so, so you can attach the correct ACL.  Use the table 
within the factory to compute the acl and attach it.

- C
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] trying to apply "row-level" security in SQLAlchemy + URL Dispatch

[Chris McDonough]

Chris McDonough wrote:
> 
> Hi George,
> 
> Have you read 
> http://docs.repoze.org/bfg/1.1/narr/urldispatch.html#using-repoze-bfg-security-with-url-dispatch
>  
> ?

Never mind, I see that you have.

The model object is not the context in this situation.  The context is 
something different.  It's the result of calling the "factory" attached to a 
route.  See the definition of "factory" inside 
http://docs.repoze.org/bfg/1.1/narr/urldispatch.html#the-route-zcml-directive

- C

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] trying to apply "row-level" security in SQLAlchemy + URL Dispatch

[Chris McDonough]

george hu wrote:
> According to the document, "A common thing to want to do is to attach an 
> __acl__ to the context object dynamically for declarative security 
> purposes", I moved __acl__ statement from RootFactory class to the Page 
> class, as in the following code:
> 
> class Page(Base):
>__tablename__='pages'
>id = Column(Integer, primary_key=True)
>name = Column(Text, unique = True)
>data = Column(Text)
> 
>def __init__(self,name,data):
>self.name  = name
>self.data = data
> *   self.__acl__=[(Allow,Everyone,'view'),(Allow,'editor','edit')]*
> 
> but it doesn't serve the purpose. What's wrong with my code?

Hi George,

Have you read 
http://docs.repoze.org/bfg/1.1/narr/urldispatch.html#using-repoze-bfg-security-with-url-dispatch
 
?

- C

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] repoze.bfg 1.1a5 released

[Chris McDonough]

repoze.bfg 1.1a5 has been released.

You may install it using the following command:

   easy_install -i http://dist.repoze.org/bfg/dev/simple repoze.bfg

It is also on PyPI.

This release is mostly a documentation improvement and speed improvement 
release.  The changelog follows:

1.1a5 (2009-10-10)
==

Documentation
-

- Change "Traversal + ZODB" and "URL Dispatch + SQLAlchemy" Wiki
   tutorials to make use of the new-to-1.1 "renderer" feature (return
   dictionaries from all views).

- Add tests to the "URL Dispatch + SQLAlchemy" tutorial after the
   "view" step.

- Added a diagram of model graph traversal to the "Traversal"
   narrative chapter of the documentation.

- An ``exceptions`` API chapter was added, documenting the new
   ``repoze.bfg.exceptions`` module.

- Describe "request-only" view calling conventions inside the
   urldispatch narrative chapter, where it's most helpful.

- Add a diagram which explains the operation of the BFG router to the
   "Router" narrative chapter.

Features


- Add a new ``repoze.bfg.testing`` API: ``registerRoute``, for
   registering routes to satisfy calls to
   e.g. ``repoze.bfg.url.route_url`` in unit tests.

- The ``notfound`` and ``forbidden`` ZCML directives now accept the
   following addtional attributes: ``attr``, ``renderer``, and
   ``wrapper``.  These have the same meaning as they do in the context
   of a ZCML ``view`` directive.

- For behavior like Django's ``APPEND_SLASH=True``, use the
   ``repoze.bfg.view.append_slash_notfound_view`` view as the Not Found
   view in your application.  When this view is the Not Found view
   (indicating that no view was found), and any routes have been
   defined in the configuration of your application, if the value of
   ``PATH_INFO`` does not already end in a slash, and if the value of
   ``PATH_INFO`` *plus* a slash matches any route's path, do an HTTP
   redirect to the slash-appended PATH_INFO.  Note that this will
   *lose* ``POST`` data information (turning it into a GET), so you
   shouldn't rely on this to redirect POST requests.

- Speed up ``repoze.bfg.location.lineage`` slightly.

- Speed up ``repoze.bfg.encode.urlencode`` (nee'
   ``repoze.bfg.url.urlencode``) slightly.

- Speed up ``repoze.bfg.traversal.model_path``.

- Speed up ``repoze.bfg.traversal.model_path_tuple`` slightly.

- Speed up ``repoze.bfg.traversal.traverse`` slightly.

- Speed up ``repoze.bfg.url.model_url`` slightly.

- Speed up ``repoze.bfg.url.route_url`` slightly.

- Sped up ``repoze.bfg.traversal.ModelGraphTraverser:__call__``
   slightly.

- Minor speedup of ``repoze.bfg.router.Router.__call__``.

- New ``repoze.bfg.exceptions`` module was created to house exceptions
   that were previously sprinkled through various modules.

Internal


- Move ``repoze.bfg.traversal._url_quote`` into ``repoze.bfg.encode``
   as ``url_quote``.

Deprecations


- The import of ``repoze.bfg.view.NotFound`` is deprecated in favor of
   ``repoze.bfg.exceptions.NotFound``.  The old location still
   functions, but emits a deprecation warning.

- The import of ``repoze.bfg.security.Unauthorized`` is deprecated in
   favor of ``repoze.bfg.exceptions.Forbidden``.  The old location
   still functions but emits a deprecation warning.  The rename from
   ``Unauthorized`` to ``Forbidden`` brings parity to the the name of
   the exception and the system view it invokes when raised.

Backwards Incompatibilities
---

- We previously had a Unicode-aware wrapper for the
   ``urllib.urlencode`` function named ``repoze.bfg.url.urlencode``
   which delegated to the stdlib function, but which marshalled all
   unicode values to utf-8 strings before calling the stdlib version.
   A newer replacement now lives in ``repoze.bfg.encode`` The
   replacement does not delegate to the stdlib.

   The replacement diverges from the stdlib implementation and the
   previous ``repoze.bfg.url`` url implementation inasmuch as its
   ``doseq`` argument is now a decoy: it always behaves in the
   ``doseq=True`` way (which is the only sane behavior) for speed
   purposes.

   The old import location (``repoze.bfg.url.urlencode``) still
   functions and has not been deprecated.

- In 0.8a7, the return value expected from an object implementing
   ``ITraverserFactory`` was changed from a sequence of values to a
   dictionary containing the keys ``context``, ``view_name``,
   ``subpath``, ``traversed``, ``virtual_root``, ``virtual_root_path``,
   and ``root``.  Until now, old-style traversers which returned a
   sequence have continued to work but have generated a deprecation
   warning.  In this release, traversers which return a sequence
   instead of a dictionary will no longer work.
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] zope.schema, zope.formlib in bfg? or help a newb understand zca coolness

[Chris McDonough]

Martin Aspeli wrote:
> Thomas G. Willis wrote:
> 
>> I was kind of expecting that the book would have some gaps as far as bfg 
>> goes. I was hoping that going through the exercise of struggling through 
>> those gaps would help me arrive at a better understanding of all things 
>> zope(a lofty goal I'm sure). 
> 
> I guess what I was saying that BFG is more "inspired by" Zope than 
> actually based on it. It does use a number of low-level Zope packages, 
> but it doesn't try to be consistent with "Zopeish" ways of doing things.

That's about right.

> One good example is the way that views work. In Zope, you register a 
> view factory (usually a class). The publisher will invoke the factory, 
> and then call the result (usually). Therefore, a basic view is a class 
> that takes two parameters in __init__, the context and the request, and 
> has a __call__ method that returns a string (or renders a template).
> 
> In BFG, a view is a method that gets called, i.e. the factory bit is 
> lost. If that's good or bad probably depends on your point of view. It's 
> certainly simpler. ;)

This is a bit off topic, but BFG actually also supports the "view as a class" 
view construction form, ala Zope:

http://docs.repoze.org/bfg/1.1/narr/views.html#defining-a-view-as-a-class

The form is overkill for lots of common things, so we also support the notion 
that a view can also just be a callable.


>> thanks so much for the info. I'll check out z3c.form.
>>
>> But if I understand what you are saying about the request needing to be 
>> marked with the IFormLayer interface, I would assume an adapter could be 
>> configured to provide that. I'll try that first anyway.
> 
> I can tell you how to do it in Plone. ;-)
> 
> I'm sure repoze.bfg has a simple way to hook in an event handler to do 
> this. You basically want:
> 
>from zope.interface import alsoProvides
>from z3c.form.interfaces import IFormLayer
> 
>alsoProvides(request, IFormLayer)

You could try to mess around with an INewRequest event subscriber, ala:

http://docs.repoze.org/bfg/1.1/narr/events.html#using-an-event-to-vary-the-request-type

> The question is where the request comes from, and what kind of an object 
> it is. A Zope 3 request (from the zope.publisher package) is different 
> from a BFG request, as far as I understand. So, it may be that z3c.form 
> would require some kind of a "zopeish" request adapter to even work.

Figuring out the real difference here would be 99% of the work in making it 
work, I imagine.

> 
> The same would be true of zope.formlib, of course. I suspect you may be 
> the first person to try this, though. If you're also just learning, then 
> maybe that's making life very hard for yourself.
> 
> My advice would be to read Philipp's book because it's very good and 
> will teach you a bunch of stuff about Zope. If you like the way it 
> works, take a look also at grok.zope.org, which uses all the Zope stuff 
> underneath but aims to make it easier to get started through 
> convention-over-configuration.
> 
> At the same time (or before or after) read the bfg docs on 
> bfg.repoze.org. They're very good too. But I'd maybe try to keep 
> repoze.bfg and "Zope" (at least as far as Philipp's book goes) separate 
> in your mind until you become more proficient with both and understand 
> them well enough to be able to help integrate Zope technologies into BFG 
> or vice-a-versa.

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] zope.schema, zope.formlib in bfg? or help a newb understand zca coolness

[Chris McDonough]

Form generation libraries that contain validation are very tough to generalize 
in a way that lends itself to framework convenience.  I think Formish does a 
pretty good job here, because it physically separates out a lot of stuff that's 
all glommed together in other system (and thus there's schemish, validatish, 
convertish, and even 'dottedish').  It's shows maturity in design.

But at its very outer layer it *does* depend on the request having a particular 
API (the WebOb API).  But so does BFG, so this works out pretty well.

I suspect it will be a bit of a project to use anything that depends on a 
particular request API but doesn't depend on the WebOb API.

So I have the beginnings of BFG-ish bindings for Formish here (unfinished and 
very unstable; the docs are currently total bollocks and don't match the 
implementation):

http://svn.repoze.org/repoze.bfg.formish/trunk/

I hope to have a release of this out within the next few weeks.


Martin Aspeli wrote:
> Chris McDonough wrote:
>> +1 to what Martin wrote, with something else that can only add to the 
>> confusion:  recently I have been using Formish (http://ish.io) to do 
>> autogenerated forms.  I think both zope.formlib and z3c.form try to paint 
>> forms 
>> based on "model" objects; formish doesn't even try.  It just lets you create 
>> your own "form schema" and attempts to draw forms based on that.  This is 
>> enough for my needs currently.
> 
> 
>  From a quick read of the documentation, formish looks nice. It also 
> looks very similar to z3c.form, and has many of the same abstractions 
> (fields, widgets, form renderers, data converters).
> 
> z3c.form indeed contains some base classes for "model-based" 
> add/edit/display forms, but it's easy to base it on anything (you don't 
> even need an interface, you can just pass it a sequence of schema fields).
> 
> In this regard, z3c.form is at least a lot more flexible than zope.formlib.
> 
> Martin
> 
> ___
> 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] zope.schema, zope.formlib in bfg? or help a newb understand zca coolness

[Chris McDonough]

+1 to what Martin wrote, with something else that can only add to the 
confusion:  recently I have been using Formish (http://ish.io) to do 
autogenerated forms.  I think both zope.formlib and z3c.form try to paint forms 
based on "model" objects; formish doesn't even try.  It just lets you create 
your own "form schema" and attempts to draw forms based on that.  This is 
enough for my needs currently.

- C


Martin Aspeli wrote:
> Thomas G. Willis wrote:
>> OK, not sure if this is a blasphemous question or not. I've been slowly 
>> working through "Web Component Development with Zope 3" , and instead of 
>> trying out the things in zopeproject, I figured that trying out the 
>> things in bfg as well may yield a greater understanding of what the heck 
>> is going on. I realize that this may be incredibly dumb, so I'm not 
>> surprised that I'm hitting roadblocks once in a while.
> 
> Bear in mind that whilst repoze.bfg uses a number of Zope packages, it 
> is not built on top of Zope 3 (in the same way that, say, Grok is). BFG 
> contains forks/re-implementations of some Zope things, omits a large 
> number of package traditionally part of a Zope 3 bundle (this is a good 
> thing!), and solves certain things differently (e.g. the way views are 
> done in bfg is different from the way they are done in Zope).
> 
> For this reason, Philipp's book will probably not apply in many cases if 
> you're using BFG, and I don't think there's any documentation or good 
> guides to *which* parts will apply and which parts won't (i.e. a "bfg 
> delta zope" document).
> 
> That said, I can't see it being impossible to use zope.schema + a forms 
> library in repoze.bfg. Not that I've tried. ;)
> 
>> After reading up on zope.schema and zope.formlib, it seems that schema 
>> based forms, fit my brain, and I would like to use them in bfg if 
>> possible rather than tw.forms etc...
> 
> This won't help with your specific question, but most people seem to be 
> ditching zope.formlib in favour of z3c.form, which is more feature 
> complete, better documented and better maintained. The basic principles 
> are still the same: you build a schema and then create a form from that 
> schema.
> 
> http://docs.zope.org/z3c.form has the documentation.
> 
> To use it, you need to depend on it in your own package's setup.py so 
> that it gets installed, and include its configuration via  package="z3c.form" /> in your configure.zcml. To use the default widgets 
> (which you probably want) you also need to mark the request with the 
> IFormLayer marker interface. I'm not sure what facility repoze.bfg has 
> for that, though.
> 
> Martin
> 

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] Minor Typo in xml-rpc docs

[Chris McDonough]

Thanks Kevin.

This was actually already fixed in SVN but the docs rendering hadn't been 
updated for a while.  I just updated it.

- C


Kevin J. Kalupson wrote:
> Hi,
>   I spotted a minor typo on http://docs.repoze.org/xmlrpc/ .
> 
> near the top -
>   easy_install -i http://dist.repoze.org/bfgsite/simple repoze.bfg.xmrpc
> 
> should be:
>   easy_install -i http://dist.repoze.org/bfgsite/simple repoze.bfg.xmlrpc
> 
> 
> the rest of that page looks good to my eyes.
> 
> -Kevin
> 
> 
> ___
> 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