Re: [Repoze-dev] removing the lxml dependency from bfg
2009/4/27 Chris McDonough chr...@plope.com: chameleon.genshi still depends on lxml. Currently BFG has c.genshi support, but when we move to the new chameleon version, we'll need to package chameleon.genshi support outside bfg itself in an add-on package (which will still depend on lxml). Or we make chameleon.genshi not depend on lxml. The reason why ``chameleon.genshi`` depends on lxml is match-templates, which do require a post-render step where the document must be parsed with XPath-selector methods (bound to particular elements in fact) passed on to callbacks. It's a bit convoluted. While I do think the concept of match templates is cool, perhaps it should be let gently out of the package again, because as it happens, the support isn't very solid. Genshi is a great language in itself; I don't think it needs match templates to qualify. The non-lxml versions of chameleon.core rely on the etree module, which is only present in Python 2.5+. We'll either need to make 2.5 the lowest supported BFG version or we'll need to change chameleon.core to fall back to an add-on elementtree module for the same functionality. Let me note two things: 1) ElementTree is only used to validate inserted content in debug-mode. 2) On Python 2.4, the ``ElementTree`` package is added as an install_requires dependency. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] Turbogears2 identity variable in templates
Hello, Today I took some time to review the state of affairs for checking for what used to be identity in TG1. A little reminder of the API http://docs.turbogears.org/1.0/UsingIdentity#using-identity-in-templates IMO that api was really good as tg.identity (the template variable) was a simple proxy to the current logged in user and some handy methods. Fast forward to TG2 we have a very different API first it's a dict and not a Bunch (aka attribute access) template_vars.tg.identity.keys() ['userdata', 'repoze.who.userid', 'timestamp', 'tokens', 'user', 'groups', 'permissions'] more interesting than that template_vars.tg.identity returns None when the user isn't logged on. which means you will have to precheck all your access tests in something along the lines of if tg.identity and tg.identity['user'] == something which is too weird. on top of that it seems to me that checks in the form of are simply not possible py:if='admin' in tg.identity.groups is there an obvious way of doing this with repoze.what that I'm missing? Also keep in mind this is pure syntax sugar as the real security check was done in the controller. Last but not least is this a class that is worth including in r.what? or should we keep it TG only? IMO this api is nice enough to work on any python template/framework and I think it's totally worth pushing into what. ___ 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 Apr 27, 2009, at 1:40 PM, Chris Rossi wrote: On Mon, Apr 27, 2009 at 1:37 PM, Malthe Borch mbo...@gmail.com wrote: 2009/4/27 Martin Aspeli optilude+li...@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? +1 from me. --Paul___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Reed O'Brien wrote: On Apr 27, 2009, at 1:46 PM, Chris McDonough wrote: On 4/27/09 1:42 PM, Paul Everitt 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? +1 from me. +1 from me too. +1 Amen. Or should that be So say we all! :) Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ9fTZ+gerLs4ltQ4RAgEhAKCiT8BsLP1bdDiDVOK3hV7DjWnVWACfXeTw BGWqf0i+fhChGaCwO+AdNiU= =WbKl -END PGP SIGNATURE- ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.plugin documentation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris McDonough wrote: On 4/27/09 1:28 PM, Martin Aspeli wrote: Chris McDonough wrote: But anyway, yeah. For someone who has never used zope.component, though, it's really not that important (more strictly compares to zope.component). Reading that page as someone who does use zope.component, I was also not entirely convinced of the rationale for this package. I'm not saying there isn't one (though it smells a bit unfortunate that we're inventing a plugin system that's almost the same as zope.component, yet incompatible), but the aforementioned documentation didn't explain it sufficiently IMHO. There's no *good* reason. The only reasons are bad. Agreed. The primary driver is that we're trying to work with the Pylons community to share implementation bits. I suggested that they might use something like zope.configuration to do system configuration. But it turns out that some in that community are completely befuddled by zope.component and those in that community who are not befuddled by it are actively hostile to it. They may still be befuddled by and hostile to something that is simpler, but at least we'll have something to argue about on technical grounds rather than emotion. I can't see much reason for us to try to share code with people who won't even attempt a rational evaluation of the candidate. -1 to bikeshedding this thing further; +1 to an 'svn rm'. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ9fWD+gerLs4ltQ4RAhfEAJ91VMGLi5IaiKqw3+qQzWLEWJ6h/ACg2vMa G4SaaBCNiVrEutkvt2mSVI0= =0dXZ -END PGP SIGNATURE- ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.plugin documentation
On 4/27/09 2:12 PM, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris McDonough wrote: On 4/27/09 1:28 PM, Martin Aspeli wrote: Chris McDonough wrote: But anyway, yeah. For someone who has never used zope.component, though, it's really not that important (more strictly compares to zope.component). Reading that page as someone who does use zope.component, I was also not entirely convinced of the rationale for this package. I'm not saying there isn't one (though it smells a bit unfortunate that we're inventing a plugin system that's almost the same as zope.component, yet incompatible), but the aforementioned documentation didn't explain it sufficiently IMHO. There's no *good* reason. The only reasons are bad. Agreed. The primary driver is that we're trying to work with the Pylons community to share implementation bits. I suggested that they might use something like zope.configuration to do system configuration. But it turns out that some in that community are completely befuddled by zope.component and those in that community who are not befuddled by it are actively hostile to it. They may still be befuddled by and hostile to something that is simpler, but at least we'll have something to argue about on technical grounds rather than emotion. I can't see much reason for us to try to share code with people who won't even attempt a rational evaluation of the candidate. Personally, I think there is benefit to both reaching out to people who aren't quite on board as well as participating in some introspection about why we do what we do. I don't attempt a rational evaluation of, say, Mathematica, because I just can't see how it would help me in my every day life. OTOH, if I had a library that just did simple graphing, I'd have some context as to how it might help me (even if I ended up disusing it anyway). -1 to bikeshedding this thing further; +1 to an 'svn rm'. Bikeshedding? I'm beggining to hate that word. Like Pythonic. I really don't care about the bits; it's more a decomposition exercise. There's always your mailer's ignore thread. - C ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.plugin documentation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Malthe Borch wrote: 2009/4/27 Tres Seaver tsea...@palladion.com: I can't see much reason for us to try to share code with people who won't even attempt a rational evaluation of the candidate. -1 to bikeshedding this thing further; +1 to an 'svn rm'. I think the primary reason why people shy away from ``zope.component`` is that it's abused too often; it's hard to see that it's really quite simple when some users are multi-adapting four ways to look up a viewlet which happens to rely on twenty other lookups to render itself. I think you are being generous: I have very little doubt that the objections come first from the presence of 'zope' in the package name, and second from the very idea of using a tool which codifies and categorizes abstractions, never mind the benefits. Perhaps if campaigned a bit on the grounds of the relative ease-of-use of the ZCA, we wouldn't have to dumb it down to the level of ``repoze.plugin`` (no offense) in order to get adoption outside of Zope. These are folks who, on the whole, prefer *code generation*, and place and extremely low value on abstraction and pluggable reuse. I don't think repackaging is going to help the gag reflex. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ9fiA+gerLs4ltQ4RArkdAJ93UdkIupl5Xa52CHb4A+SmxBRAgQCfeoFW 9SG7sADfzbZehsa5KpQkcOk= =xHg2 -END PGP SIGNATURE- ___ 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
I think its nice to have a default... ...but I think one default is enough ;) +1 Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Reed O'Brien wrote: On Apr 27, 2009, at 1:46 PM, Chris McDonough wrote: On 4/27/09 1:42 PM, Paul Everitt 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? +1 from me. +1 from me too. +1 Amen. Or should that be "So say we all!" :) Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ9fTZ+gerLs4ltQ4RAgEhAKCiT8BsLP1bdDiDVOK3hV7DjWnVWACfXeTw BGWqf0i+fhChGaCwO+AdNiU= =WbKl -END PGP SIGNATURE- ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev -- Fergus Doyle Lead Developer 120 Long Acre, Covent Garden, London. WC2E 9PA. www.largeblue.com, fergus.do...@largeblue.com +44 (0)20 7240 0330 ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.plugin documentation
On 4/27/09 1:18 PM, Chris McDonough wrote: I find the introduction lacking; why do I care about indirection, what's the benefit. Good point. Um. Why *do* we care about indirection? In particular, why do we care about this sort of generic-function-ish dispatch pattern we call adaptation? Why do we care about it for *every* application? I'm too brainwashed to answer that question without thinking about views. If we want something to be bit off by the larger Python community, we need an answer for this. Answering myself with the kind of navel-gazing which is sure to drive Tres nuts ;-): - We use the heck out of indirections during unit testing. In most of the apps I write personally, the ZCA indirections are the only thing that make it *possible* to write unit tests rather than needing to write functional tests. But typically during testing the idea that some *adapter* is registered against more than one requires interface is just something that we deal with rather something that is actively desirable (because we always only have one implementation during unit testing); the actual multidispatch is to support the below case. - We use adaptation and utility indirections in applications to allow people to override implementations without needing to change the code. Most non-Zope people associate this desire to provide pluggability, correctly or incorrectly, with CMS systems. But there's something to this conclusion because indeed the ZCA indirections were originally meant to replace use of something like acquisition to find values in content space. I suspect we are quite brainwashed here, or at least incapable of discounting this use case, because we tend to treat every application as something that might turn into a framework. - We use utility indirections (or at least I do) to retrieve application-specific configuration values (e.g. BFG's ISettings utility, which offers no behavior except as a bag-of-names). I have some ideas about how you might layer several systems together to allow people to only bite off one bit of software for each of these cases. #2 is the most problematic and would be at a higher layer. - C ___ 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
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. Wichert. -- Wichert Akkerman wich...@wiggy.netIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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] repoze.plugin documentation
Hey, On Mon, Apr 27, 2009 at 6:19 AM, Malthe Borch mbo...@gmail.com wrote: I realize this documentation[1] is still in progress; yet, here are some comments, posted to the list to maybe encourage some kind of debate (since it's likely that there will be several consumers of this package in repoze.* in the future: I find the introduction lacking; why do I care about indirection, what's the benefit. Next, I can't read through the documentation if it's going to be all a and somecomponent; can we have some kind of context, e.g. a story-line or some likely scenario. This would help a lot in motivating the package in the first place, too. Yeah, some times I happen to try to explain things in terms of a and b and soon I realize it wasn't effective. What I *think* it would be more effective in first place is *why* people should write apps that one can extend by layering other components on top of it rather than monkey patching or doing all sorts of incantations to achieve what they want. The spelling is important so people can understand how to implement their story (if they know the so called AOP) by using a given package. repoze.plugin just happen to make it easier to associate the concepts of AOP to the code and maybe attract more people. Cool package after all . Fernando ___ 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
