[Repoze-dev] [issue31] New blog backend
Paul Everitt [EMAIL PROTECTED] added the comment: We could get commenting with, probably, 2 hours of work on pyxblosxom. On the former, is Plone 3 enough? Martin Aspelli, for example, seems to have a decent-enough blog. I suspect that the repoze.org blog isn't something that we want to spend a lot of time getting running, correct? --Paul On Apr 3, 2008, at 9:31 PM, Chris McDonough wrote: New submission from Chris McDonough [EMAIL PROTECTED]: We need a new blog backend that supports posting entries through the web as well as commenting. -- messages: 88 nosy: chrism priority: feature status: in-progress title: New blog backend __ Repoze Bugs [EMAIL PROTECTED] http://bugs.repoze.org/issue31 __ ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev __ Repoze Bugs [EMAIL PROTECTED] http://bugs.repoze.org/issue31 __We could get commenting with, probably, 2 hours of work on pyxblosxom.On the former, is Plone 3 enough? Martin Aspelli, for example, seems to have a decent-enough blog.I suspect that the repoze.org blog isn't something that we want to spend a lot of time getting running, correct?--PaulOn Apr 3, 2008, at 9:31 PM, Chris McDonough wrote:New submission from Chris McDonough [EMAIL PROTECTED]>:We need a new blog backend that supports posting entries through the web as well as commenting.--messages: 88nosy: chrismpriority: featurestatus: in-progresstitle: New blog backend__Repoze Bugs [EMAIL PROTECTED]>http://bugs.repoze.org/issue31>_Repoze-dev mailing listRepoze-dev@lists.repoze.orghttp://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] Keeping pages out of deliverance's hands
Tom Lazar wrote: On 2008-03-12 14:58:14 +0100, Tres Seaver [EMAIL PROTECTED] said: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Reinout van Rees wrote: Paul Everitt schreef: Tres made a urienv branch for Deliverance that allows you to put a middleware step in front of Deliverance to control which theme gets set. That is the one that is now merged back to trunk, right? Yes. However, what you want is simpler: you can write a middleware step that sets the notheme flag on the query string. Hey, neat. Didn't know that one :-) Works like a charm in the browser at least. For making a middleware step: does anyone know a paster skeleton for that? Googling for paster skeletons for creating stuff that is to be used by paster is a bit hard :-) Nope, we've just started for existing examples. does anybody have a working example of this? i would a) need the functionality and b) it sounds like an excellent starting point to write simple middleware. Does this == paster skeletons, or the Deliverance keep-your-hands-off thing? -Paul ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] bfg zcml directives...
On Dec 20, 2008, at 2:12 PM, Chris McDonough wrote: Paul Everitt wrote: On Dec 20, 2008, at 1:59 PM, Chris McDonough wrote: As a result of messing around with the ZCA + ZCML outside the context of Zope, I've found that it may be possible to significantly reduce the number of egg dependencies of BFG by replacing the code that allows the following ZCML directives to work: - utility - adapter - interface - subscriber As such, I'm thinking of ditching the handlers written zope namespace for these directives in favor of handler written in the bfg namespace. So, for Interesting idea. I suppose the decorator syntax wouldn't change, but the machinery behind it would. zope.configuration doesn't provide any decorator syntax, but if you mean the Sorry, I meant repoze.bfg.convention. I believe that, under the hood, it's doing the same configuration work as ZCML. ZCML syntax, yes, exactly; it wouldn't change for the utility or adapter directives. One fallout change would be that instead of: bfg:view for=.models.MyModel view=.views.my_view / The view directive would be just: view for=.models.MyModel view=.views.my_view / (because the bfg XML namespace would be the default). example, rather than doing: configure xmlns=http://namespaces.zope.org/zope; utility provides=.interfaces.IFoo factory=.foo.Foo/ /configure You would instead do: configure xmlns=http://namespaces.repoze.org/bfg; utility provides=.interfaces.IFoo factory=.foo.Foo/ /configure The down side of this is that it would mean that existing applications that used ZCML would need to change their ZCML, or they'd at least need to declare zope.security as an install_requires dependency and do a manual include of the zope.component ZCML: include package=zope.component file=meta.zcml / I think it's pretty reasonable to make that requirement in order to get that gain. Meaning, apps would still work with a one-line setup.py change and a line of ZCML. Right. Creating parallel adapter, utility and subscriber handlers is really how I should have started things out, but I didn't, and given that there are people using the system in the wild that this would cause problems for in a new release, I wanted to ask for comments. Here are the dependencies we might be able to shed by doing this: zope.location-3.4.0-py2.4.egg zope.publisher-3.5.4-py2.4.egg zope.security-3.5.2-py2.4-macosx-10.5-i386.egg zope.traversing-3.5.0a4-py2.4.egg zope.i18n-3.6.0-py2.4.egg pytz-2008i-py2.4.egg My personal opinion is that doing this is worth it for the long term. None of these packages actually *do* anything for bfg apps, they're just required to satisfy dependencies of features we can't use. For applications that do a Zope-ish architecture (ZODB, security, etc.), how many of those packages would they need to pull in manually? Security is not a feature provided by any Zope package in a BFG app; ZODB requires whatever its setup.py says it requires. In terms of the Zope-ish applications we (Agendaless) are developing under BFG, no changes would need to be made to any setup.py install_requires. Right, I meant the latter. For people that are writing BFG applications that smell like Zope (e.g. KARL), how many of those packages would still be used, thus lessening the win in that case? --Paul ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] bfg zcml directives...
On Dec 21, 2008, at 9:31 AM, Chris McDonough wrote: But one thing won't happen: bfg is not going to live with four inappropriate dependencies forever to service a goal of fidelity. Repoze is the place where we co-habitate with the goals of other projects, such as Zope and Plone. BFG, though, is where we make something that is more fun than frustration, defining the goals and limits to serve the purpose of BFG. Thus, +1M on Chris's point. People that want the fidelity of Zope already have other choices. Hell, Zope itself gives them two very different choices, and Grok is a third. People who want to enjoy other Python web stuff as part of the core, in combination with the fun part of Zope, and strive for fun and minimalism, now have a place to hang out. People that don't share that goal, or have the goal of Zope fidelity, are well-served elsewhere. BFG != Zope, by the original motivation of its creation. --Paul ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] bfg zcml directives...
On Dec 21, 2008, at 11:36 AM, Martin Aspeli wrote: Paul Everitt wrote: That seems like a false leap. I freely admit to using hyperbole in my original email to draw out a debate. :-) It does bother me a little, though, that the fix seems to be to fork/re-implement rather than to try and push something downstream. No-one in Zope is disagreeing that the dependencies should be untangled. Few people seem to have the time and impetus to do something about it. When BFG does, then it'd be great if that effort could benefit everyone. Chris provided an analysis showing that this is more than packaging. There are policy decisions involved. Could you comment on his writeup about the policies and side effects? Should people that want to use Zope-style components, also be forced to digest trusted adapters? Or, is someone brave enough to convince the Zope world to either ditch that idea? Or, shepherd a proposal to make it parameterizable? It isn't their itch, so they won't implement the proposal. Instead, you'll be asking the people that *don't* want trusted adapters, to do the work to paramaterize it. Thus, this is harder than just untangling dependencies, IMO. My specific reaction, by the way, was not to BFG, but to Chameleon. Does chameleon.zpt belong to BFG? This wasn't my impression. And if so, does Plone need to be wary of adopting it, for fear of it growing a lot closer to a BFG philosophy that's not necessarily going to be compatible with Plone's architectural vision going forward? I presume that Chameleon belongs to Malthe et al. I doubt a change would be made that he disagreed with. But I'll invert the question: does Chameleon belong to Zope? I believe Chameleon aspires to life beyond the Zope island. If so, then it is a Great Thing to shed those rather harmful side effects, while enabling a *TRIVIAL* way to sign back up for them in Zopeland. Everybody wins. What about the other repoze.* packages? Which ones are going to inhibit Yes, you made this assertion, and I'm asking you to demonstrate the facts behind that assertion. Are you claiming that repoze.zope2 has changed? repoze.retry? repoze.tm? repoze.who? this parallel universe where things are done almost like other parts of Zope, but not quite? After ZCML, what's next? Hopefully, lots of stuff is next, but for BFG. Repoze is the place of co-habitation with the goals of fidelity. There is an obvious risk here, as demonstrated by the chameleon.zpt case, that the desire to prune transitive dependencies means BFG either ends up being more monolithic (i.e. owning its own, tightly controlled, Calling bfg a monolith is, like calling it an island, just plain silly. BFG is the opposite of a monolith, as I demonstrated in my previous mail. Also, BFG does not have the goal of fixing Zope's tightly-controlled monolith. Again, Chris spent the time to show that this is more than pruning transitive dependencies. This is pruning harmful (to non-Zope), side- effect-ful (to non-Zope) policies that are part of the goal in Zope. minimal versions of everything) or pushing alternate methods for things like configuration into lower level packages, because dependencies can't be kept to an absolute minimum otherwise. Re-use always carries a risk of getting more than you bargained for, because the author of the original package may not have intended it to be re-used in exactly the way you need. But sorry about the island gripe - I'm very grateful for the work repoze is doing to play well in Python land, and, as you know, I'm a strong advocate of Plone and Zope riding that bandwagon. I just worry that sometimes this may mean leaving the rest of Zope behind, rather than work to bring it along. Chris has worked hard *in Repoze*, harder than just about anybody else, to bridge the gap and bring it along. He's asking that BFG be his own place, where he can build just the thing he wants, and leave out the parts he doesn't want. People don't have to use it if that isn't their goal. --Paul 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
Re: [Repoze-dev] bfg zcml directives...
On Dec 22, 2008, at 1:06 PM, Martin Aspeli wrote: Wichert Akkerman wrote: Previously Martin Aspeli wrote: If you want to pull in, say, plone.supermodel (a pure Zope 3 package that should be re-usable and may be useful to BFG if it ever wants to serialise Zope 3 schema interfaces to/from an XML representation) well, it uses zope:* ZCML directives. Are you going to fork plone.supermodel? I would be very tempted at least. Or decide to not use supermodel. Which would mean that the BFG-intersecting parts of the repoze stack would be a fork or re-implementation of all Zope stuff that was interesting to it. I don't think that's a sustainable way forward. Or at least, then repoze should stop billing itself as the maturity of Zope now with the flexibility of the WSGI future. Demonstrably false. Please list the Repoze components, particularly the ones Plone is using, that were affected by this change. --Paul ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] Anybody going to the Plone Symposium next month at Penn State?
Hi there. Just as an FYI, we're doing a BFG tutorial at the Plone Symposium. Anybody gonna be there? I'm also giving a talk on the big BFG project that we've been working on. --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
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] Genshi match templates without ``lxml``
Well, this is pretty doggone interesting. I do worry that the last sentence is pretty optimistic. I wonder, in light of our #repoze discussions about theming, what you think this would mean if the stuff below landed? --Paul On Apr 28, 2009, at 11:41 AM, Malthe Borch wrote: Adressing the Repoze-list here, since Chameleon is currently kept in this repository. For those not in the know (certainly before I read the documentation[1], I was one of them), Genshi has a feature called match templates which lets you first render a template, then apply a second template to elements matched by an XPath-expression. If this sounds a bit strange, it's because it is––but it's useful because it can be used to sculpt HTML in a way similar to Deliverance and/or XSLT. At any rate, it's a Genshi feature and we do support it in ``chameleon.genshi``. Problem is, ``lxml`` is required for this to function––what's more, this solution is suboptimal in terms of performance (which is the raison d'etre for Chameleon in the first place). There are two scenarios: 1) Match templates are defined and used on elements appearing in the same template; 2) Match templates are brought in through an XInclude, dynamically, at render-time. Assuming we know how to match elements using XPath, the first scenario is reasonably easy; the difficult being only that the XPath ``select`` method (corresponding to the matched elements) must be made available. The second scenario is more difficult, because these includes aren't predictable at compile-time; as such, we have to match elements as we render and apply the templates. As mentioned, this is currently solved by post-processing the output using ``lxml`` and applying match templates using callback-methods. It's not horrific, but it's also convoluted and slow–––and slightly buggy. However, I think there's a way out of the deadlock. If we compile the template specifically for each XPath-expression (on-demand, of course), we can match the elements at compile-time and have a situation similar to (1). This leaves us with the task of porting/writing an XPath selection routine; it needn't be complete I think (Genshi's surely isn't). \malthe [1] http://genshi.edgewall.org/wiki/Documentation/xml-templates.html#id5 ___ 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.bfg) Adding several models
On Jun 4, 2009, at 8:26 AM, Malthe Borch wrote: 2009/6/4 Jonas Melian jo...@mailup.net: Is possible to have several models? If it's so, how are they returned from root? The default object traversal uses the ``__getitem__`` method to traverse to subobjects. These could be instances of other models. The lxmlgraph tutorial I wrote (which should probably be deprecated) shows how traversal can get very custom: http://docs.repoze.org/bfg/tutorials/lxmlgraph/step02.html#module-models-py In that I use the identifier as an argument to an XPath inside a __getitem__. --Paul ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] Q: Anybody using wsgi.file_wrapper and modwsgi?
Hi all. This is a question aimed at the subset of people that might be using modwsgi. The WSGI spec has a concept for file wrappers: http://www.python.org/dev/peps/pep-0333/#optional-platform-specific-file-handling modwsgi has supported this, had some bugs in it, and now seems stable: http://code.google.com/p/modwsgi/issues/detail?id=132 http://groups.google.com/group/modwsgi/browse_frm/thread/e7111816e70d236a http://groups.google.com/group/modwsgi/browse_thread/thread/99b7c7f208918a0c Just curious if anybody has any experience with using this as a way to deliver files from your app? --Paul ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Set up a MongoDB with BFG
On Feb 1, 2010, at 12:35 PM, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joan Miller wrote: Does anybody could write a little example about how to set up a MongoDB (through Ming [1]) data store with BFG? This one to be used in TG2 [2] [1] http://merciless.sourceforge.net/ [2] http://bitbucket.org/percious/c5t/src/tip/c5t/core/model/auth.py - From what I can tell, the model classes in the c5t example would work pretty much unchanged in a BFG app: if you used routes instead of traversal, the views could use the same pattern for finding the model objects. I think Reed O'Brian was doing some work on Mongo-based BFG apps. I've CC'ed him just in case he missed seeing your post. http://svn.repoze.org/playground/redir/repoze.mongo/trunk/ --Paul ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Typo in the Basic Layout page
Good catch, just checked in a fix. --Paul On Feb 22, 2010, at 2:00 AM, Douglas Cerna wrote: Hey everybody. I'm starting to read the BFG documentation, which is great btw, and I noticed this tiny typo in the Basic Layout page: persistint.mapping.PersistentMapping ^ Douglas ... allí es cuando te das cuenta que las cosas malas pueden resultar bastante buenas... - Lionel Messi Por favor, evite enviarme adjuntos de Word, Excel o PowerPoint. Vea http://www.gnu.org/philosophy/no-word-attachments.es.html ___ 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] static views and @@
On Jun 24, 2010, at 3:34 AM, Wichert Akkerman wrote:
On 6/24/10 09:28 , Chris Withers wrote:
Hi All,
I've registered a static view with:
config.add_static_view('static','mypackage:templates/static')
Which, if I read the docs, means I should be able to build urls such as:
/@@static/some.css
I can't remember seeing any use of @@ in BFG docs. Where did you see that?
http://docs.repoze.org/bfg/current/narr/traversal.html#traversal-chapter
The traversal algorithm exposes two special cases:
[snip[
• If any path segment element begins with the special characters @@
(think of them as goggles), the value of that segment minus the goggle
characters is considered the view name immediately and traversal stops there.
This allows you to address views that may have the same names as model instance
names in the graph unambiguously.
--Paul
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] Chameleon vs. jQuery templating, round one
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
Re: [Repoze-dev] Chameleon vs. jQuery templating, round one
You're right, I forgot to mention that this was going to be the plan I went
with to get around Chameleon parse-time problems. On one hand, it kinda goes
against the accepted pattern for doing client-side templating...everybody just
jams stuff into the original page.
OTOH:
1) It results in the same thing.
2) It lets you keep the templating close to the jQuery plugin that might bundle
up the larger widget you're making.
3) It can help avoid keeping both the QUnit templating in sync with the ZPT
templating.
So, you're right that the pattern you have below is a good one.
--Paul
On Oct 12, 2010, at 2:32 PM, Chris Rossi wrote:
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
___
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
On Oct 13, 2010, at 3:39 AM, Malthe Borch wrote: On 12 October 2010 13:40, Paul Everitt p...@agendaless.com wrote: 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. Wichert's advice to prevent $-evaluation is apt here, although you could also escape it – I think it's just \$. Dang, that's exactly the thing I was planning to ask for, and it's already there. :) Thanks guys, makes it easier when doing browser-templates the normal way. I might still look at Chris Rossi's way. As for % and % –– I think Chameleon 2.x (work in progress, but almost there) will parse and accept such tags. That might help on the situation then. Oh, interesting, will be fun to see how that works. --Paul ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
