Re: [Repoze-dev] catalog oddness
On Fri, Jan 14, 2011 at 5:20 AM, Wichert Akkerman wich...@wiggy.net wrote: This may already be different in the trunk of repoze.catalog, but I just stumbled over this: when you do a catalog search and ask it to order by an empty index you get an empty result set. I was expecting the result to be an unordered result for that situation. Is this expected behaviour? Hi Wichert, I haven't observed this behavior, but it seems like an undefined case, to me. I'm not sure what I would expect it to do in such a situation. Supposing you have a set of documents you want sorted by an index and the index contains only a subset of those documents? It seems to me the case is undefined--I would have a tendency to raise an exception, personally. I think in the interest of a well defined determinism I would suggest that if you are using an index to sort, you should make sure that the discriminator for that index be able to return some value for any document. This way even if logically, to you, the document doesn't really have a value for that index, you can at least be deterministic about how it will be sorted. Chris ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] catalog oddness
On Fri, Jan 14, 2011 at 10:21 AM, Wichert Akkerman wich...@wiggy.netwrote: The object did have a value, but it was None which the indexed apparently ignores. The fact that it was always None was a bug in my code that has been fixed now - it should be either None or a date (it was a publication-date field). Ah, having a value of None is different than not having a value. Ie, def discriminator(obj, default): Does not have a value. return default def discriminator(obj, default): Has a value of None. return None You're sure it's the second case you're hitting? It wouldn't be an empty index, but it would be one where every document has a value of None. If you're seeing an empty result set in that case, then that sounds like a bug. Chris ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Generating http/https links from the application
I would just have a middleware look for that header and rewrite
wsgi.url_scheme appropriately in the environment. You could use repoze.vhm
to do that, but since you only need that one tweak, a few lines of
middleware should really be all you need.
Chris
class RewriteURLSchemeMiddleware(object):
Not tested.
key = 'HTTP_X_FORWARDED_PROTO'
def __init__(self, app, global_config, **config):
self.app = app
def __call__(self, environ, start_response):
if self.key in environ:
environ = environ.copy()
environ['wsgi.url_scheme'] = environ[key]
return app(environ, start_response)
On Wed, Nov 10, 2010 at 11:40 AM, Hanno Schlichting ha...@hannosch.euwrote:
Hi.
We have an application which supports both HTTP and HTTPS. If the user
visits the site via https:// he should stay on that protocol and as
such all links should be generated accordingly.
We do the SSL handling in Nginx in front of the bfg application. So
the application always gets a request.application_url with a http://
link. We have an additional header 'HTTP_X_FORWARDED_PROTO which
gets sets to 'https'.
In order to support this, we use our own route_url function that looks
like this:
from repoze.bfg.url import route_url as bfg_route_url
def route_url(route_name, request, *elements, **kw):
https = request.environ.get('HTTP_X_FORWARDED_PROTO') == 'https'
value = bfg_route_url(route_name, request, *elements, **kw)
if https:
return value.replace('http://', 'https://')
return value
Does this sound like a reasonable approach, or is there a better
alternative? Having to use a different implementation of a core API
feels wrong.
Thanks,
Hanno
___
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.catalog clear
On Mon, Nov 8, 2010 at 10:10 AM, Wichert Akkerman wich...@wiggy.net wrote: On 11/8/10 16:09 , Chris Rossi wrote: The document_map, while sometimes stored on the catalog, is not known to the catalog. If you want to clear it, you need to do so explicitly. This is because r.catalog makes no assumptions about how you retrieve a document given a docid. The DocumentMap implementation is provided to fit a common case, but is still up to the app to manage. right. It would be nice if DocumentMap supported a clear() method though. Hmm. Sure. I'll add that on trunk. Seems safe enough. In the meantime you could just create a new DocumentMap? Chris ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Chameleon vs. jQuery templating, round one
I suspect you're going to want to store client side template separately from
the ZPT and inject it at render time. Does this work?
In Python:
jstemplate = blah blah blah % some expression % blah blah
rendered = render_template(template.pt, jstemplate=jstemplate)
In ZPT:
blah blah
div tal:replace=structure jstemplate/
blah blah
Chris
On Tue, Oct 12, 2010 at 1:40 PM, Paul Everitt p...@agendaless.com wrote:
Hi all. Before this floats out of my brain, I thought I'd write it down
and see what people think.
In the past few months I've done a bit of client-side templating in jQuery,
first using John Resig's microtemplating:
http://ejohn.org/blog/javascript-micro-templating/
...as well as the just-announced-as-core templating:
http://blog.jquery.com/2010/10/04/new-official-jquery-plugins-provide-templating-data-linking-and-globalization/
I used these in KARL which uses Chameleon 1.1.1. All was happy.
I tried both today on a new project which uses Chameleon 1.2.13. Chameleon
didn't like the syntax, which in one case looks like this:
% some expression %
and in another:
${somevar}
In the first case, Chameleon refuses to parse the zpt because Expat tries
to interpret % as a startTag. In the second case...needless to say, it is
ironic that we have overlap in syntax. I then tried wrapping a CDATA around
the block, but Chameleon happily plowed into the CDATA looking for stuff to
evaluate.
I was going down the path of demand-loading my templates with a second
request when I stumbled across an obscure point in the docs saying that
${somevar} and {{= somevar}} are interchangeable for the second URL above.
Thus, I'm less in a pickle, but thought I'd bring it up anyway.
--Paul
___
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.folder API weirdness
On Thu, Jun 17, 2010 at 10:08 AM, Tim Hoffman zutes...@gmail.com wrote: I would be concerned if you tried to __setitem__ a new page to replace the existing folder of the same name thus blowing away a whole heap of subfolders and documents in the process. Very bad ;-( I would tend to think that responsibility for protecting the user from errors lies at the UI and application level. An API, generally speaking, should just do what it's told. I don't think I have a preference between wiggy's and mcdonc's proposals. Chris ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] imperative configuration prevents application extension?
On Thu, May 6, 2010 at 4:14 AM, Charlie Clark charlie.cl...@clark-consulting.eu wrote: Am 06.05.2010, 10:10 Uhr, schrieb Chris Withers ch...@simplistix.co.uk: This is spot on, and would, in theory, allow an app to override a library that overrides a framework. Cue lots of Jim like wooah! comments and it's all Chris' fault in the code! ;-) I hate to just make more work for Chris M. I'm happy to add this to my todo list. I have a lot on my plate right now, so don't expect a timely implementation, but I'll try to get to it . . . . sometime. Chris R ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] imperative configuration prevents application extension?
On Thu, May 6, 2010 at 10:49 AM, Chris McDonough chr...@plope.com wrote: On Thu, 2010-05-06 at 10:36 -0400, Chris Rossi wrote: On Thu, May 6, 2010 at 4:14 AM, Charlie Clark charlie.cl...@clark-consulting.eu wrote: Am 06.05.2010, 10:10 Uhr, schrieb Chris Withers ch...@simplistix.co.uk: This is spot on, and would, in theory, allow an app to override a library that overrides a framework. Cue lots of Jim like wooah! comments and it's all Chris' fault in the code! ;-) I hate to just make more work for Chris M. I'm happy to add this to my todo list. I have a lot on my plate right now, so don't expect a timely implementation, but I'll try to get to it . . . . sometime. I'm actually not 100% confident that I understand the syntax, so I don't think I could implement it yet anyway. With ovverides='some.funcion.or.method', is the function or method being overridden assumed to have a view configuration attached to it that matches the overriding view configuration? If so, that's a little weird. What if it has different view configuration arguments or or no view configuration arguments at all? A good number of view configuration overrides as performed via ZCML don't require creatign separate view callable (like changing the rendererer), so constructing one just to be able to decorate it, then delegating to the original, seems a little suspect. I'm also not sure that this can be advertised as an overrides strategy 100% comparable to ZCML unless all the various ZCML directives get Python declarative equivalents. So.. yeah, I think there's a cool idea lurking in here, but I'm not sure we found it yet. Good point. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] imperative configuration prevents application extension?
On Wed, May 5, 2010 at 1:34 PM, Chris McDonough chr...@plope.com wrote: On Wed, 2010-05-05 at 19:19 +0200, Charlie Clark wrote: Am 05.05.2010, 02:18 Uhr, schrieb Chris McDonough chr...@plope.com: Relying on scan ordering is like relying on import ordering to do configuration in an application. You can do it if you want, but you get to keep both pieces when it breaks. Would it make sense to raise a configuration error like ZCML does? Probably. This would be most consistent. Decorator configuration is more like ZCML than it is like imperative configuration. +1 FWIW, I can imagine something spelled sort of like: @bfg_view(name='something', overrides='baseapp.views.someview') def my_view(request): ... If the overriding registration specifically calls out what it is its overriding you can still figure out who's supposed to win in a conflict without trying to rely on scan order. Chris ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] threadpooling things
This currently lives in a specific project but I have considered pulling it out and making it more general: http://bfg.repoze.org/pastebin/715 The main thing you would need to do to make it a general purpose ResourcePool would be to pass a resource_factory callable into the constructor and, optionally, a ping callable for checking that the resource is still usable. The cleanup thread is probably a little fishy. And this package doesn't provide any sort of threadlocals. The application does get a connection per thread and store it in a threadlocal, but that's outside the scope of the resource pool implementation. Chrsi On Thu, Apr 29, 2010 at 10:44 AM, Chris Withers ch...@simplistix.co.uk wrote: Not strictly speaking a repoze question, but the people who live here have likely bumped into this, and I value your wise opinions :-) So, SQLAlchemy takes care of having one session per thread and a connection pool for you, however what about resources where that's not the case. For me, it's a stomp client for sending stomp messages, but I guess it could be an ftp connection, etc. Are there any tools around for managing one connection per thread and/or connection pooling in an abstract way that I could re-use? cheers, Chris ___ 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] how to get the response
Ciao Davide,
There is not a response already attached to the request, but your
instance of HTTPFound *is* a response, so you would just set your
cookie there:
ppp = HTTPFound(location=request.application_url)
ppp.set_cookie('fb_user', value=value, ...)
return ppp
Chris
On Tue, Apr 27, 2010 at 12:28 PM, Davide Moro davide.m...@redomino.com wrote:
Hi,
I have a question about how to get the response from a request, how to
set a cookie and redirect.
Is there any working example? Something like that:
ppp = request.get_response()
ppp.set_cookie('fb_user', value=value, ...)
and then redirect to the application url
return HTTPFound(location=self.request.application_url)
Thanks,
davide
--
Davide Moro
Redomino S.r.l.
Largo Valgioie 14,
10146 Torino Italy
Tel: +39 0117499875
http://redomino.com
___
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] Use case of view predicate xhr and json renderer
Hi George,
In this case it really doesn't make much difference. There just happens to
be more than way to skin the cat. You have a context, an instance of
ITextEdit, and you're trying to configure BFG in such a way that it can call
different views based on the request. You've already done this using one
perfectly legitimate approach--you've given your view a name and used the
name in the url that you call to retrieve it. It's unambiguous which view
is being called here, so there's no real need to go further.
The xhr predicate is just another way to differentiate view registrations.
Rather than using the name of the view, and adding the name to the end of
the url you use to call it, you could, instead, use the xhr predicate.
Since TinyMCE is issuing an XMLHTTPRequest in order to hit your view, and
sets a header in the request indicating that, you can use the xhr predicate
to look for the presence of that header and call the view that way. The url
you use to hit the image list js and the normal text editor html view will
be the same. Instead of differentiating on the view name in the url, BFG
differentiates on the X-Requested-With header. (Caveat: I don't do a ton of
AJAX so I'm not entirely sure whose responsibility it is to set that
header--the browser, or the javascript code that's making the request. If
it's the latter, you may need to check and make sure that TinyMCE sets the
appropriate header.)
In your case, though, I would actually leave it the way you have it. This
is because, conceptually, to me, the image list is a different resource than
the text editor, so it makes sense to differentiate them by url. I would
have more of a tendency to use the xhr predicate if I were interested in
providing both an html and a json view for the same logical resource, say a
blog post, or a photograph. This way the resource is always at the same url
but depending on the client that generated the request you can send back an
html page that displays the resource or json that represents the resource
logically.
As far as renderers go, I don't think you would be served by using BFG's
json renderer because it looks like you're passing back to TinyMCE a
javascript assignment statement. JSON really only applies to the right hand
of that assignment. If you were to use the BFG renderer you'd only be
sending back the right side of the assignment. If TinyMCE also needs the
left side to function, that probably don't work. I am completely ignorant,
though, of what TinyMCE expects there.
Hope this helps.
Chris
On Fri, Jan 22, 2010 at 6:27 PM, georgehu geo...@gmail.com wrote:
Hi there,
As I'm fairly new to the python web development, sometimes I found it's
hard to get an idea of how to use features in the repoze.bfg. For example,
for the xhr view predicate, the document says this is useful for detecting
AJAX requests issued from jQuery, Prototype and other Javascript
libraries..
Well yes, I understand it, but I still don't know what can I do with it.
Although a first look at the question I would say it's not appropriate to
ask it here, as I can understand this is a feature exists in such a
framework like BFG, which declares itself as *Minimalism*, and it's
totally up to each individual developer to deal with, but for a newbie like
me just can't imagine how to start with it. Thankfully I can study and learn
many other features by looking at the source code such as BFG site, but
still there are points here and there which I can't find a example. So a
sample code snippet would be will very helpful.
Enough talk and let's go back to the business, I'm currently trying to use
TinyMCE to provide a rich editor of my text field, one of its functionality
is to supply a list of jpg files on the server to the user, which is an
option named external_image_list_url in TinyMce. My task is to return a
java script like var = array of files to the main TinyMCE script in a
template, I first defined a view in zcml:
view
for=myproject.interfaces.ITextEdit
name=imgList
view=.js.imgList
/
in the template, I have TinyMCE java script initialized as this,
..
external_image_list_url: imgList
..
in the js.py I have a function to return a javascript document,
def imgList(context, request):
response = Response(content_type='application/x-javascript')
here = os.path.dirname(__file__)
basedir = os.path.join(here,templates,static,images,site)
baseurl = /static/images/site/
files = glob.glob(basedir+/*)
array = [(os.path.basename(file),baseurl+os.path.basename(file)) for
file in files]
response.body = var %s = %s % ('tinyMCEImageList',
simplejson.dumps(array))
return response
in the above function I use json to return the array of image files to the
template,
It runs without problem, my question is, is it a best way to do it? As I
read through the document, I saw xhr view predicate, and json renderer, is
there a way to
Re: [Repoze-dev] doc question
On Sun, Nov 22, 2009 at 9:08 PM, Chris McDonough chr...@plope.com wrote: 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? This seems to be a simple confusion over terminology. According Python's own terminology, the following class has a class method, a static method, and an instance method: class C(Object): @classmethod def factory(cls, *args, **kw): My first argument is the class. @staticmethod def something_else(*args, **kw): I get no special args. def an_instance_method(self, *args, **kw): I take an instance as my first arg. So, technically, where the documentation refers to a class method, you really mean an instance method. Chris ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] page directive sci-fi
I may be missing something that makes this impossible, but my point was that you could probably add it to the existing implementation without changing how any existing applications work. The existing functionality is all there as a subset of the new stuff. But I haven't stared at it for too long so I may be missing obvious backwards incompatibility. Chris On Sun, Sep 13, 2009 at 10:29 PM, Tim Hoffman t...@zute.net wrote: Hi I am not too sure about making this the default 'view' implementation or at least we need to retain the existing the simpler view directive. I many cases I am/need to identify the template used much later in the process, so for me baking the template name in the view directive is certainly not what I want T On Mon, Sep 14, 2009 at 1:59 AM, Chris Rossi ch...@archimedeanco.com wrote: This looks reasonable. I think it would also be reasonable to just make this the standard 'view' functionality, since afaict the current functionality is a subset of this. Chris On Sun, Sep 13, 2009 at 12:57 PM, Chris McDonough chr...@plope.com wrote: Here's some sci fi I wrote up about a page ZCML directive. As Tim Hoffman suggested, maybe the fact that the page is passed into the template would give us enough pull capability to avoid any of the other hacks I proposed to push global names into every rendered template. Note that the view directive could probably eventually be changed to do everything that the page directive I describe below does. Comments appreciated. repoze.bfg.page README == ``repoze.bfg.page`` is a package which adds a ``page`` ZCML directive to the set of directives that may be used under BFG. You might use a ``page`` directive in places where you would otherwise use the built-in repoze.bfg ``view`` directive. Defining a ``page`` directive effectively creates a single BFG view under the hood, and owns attributes similar to those of a view directive. However, the ``page`` directive differs from the BFG ``view`` directive in a number of important ways: - The ``page`` directive allows you to associate a *template* with the page being defined. The machinery behind the ``page`` directive is capable of rendering an associated template, unlike a view, which must find and render a template itself. - A ``page`` directive, like a BFG ``view`` directive, points at a callable which accepts two arguments: ``context`` and ``request``. This callable must return a Response object *or* a Python dictionary. This is unlike a BFG ``view`` callable, which always returns a Response object (and must never return a dictionary). The ``callable`` which a ``page`` directive points at may optionally be a class. If the page directive's ``callable`` attribute points at a class, that class must have an ``__init__`` method that accepts two arguments: ``context`` and ``request``. That class must further define a ``__call__`` method which accepts no arguments and which returns a dictionary or a Response object. If the page callable returns a Python dictionary, the ``template`` named within the directive will be passed the dictionary as its keyword arguments, and the ``page`` implementation will return the resulting rendered template in a response to the user. The callable object (whatever object was used to define the page ``callable``) will be automatically inserted into the set of keyword arguments passed to the template as ``page``. If the callable object was a class, an instance of that class will be inserted into the keyword arguments as ``page``. If the ``callable`` associated with a ``page`` directive returns a Response object (an object with the attributes ``status``, ``headerlist`` and ``app_iter``), any template associated with the ``page`` declaration is ignored, and the response is passed back to BFG. For example, if your page callable returns an ``HTTPFound`` response, no template rendering will be performed:: from webob.exc import HTTPFound return HTTPFound(location='http://example.com') # templating avoided Here's an example of a page directive which acts as a default view:: page template=templates/my_template.pt callable=.pages.my_page / The ``template`` attribute is optional. If one is not named, and the callable returns a dictionary, an error will be thrown at rendering time. Special ZCML Attributes --- The directive accepts attributes other than ``template`` and ``callable``. attr ``repoze.bfg.page`` defaults to using the ``__call__`` method of the page callable to obtain a response dictionary. The ``attr`` value allows you to vary that method name. For example, if your class had a method named ``index`` and you wanted to use this method instead
Re: [Repoze-dev] bfg vs buildout
On Wed, Jun 24, 2009 at 9:16 AM, Chris Withers ch...@simplistix.co.ukwrote: Also, how do you wire running tests, particularly running them with nose, into this? bin/nosetests path/to/src Chris ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.component and repoze.configuration
FWIW, when/if I end up trying to introduce component architecture ideas and practices to projects or groups not already using Zope or BFG, chances are I will start here, rather than than with the zope.* equivalents. While I don't have any particular opinion about XML vs YAML, I have found the heuristic that all component lookups are based on interfaces to lead the abuse of the interface concept. Marker interfaces, I think, are a symptom of this. They're not really interfaces. But they are markers. Use of strings as markers I think relieves this stress on the interface concept and opens up some more (not yet even thought up) usage patterns that could be interesting. It also relieves the temptation to pull in zope.interface when one wishes to use the *concept* of interfaces in their code, but not necessarily Zope's implementation of such. I'm starting to think that for the advantages interfaces provide in terms of writing polymorphic, OOP code in Python, abstract base classes might be a more natural way to go. Chris On Mon, Jun 22, 2009 at 3:52 PM, Chris McDonough chr...@plope.com wrote: I have released two new packages to PyPI. These packages were inspired by (design almost entirely stolen from) zope.component and zope.configuration. I don't really expect them to get much use, but writing them was enlightening. Maybe they'll be interesting to someone who wants to introduce people to zope-style componentry without using interfaces and zope-style configuration without schema or XML. repoze.component package: http://pypi.python.org/pypi/repoze.component/0.1 docs: http://docs.repoze.org/component/ code: http://svn.repoze.org/repoze.component/trunk/ This package differs from zope.component inasmuch as it disuses the concept of interface, instead favoring string markers. repoze.configuration package: http://pypi.python.org/pypi/repoze.configuration/0.1 docs: http://docs.repoze.org/configuration/ code: http://svn.repoze.org/repoze.configuration/trunk/ This package differs from zope.configuration inasmuch as it uses YAML instead of XML, and doesn't use schemas to define directive attributes. Have fun, - 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] Plan for repoze.zodbconn
On Fri, Jun 12, 2009 at 12:28 PM, Tres Seaver tsea...@palladion.com wrote: +1 from me. +1 from me. Also +1 for managing the transaction at this level, if feasible. Chris ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] unifying url dispatch and traversal
On Mon, Jun 8, 2009 at 10:19 AM, Stephan Altmueller step...@klaravision.com wrote: I would also like to throw in my suggestion for a function signature (based on Chris Rossi's): def context_factory(request, routes_match=None): I like that one. +1 Chris ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] unifying url dispatch and traversal
On Fri, Jun 5, 2009 at 11:33 AM, Chris McDonough chr...@plope.com wrote: - If a factory is specified on a route, it will need to point at a function that had the same call/response convention as a traversal root factory. This will break code. Context factories accept key/value pairs assumed to be items that matched in the URL match. These would cease working, and would need to be rewritten as root factories, which accept a WSGI environment. My gut feeling is this should be a show-stopper. Not having easy access to the match dict when doing routes just goes too far in terms of breaking expectations about how routes should work. That said, I think the goal of unifying the two methods is very compelling, so we should spend some more time thinking about how to accomplish this without breaking fundamental expectations with regards to url dispatch. The idea of performing a graph traversal starting at a context found by a routes match is particularly compelling and reason enough to pursue a unification. I'd just suggest thinking about it a little more before starting to move code around. I'll try and devote some brain cycles of my own to the problem. Thanks, Chris ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] unifying url dispatch and traversal
On Fri, Jun 5, 2009 at 11:44 AM, Chris Rossi ch...@archimedeanco.comwrote: On Fri, Jun 5, 2009 at 11:33 AM, Chris McDonough chr...@plope.com wrote: - If a factory is specified on a route, it will need to point at a function that had the same call/response convention as a traversal root factory. This will break code. Context factories accept key/value pairs assumed to be items that matched in the URL match. These would cease working, and would need to be rewritten as root factories, which accept a WSGI environment. My gut feeling is this should be a show-stopper. Not having easy access to the match dict when doing routes just goes too far in terms of breaking expectations about how routes should work. That said, I think the goal of unifying the two methods is very compelling, so we should spend some more time thinking about how to accomplish this without breaking fundamental expectations with regards to url dispatch. The idea of performing a graph traversal starting at a context found by a routes match is particularly compelling and reason enough to pursue a unification. I'd just suggest thinking about it a little more before starting to move code around. I'll try and devote some brain cycles of my own to the problem. I guess the most stupidly straightforward solution might be something like: class UnifiedFactory(Interface): def __call__(self, environ, **routes_match): Replaces concepts of root factory used for traversal and context factory used for routes, into a single concept. environ is the WSGI environment, and the match dict from routes matching, if applicable, is passed in as kw args. Chris ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] unifying url dispatch and traversal
On Fri, Jun 5, 2009 at 12:01 PM, Tres Seaver tsea...@palladion.com wrote: I'm assuming that we would fix anything in our repository; it should even be possible to do so in a BBB-compatible way, e.g.:: def context_factory(environ=None, **kw): match_dict = kw.copy() if environ is not None: # called as root factory match_dict.update(environ['repoze.bfg.matchdict']) Ah, right. Cool. Making environ a kw arg preserves backwards compatability for context factories. So tweaking my suggestion a little bit: class UnifiedFactory(Interface): def __call__(self, environ=None, **routes_match): Replaces concepts of root factory used for traversal and context factory used for routes, into a single concept. environ is the WSGI environment, and the match dict from routes matching, if applicable, is passed in as kw args. I'm sure Chris M will come up with something completely different. Chris ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] repoze.curry
Hi Malthe, Just read over the repoze.curry docs--looks really cool! I was glad to see at the end that you had a static decorator on the to-do list. I had thought of that while reading your docs and was going to suggest it anyway. I was wondering, though, if const might be a better name for it. Marking a function as const would be morally equivalent to a C++ function with all of its arguments declared const. (key difference, of course, that C++ compiler actually enforces this.) static generally implies something different in most languages that use it. That's just a nit, though. I enjoyed the morning brain stim. Thanks, Chris ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] bfg docs
On Tue, Jun 2, 2009 at 9:29 AM, Chris McDonough chr...@plope.com wrote: On 6/2/09 8:08 AM, Reed O'Brien wrote: Finished a once over the API docs. Possible nit: location.html#repoze.bfg.location.locate I don't like locate as the name for the function as I expect it to find me something rather than make something location aware. I would expect it o be something like emplace, set, put or something. I don't really like those either. OK, if anyone comes up with a better name I don't mind changing that. repoze.bfg.location.graph? Chris ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.zope2 - what's up on trunk
On Sat, May 16, 2009 at 10:47 AM, Chris McDonough chr...@plope.com wrote: On 5/16/09 6:58 AM, Hanno Schlichting wrote: Tres Seaver wrote: +lots to calling this something other than 'repoze.zope2', which has always been about bending over backward to provide full BBB for Zope2 apps. What about calling it repoze.z2bob? It's still a bob (based on repoze.obob) helper for Zope 2, but in spirit closer to the bob (as in simplification) story than the Zope 2 story. I'd still rather not have repoze in it's name if it sees the light of day as a release. plone.publisher? Chris ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] [chameleon] magic?
On Fri, May 15, 2009 at 11:36 AM, Malthe Borch mbo...@gmail.com wrote: 2009/5/15 Chris Rossi ch...@archimedeanco.com: While I think you're probably right, I know for a fact there are plenty of templates in the wild that assume you can use attribute syntax for dictionary lookup. At least on the stuff I'm working on. I'm surprised! How did you learn about this feature in the first place? I'm pretty sure I read about it in your documentation. Anyway, I'm working on a project now that I didn't start, so there were a lot of those already in there. Chris ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze grok comparison
On Thu, May 7, 2009 at 7:01 PM, Chris McDonough chr...@plope.com wrote: People are often confused about the duality of zope.interface Interface objects being used as markers during adaptation as well as being used as a mechanism to describe an API. Personally, I think it should be possible to keep the two concepts logically distinct in any given application. I don't really have a sense of how abstract base classes would fit in here. Yeah, my thinking has been, generally, that the fact that it's fairly common for people to create interfaces purely to have a marker to use for ZCA lookups, exposes a problem with the ZCA. An interface that is not an API specification is not really an interface. So called marker interfaces, to me, abuse the idea of an interface. I find repoze.plugin intriguing, in part, because it fixes this problem. AFAICT, it does everything zope.component does but adds some new use cases and makes the solutions to a few others seem less abusive of certain basic concepts. I don't have a lot of hope for its general adoption--it's awfully abstract to be accepted outside of Zope circles and inside of Zope circles there's already the ZCA, even if it seems a bit warty in places. The Zopistas seem to be the few folks, though, interested in such high levels of abstraction and formalism. Among the more obvious use cases, to me, is the case Zope/Plone programmers run into all the time where they want to apply different components to different branches of their object graph--ZCA just doesn't really handle this at all, and yet it's very common to want to do this. The canonical solution is to apply marker interfaces to different objects in your graph in order to game the adapter lookups, but that's awfully hacky and not very satisfying at all. I haven't sat down and pieced together how you'd do it in repoze.plugin, but it seems to that the fact that you can really use anything as a marker for your lookups, means you *ought* to be able to make this work in a bit more intuitive way. Chris ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.bfg trunk C-free
On Sat, May 2, 2009 at 3:15 PM, Chris McDonough chr...@plope.com wrote: On 5/2/09 2:38 PM, Carlos de la Guardia wrote: No hacks, just repackaged the eggs in a GAE friendly manner (also, a zip file was needed to accommodate for the 1000 file limit) and added fake parser and compiler modules to allow initialization to work. OK, cool. Adding those fake parser and compiler modules should no longer be necessary if you use the BFG trunk (nothing from chameleon.zpt is imported at startup time). Here's the complete application handler I used: import sys sys.path.insert(0,'bfg_dist.zip') from google.appengine.ext.webapp.util import run_wsgi_app from repoze.bfg.router import make_app from bfgstarter.models import get_root import bfgstarter application = make_app(get_root, bfgstarter) def main(): run_wsgi_app(application) if __name__ == '__main__': main() Cool... Any suggestions for templating engines? There are existing BFG bindings for Jinja2 (http://svn.repoze.org/repoze.bfg.jinja2). I don't know if Jinja2 runs on GAE; a quick Google search seems to imply that it might. I could probably create some bindings for meld3, although meld3 kinda sucks balls. DTML? ;-) simpletal? http://www.owlfish.com/software/simpleTAL/ Chris ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.plugin documentation
On Tue, Apr 28, 2009 at 3:01 AM, Malthe Borch mbo...@gmail.com wrote:
2009/4/27 Chris McDonough chr...@plope.com:
Answering myself with the kind of navel-gazing which is sure to drive
Tres
nuts ;-):
Not answering anything, but this thread is as good a place as any:
I think the issue of overriding default components is unnatural.
Rather, I'd like to think of components in terms of availability,
rather than pluggability. Concretely, the following is *pluggability*:
by_interface = {}
Plug me once, you'll plug something out if you try it again.
That's not what the ZCA is about; I think it's rather about
availability, e.g. if I give you these N things, give me something
that provides some formal functionality (described by an interface).
The problem with this line of thought is that it breaks down when you
abuse it to multiplex user interface elements; because here it's not
about availability, it's about multiplexing.
I think we should reconsider the way we decide on views and related
components. Perhaps using a routes-like approach, e.g.
browser:page
...
for=.interfaces.IHelpCenter .interfaces.IDocument
/
(to target documents inside the help center section). Or whatever
language/abstraction that can fit the bill. Note that to match this
for clause, something more than a simple component lookup is
required.
I'm not sure that I see the need for that personally, but maybe it just
hasn't sunk in yet why I'd want to do that.
I did want to go ahead and bring up a completely different use case that is
very common in the wild but doesn't seem to be addressed in ZCA or this
generic formulation. Let's call it the Photoshop model, since hopefully
everyone knows what Photoshop plugins are. You have N number of plugins
that define a particular interface that are all registered but with no
preferential treatment in terms of look up--just a list of things you could
possibly use, with choice driven by the user.
registry.look(img_processor)
[ FuzzyCloudsPlugin ojbect at 0x, SatanicRequestPlugin at
0x, GreeneryPlugin at 0x, etc...]
or maybe a dict, more like:
registry.look(img_processor)
{ 'Fuzzy Clouds': FuzzyCloudsPlugin ojbect at 0x,
'Satanic Request': SatanicRequestPlugin at 0x,
'Greenery Plugin': GreeneryPlugin at 0x,
etc...
}
Now, I have no idea whether or not we actually care about this use case. An
application that uses plugins like this could easily define it's registry
and registration process. But, it had occurred to me, that if you're
throwing around the word plugin to people not already familiar with ZCA, a
lot of people are going to be thinking this model.
Chris
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] removing the lxml dependency from bfg
On Mon, Apr 27, 2009 at 1:37 PM, Malthe Borch mbo...@gmail.com wrote: 2009/4/27 Martin Aspeli optilude+li...@gmail.comoptilude%2bli...@gmail.com : I've never once written a web app that didn't need templating, because I've never written one that only responds with text/plain and writing HTML with print or string manipulation is just lame. It's possible though :-) I guess the point is that *most* apps need templating and since we have a strong offering (here are mostly mean the ZPT *language*, not any particular implementation), let's include and promote it (at least to some extent). In response to the original question, it seems that everyone is on board with factoring out genshi and xslt to add-on packages and leaving just chameleon.zpt as the one template system that ships with BFG. Did I get that right? Chris ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] removing the lxml dependency from bfg
On Mon, Apr 27, 2009 at 4:48 PM, Wichert Akkerman wich...@wiggy.net wrote: Previously Malthe Borch wrote: 2009/4/27 Reed O'Brien r...@reedobrien.com: +0 I think it is OK to have a default one. Think hello world. Devil's advocate here, but: print htmlbodyHello world/body/html You kind of don't need a templating language; in particular, you might want to serve up binary files only, combined with JSON input/output. We actually do that in ``repoze.filecat``. That works, but any first user of repoze.bfg is bound to want to try a template, and not bundling any default templating languages will make that first introduction to bfg more complicated. I think bundling chameleon.zpt is fine, but just wanted to point out that the canonical way to get started with BFG is via the paste script and that sample app created by that could easily have a dependency on something that BFG doesn't. You could theoretically suck in chameleon.zpt there to get people started *and* not have to make it a dependency of BFG. Not that I'm suggesting we change it now. Just saying. ;) Chris ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] removing the lxml dependency from bfg
Sorry. Just pretend like it really did end there. ;) Chris On Mon, Apr 27, 2009 at 8:20 PM, Martin Aspeli optilude+li...@gmail.comoptilude%2bli...@gmail.com wrote: Tres Seaver wrote: Amen. Or should that be So say we all! :) Not any longer... (sniff) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
