Re: [Repoze-dev] [Pyramid-checkins] Broken: Pylons/pyramid#1123 (master - ba0593a)
+1 Python 3.2 is not likely to be relevant going forward because conservative users are anyway still on 2.x. Malthe On Wed 5 Nov 2014 at 21:39 Wichert Akkerman wich...@wiggy.net wrote: On 05 Nov 2014, at 17:55, Tres Seaver tsea...@palladion.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/05/2014 10:44 AM, Wichert Akkerman wrote: On 05 Nov 2014, at 15:57, Tres Seaver tsea...@palladion.com wrote: Unicode literals are a no-no for 3.2-compatibility: How important is 3.2 compatibility? We don't ordinarily drop a supported Python version a non-major release. So we can consider dropping 3.2 for Pyramid 1.6? Dropping that would make straddling easier, which sounds worth it to me. As a dependency for pyramid, if translationstring drops 3.2 compatiblity, we would need to pin it for release branches to versions which preserved it. Note that the classifiers for translationstring 1.2 still claim support back to 2.4: https://pypi.python.org/pypi/translationstring/1.2 although testing versions 2.6 with tox is no longer feasible. I’ve updated that for the 1.3 release. I’ve also setup travis to automatically run tests on Python 2.6-2.7 and 3.2-3.4. I don’t know if anyone uses the tox configuration, so I’ve left that in place. Wichert. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org https://lists.repoze.org/mailman/listinfo/repoze-dev ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org https://lists.repoze.org/mailman/listinfo/repoze-dev
[Repoze-dev] pagetemplates.org back up
My apologies if its downtime has caused issues. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org https://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] translation problem
This is also a problem on regular Zope, fwiw.
It's not particular hard to call ``translate`` first on the mapped
values, but it's of course a little tedious. The question is whether
it's too much of an overhead to go through any mapping, looking for
messages (i.e. the automatic alternative).
\malthe
On 27 July 2011 16:27, Wichert Akkerman wich...@wiggy.net wrote:
We are running into an i18n conundrum with deform. Basically what happens is
this:
- we have a sequence item in a colander schema with a title, which
is a TranslationString instance
- deform generates an add-button for the sequence which uses this
title using something similar to _('Add ${title}', mapping={...})
When the add button is rendered its label is translated, but the sequence
item title is not translated. I can see two ways of fixing
this:
1. translationstring detects translatable items in its mapping, and
if it finds any it translates those before replacing them
2. deform (and others who do similar things) must manually translate
mapping items
I'm not sure what the best option is. The second option may not be viable
since I'm not sure the request or translate function is available
at the places where you would need it. The first option adds extra
complexity to translationstring, which isn't very attractive either. I
suspect that is still the better option though.
Opinions?
Wichert.
--
Wichert Akkerman wich...@wiggy.net It 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
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Chameleon: XInclude support for ZPT templates
On 1 April 2011 15:28, Fabio Tranchitella kob...@kobold.it wrote: as discussed briefly with Malte on #repoze, I'd like to add XInclude support to the ZPT Chameleon templates. As it turned out, it is quite simple and the patch is attached to this message. Sorry for the late response. Patch looks good. But I wonder why it is necessary. Did you know that you can include a template like this: metal:use-macro=some_template_object_doesnt_have_to_be_a_macro Of course, with XInclude you get an option to load a template from a file. But it should be a simple matter to have (maybe via framework support): metal:use-macro=file: other_template_relative_to_this.pt (or similar). \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Chameleon: a few newby questions
p metal:use-macro=templates['header.pt'].macros['header'] / [snip] Is there any shorter way to do this? Can the template loader be passed implicitly? It would easy to include a load function or even expression, i.e. load: ../header.pt, but as that example illustrates, it would be relative to where the template itself is located. We could include something like that. Anyone else with an opinion on this? 2) Repeat and macro expansion don't seem to respect indentation levels. Are there any options for pretty formatting of html output? I guess I'll have to parse then reformat in a separate phase? Repeat clauses should have indentation, computed as the whitespace on the line of element definition. The macro implementation does not take indentation into account. That might be a bug. I don't know the performance impact of having to go through the items in the output queue and add the indentation to each. Might not be bad. 3) Can we have 1 template per file? You want to have them named somehow then? What sort of syntax are you thinking about it? \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Chameleon: a few newby questions
On 29 March 2011 11:02, Hanno Schlichting ha...@hannosch.eu wrote: Isn't that exactly what macros give you via define and use? Except macros are funny in that they render implicitly where defined. But you could definitely have a template that includes any number of macros. Just make sure to not render that template directly then ! \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] repoze.zope2 release
Are there any impediments to releasing the trunk of repoze.zope2? \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Migration to Github
On 24 March 2011 12:02, Brian Sutherland br...@vanguardistas.net wrote: I'd like to make a new release of repoze.bitblt (when my pull request is accepted). Is there any documentation anywhere about how releases should be tagged/created within the Repoze github repository? Looking at e.g. https://github.com/repoze/repoze.vhm, it seems that releases are just given a version-tag, e.g. 1.1. $ git tag -s 1.1 $ git push --tags \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] Chameleon and attribute escape
Just wanted to follow up on some issues with attribute escaping that were asked on the channel. I believe I have now adressed these concerns: https://github.com/malthe/chameleon/commit/800306a7433250120e039773ef013702dbaec3fc In particular, you can now use invalid markup such as: span ... alt=true false ... It's not valid, but it's also not the business of the template engine to change the markup. With the changeset above, it's pretty much what you write is what you'll get. There should be much fewer surprises. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Chameleon and attribute escape
On 7 March 2011 11:59, Wichert Akkerman wich...@wiggy.net wrote: Is there a mode to make it impossible to accept or generate invalid markup? For some of us that is very important. That's what this changeset does. It allows you to use invalid markup to the extent possible. For instance, you can use HTML markup: div br /div \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Chameleon and attribute escape
On 7 March 2011 12:07, Wichert Akkerman wich...@wiggy.net wrote: That is the opposite of what I want: I would like invalid markup to be rejected, and I want it to be completely impossible to generate invalid markup. I see. Perhaps there could be a validator sitting in front of the compiler which (as the default) warns of invalid markup. The correct behavior in my view is to accept any markup, but ideally warn (using ``logging.warn``) about it. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Chameleon and attribute escape
On 7 March 2011 12:11, Wichert Akkerman wich...@wiggy.net wrote: For input possibly. I consider invalid markup as possible output to be a bug in the template engine. Right. Note that any dynamically included content will undergo escaping: If your input is valid, you know that the output is going to be valid, as long as content is not included as structure. Now if your application requires the inclusion of user-submitted HTML content or other similar content is not part of the application distribution itself, it should be sanitized prior to usage in the template engine (using an engine such as tidy). This is expensive and should probably happen when that content is submitted in the first place. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] chameleon zpt: structure or not?
On 2 March 2011 03:36, Shane Hathaway sh...@hathawaymix.org wrote: Also, a quirky behavior of the reference TAL implementation is if you use unknown attribute names in the tal namespace, those attributes get stripped from the output. It's a useful feature; it allows me to write comments about a tag. I always spell the comment attributes as tal:comment. Chameleon 2.0-rc2 raises an exception on my tal:comment attributes, while 1.3 ignored them. Can we have tal:comment or the original behavior back? Yes. I've reported it here: https://github.com/malthe/chameleon/issues/4. Thanks, \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] chameleon zpt: structure or not?
On 2 March 2011 08:18, Chris Withers ch...@simplistix.co.uk wrote: Interesting, I use this technique a lot, and I didn't experience this problem with my brief test of 2.0-rc2. Mind you, Shane means tal:comment in *attributes*: div tal:comment=This is a throw-away div ... /div I think this is a fairly quirky feature of ZPT. Actually, I'd be inclined to only allow ``tal:comment``, because allowing any tag takes away our ability to warn users of typos which might take a long time to track down. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] chameleon zpt: structure or not?
On 2 March 2011 19:27, Shane Hathaway sh...@hathawaymix.org wrote: I think it's unwise to support this meaning of the pipe character in Python expressions. I say the new behavior is better. Great. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] chameleon zpt: structure or not?
On 1 March 2011 12:00, Chris Withers ch...@simplistix.co.uk wrote: div class=batcher tal:content=pager/ ...doesn't appear to quote the html in the pager variable. This is different from normal zpt, why the change? It should definitely escape it in exactly the same way. Also, as a corollary, the following appears to be a no-op: div class=structure batcher tal:content=pager/ Am I right? Yes, but that's firstly because you need to use ``tal:attributes``, secondly because there is no structure keyword for attributes. It is simply not allowed to *not* escape an attribute value. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] chameleon zpt: structure or not?
On 1 March 2011 14:19, Chris Withers ch...@simplistix.co.uk wrote: So, it's quoting the tags but not the entities. Bug, no? Yes, it certainly seems so. Which version is this? div class=batcher tal:content=structure pager/ That should include the content in ``pager`` as-is. What do you get? Thanks, \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] chameleon zpt: structure or not?
On 1 March 2011 14:49, Chris Withers ch...@simplistix.co.uk wrote: Which version is this? 1.3.0-rc1 If you have the time, can you try the same thing in 2.0-rc2? Thanks! \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] Chameleon 2.x
The current development target for Chameleon 2.0 [1] is now stable and seems to be compatible with Pyramid (tests run). For information on what's new, see the readme. Minimum Python version is 2.5 (and compatible up to 3.2). PyPy is also supported (only fast-forward branch tested, but should work on newest release). If you have time to take it for a test drive, please do so and provide feedback either here (if specific to Pyramid / repoze) or as an issue on the tracker. Thanks! \malthe [1] https://github.com/malthe/chameleon ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Chameleon 2.x
Hey Attila, Use git to clone the repository, or simply download it as an archive from the page. Then add a ``develop`` section to your buildout, e.g. [buildout] develop = ../chameleon2 eggs = Chameleon \malthe On 25 February 2011 13:36, Attila Oláh m...@aatiis.me wrote: Hello Malthe, On Fri, Feb 25, 2011 at 12:14, Malthe Borch mbo...@gmail.com wrote: The current development target for Chameleon 2.0 [1] is now stable and seems to be compatible with Pyramid (tests run). For information on what's new, see the readme. I'd like to test-drive Chameleon 2 with a Pyramid app I'm currently working on (that needs to run on App Engine), but I can't update, as there's no link to version 2.0 on pypi (yet). I'm using buildout, what should I do to get version 2.0 (e.g. add the GitHub repo to find-links)? Or have you released it to another pypi server? Attila ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Chameleon and Genshi Text Templates
Hey Brian, That's right. It hasn't been implemented and it's a bit of false advertisement really. That said, implementing it should be relatively straight-forward. \malthe On 14 February 2011 17:20, Brian Sutherland br...@vanguardistas.net wrote: Hi, The genshi text template language doesn't seem to work at all with chameleon.genshi: http://genshi.edgewall.org/wiki/Documentation/text-templates.html In fact it seems that chameleon.genshi.template.GenshiTextTemplate cannot do anything more than string substitution. Am I missing something obvious? I've attached a test that I would have expected to have worked, should I commit that? -- Brian Sutherland ___ 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.repoze.org is offline.
Hey Tim, The server that's hosting the site was compromised yesterday. My slice there has been suspended. As of yet, I haven't gotten permission to access the files on there yet from the hosting provider. Thanks for reporting though. \malthe On 17 December 2010 14:22, Tim Hoffman zutes...@gmail.com wrote: Hi Folks In case you didn't notice, chameleon.repoze.org is offline. T ___ 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 chameleon unicode crash with wrapper views
Alternatively, enable implicit decoding using
``default_encoding=utf-8`` (in the template constructor). This is
enabled on Plone, for instance.
\malthe
On 16 December 2010 14:47, Tres Seaver tsea...@palladion.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/15/2010 10:18 PM, Iain Duncan wrote:
Not sure where I'm supposed to ask this now, here? Pyramid list?
I have view with a chameleon template that contains utf-8 unicode special
chars. It renders fine when rendered on it's own from a view. As soon as I
wrap that view with a wrapper view, I get errors with the wrapper choking on
the unicode.
My master views call method is like this:
def __call__(self):
tmpl_dict = {}
tmpl_dict['inner_content'] = self.request.wrapped_body
return tmpl_dict
I get the following traceback ( snipped ):
File
/home/jordans/Jordans/eggs/repoze.bfg-1.2.2-py2.6.egg/repoze/bfg/router.py,
line 130, in __call__
response = view_callable(context, request)
File
/home/jordans/Jordans/eggs/repoze.bfg-1.2.2-py2.6.egg/repoze/bfg/configuration.py,
line 1724, in _owrapped_view
wrapper_viewname)
File
/home/jordans/Jordans/eggs/repoze.bfg-1.2.2-py2.6.egg/repoze/bfg/view.py,
line 90, in render_view_to_response
return view(context, request)
File
/home/jordans/Jordans/eggs/repoze.bfg-1.2.2-py2.6.egg/repoze/bfg/configuration.py,
line 1663, in _bfg_class_view
response = inst()
File /home/jordans/Jordans/jordans/views/master_view.py, line 22, in
__call__
tmpl_dict['inner_content'] = u%s % self.request.wrapped_body
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 4090:
ordinal not in range(128)
Any clues?
The code in the traceback doesn't match the sample you showed above:
the 'wrapped_body' is an encoded string (WebOb responses always encode
the body with the supplied charset) which the view is trying to decode
(back?) to unicode without supplying the encoding. The default encoding
used by WebOb is 'UTF-8', so I would try:
def __call__(self):
tmpl_dict = {}
body = self.request.wrapped_body
tmpl_dict['inner_content'] = body.decode('UTF-8')
return tmpl_dict
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.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0KGHEACgkQ+gerLs4ltQ7FZQCgzIl5cIsJbt1viMO8KKAre97j
ne8An1T4tFdxXHTQzOcSJyWpP7hGiBcq
=Ty1s
-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] Chameleon templates and facebook namespace
Hey Eduardo, --- It shouldn't eat that namespace prefix. I wonder if this is still the case in the current Chameleon release. Have you tried? Sorry for the long delay in response. \malthe On 5 June 2010 18:29, Eduardo Diaz eduardo.d...@ediaz.me wrote: Hi, I'm trying to use facebook's xfbml, it uses a custom namespace which I declared like this: html xmlns=http://www.w3.org/1999/xhtml; xmlns:fb=http://www.facebook.com/2008/fbml; And in the body I write this: fb:login-button/fb:login-button The problem is that when the login-button part gets rendered I get: login-button/login-button Is there a way to tell chameleon to ignore certain namespace?? Thanks! ___ 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] Wrong URL to bug tracker in docs
This was fixed earlier on in the repository, but I have now also updated the live documentation. Thanks! \malthe On 29 August 2010 08:45, Chris McDonough chr...@plope.com wrote: This message was discarded because the sending address wasn't subscribed to the maillist, FWIW. On Sat, 2010-08-28 at 21:11 +0200, JW wrote: Hello, In the documentation for your Chameleon project, at http://chameleon.repoze.org/docs/latest/, there is an incorrect link to its bug tracker. It links to https://bugs.launchpad.net/chameleon, which is the bug tracker for the Chameleon blogging engine, my (now inactive) project, and not your template engine. It seems the correct URL is https://bugs.launchpad.net/chameleon-template-engine. Cheers, JW ___ 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] [issue157] Chameleon throws errors for translation strings that contain html elements with and without i18n:name attributes
Malthe Borch mbo...@gmail.com added the comment: Where is this branch? Can you paste a link to the revision diff when you've committed it (e.g. using http://repoze.org/viewcvs/chameleon). -- status: unread - chatting __ Repoze Bugs b...@bugs.repoze.org http://bugs.repoze.org/issue157 __ ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue157] Chameleon throws errors for translation strings that contain html elements with and without i18n:name attributes
Malthe Borch mbo...@gmail.com added the comment: It's because it doesn't really make much sense to not name your tags if you provide a translation string. However, there are already some examples of this in the tests. Maybe: 1) First look at the existing examples that demonstrate this. They've been comitted quite recently. 2) Make a new test that describes in slightly more detail what you want to happen, and in particular, what should happen when you pass in a language and when you don't, i.e. when a translation is available and when its not. __ Repoze Bugs b...@bugs.repoze.org http://bugs.repoze.org/issue157 __ ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue156] Chameleon - Bugs when using with apache
Malthe Borch mbo...@gmail.com added the comment: I'm not sure what this is, but it's not the first report I get about it. It's difficult to debug without some way of reproducing it consistently, although it seems to revolve around thread-safety. One thing about it though is that you seem to be compiling at run-time, repeatedly. That's not a good idea. Either use a template loader object, or define your template object on module- or class level. Can you try to see if this changes anything? -- status: unread - chatting __ Repoze Bugs b...@bugs.repoze.org http://bugs.repoze.org/issue156 __ ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.folder API weirdness
On 17 June 2010 16:08, Charlie Clark charlie.cl...@clark-consulting.eu wrote: This is standard behaviour for folders (the not accepting duplicates). I think changing it would be against user expectations. My file system accepts duplicates (meaning replacement). I don't need to remove the file first. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] problems running chameleon tests
Really that's odd; we can definitely add a [test] on next release; or please go ahead and commit it if you can. Thanks, On 3 June 2010 09:50, Chris Withers ch...@simplistix.co.uk wrote: Malthe Borch wrote: This has to do with lxml; it currently worksforme, but I don't know why. Try Stephan's static build and see if it fares any better, possibly using otool -L to confirm bindings. Actually, the tests only run if you have *all* the stuff in the test_require ;-) ...its' a shame there isn't a chameleon[test] to install when you want to run tests, python setup.py test appears to install all the tests dependencies for each test run :-( Chris -- Malthe Borch Technical Advisor UNICEF Uganda +256 (0) 703 945 965 ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] [chameleon bug] bugtracker url wrong in docs.
We should try and consolidate all these different bug trackers. It's a mess. Too bad we don't have the proper top-level name for this. I don't know that I agree with the name chameleon-template-engine. \malthe On 3 June 2010 00:49, Wichert Akkerman wich...@wiggy.net wrote: On 2010-6-2 23:48, Chris Withers wrote: First hit for me was: https://launchpad.net/chameleon.genshi Is that related? A fork? Something else? chameleon.genshi was merged into Chameleon 1.2.0. Wichert. -- Wichert Akkerman wich...@wiggy.net It 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 -- Malthe Borch Technical Advisor UNICEF Uganda +256 (0) 703 945 965 ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] problems running chameleon tests
On 3 June 2010 12:37, Chris Withers ch...@simplistix.co.uk wrote: How do you run the tests? python setup.py nosetests Hmm, it occurs to me that even if the [test] extra_requires was there, I don't know how to feed that into: python setup.py develop Any ideas? Not really right now; let me think it over. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] [chameleon bug] bugtracker url wrong in docs.
It wasn't. On 3 June 2010 13:05, Wichert Akkerman wich...@wiggy.net wrote: On 6/3/10 11:27 , Malthe Borch wrote: We should try and consolidate all these different bug trackers. It's a mess. Too bad we don't have the proper top-level name for this. I don't know that I agree with the name chameleon-template-engine. Hm, wasn't it you who created that tracker? Odd! Wichert. -- Malthe Borch Technical Advisor UNICEF Uganda +256 (0) 703 945 965 ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] Emacs bug!
try passing tab at pass: http://pastebin.com/qCMaym9S \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Emacs bug!
I guess it's documented here: https://bugs.launchpad.net/python-mode/+bug/328781. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] DOCTYPE inside macro
On 13 May 2010 19:23, Douglas Cerna douglasce...@yahoo.com wrote: I'm trying to set up a page macro that includes the !DOCTYPE ... in it, like this: That's not valid XML and since Chameleon currently uses Expat to parse documents (albeit very customized), it refuses to accept a doctype after a regular tag. As Shane mentions, the only good solution right now is to simply use the entire template as a macro; no definition needed! use:macro=some_template \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] LMS a BFG application
would do. A bit of encouragement, appreciation and recognition can boost our morale and can make us contribute better for Open Source Community.We are an NGO and develop software also. According to your own homepage, Mahiti Infotech is a large Indian IT company that specialise in a host of technologies including PHP and Drupal. As such you're very off-topic on this mailinglist asking for evaluation and recognition. Please try a more general mailinglist for advertising open-source software. You'll definitely receive much better feedback there. On the other hand, if you have concrete questions or inquiries about BFG or some of the other repoze technologies, this is the mailinglist to use. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Chameleon 1.1 and z3c.pt problems
On 9 April 2010 21:30, Hanno Schlichting ha...@hannosch.eu wrote: Sure. I think the approach we took was good. It gave as a hugely successful, stable and performant engine. I just have the feeling that the current model has become somewhat convoluted and hinders us to do any more optimizations. I certainly don't want to go anywhere near what Spitfire did with its four different optimization stages. There are things which are better left to JIT compilers like Unladen Swallow. True. RepeatNode \-- AssignNode \-- ConditionNode \ ContentNode That's what I tried to do, but failed because of poor approach. I think it's possible to redo this in a sane way, e.g. establish an AST not for Python code, but for template primitives such as the ones you suggest. I think part of the problem was scope creep; suddenly we had i18n in there along with metal and various other concepts. or something similar high-level. For the repeat variable case, I'd then want to take each RepeatNode and traverse it's inner nodes. If the repeat variable is accessed the RepeatNode would get a flag set and generate the corresponding code at a later stage. For this to work, you need to be able to ask each Node for the variables it's operating on. Really, what we need is something like: Scope -- RepeatNode ... Such that the code generator will take care of backing up scope variables, when necessary, e.g. when it's not temporary variables within the scope. Similar, the code generator should generate temporary variable names itself. Maybe you could also optimize the above tree to move the AssignNode outside the loop, if it isn't dependent on the loop variable of the RepeatNode. There's plenty other things you can do. I don't know which ones of these make sense to have and which ones are better left to Python itself. I'd say that all refactoring should be left to independent AST optimization logic, whether this be in the JIT-compiler, in CPython or tentatively in a Python library. ul tal:repeat=item items li tal:condition=view.useIcons() icon /li li tal:condition=not view.useIcons() text /li /ul One problem here is that you don't know that ``view.useIcons()`` is static. That said, I think we could have a flag ``treat_calls_as_static`` which would enable such optimizations. But isn't it symptom treatment? Shouldn't the language instead be better: li tal:condition=view.useIcons() icon /li li tal:condition=not previous text /li Maybe introducing node variables such as ``this``, ``next``, ``previous``, and ``parent`` would make sense. There's always the option of going inline: ``if view.useIcons():`` liicon/li ``else:`` litext/li I find that double backticks are much more readable than ! -- ! or other such combinations; and nobody uses them for prose. To group, either use a tag from the default namespace, or ``tal`` (or whatever): ``if some_condition:`` tal:group ... /tal:group Personally, I kind of feel that ``tal:content`` and ``tal:attributes`` and friends are awkward because they mix Python and attributes. On the contrary, I don't mind ``i18n`` because it's declarative. For ``metal``, it's even problematic to require tag usage because of oddballs like DOCTYPE. I'll have to think about that one; it's only ``use-macro`` that requires Python, the rest is declarative. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Using zope.contentprovider and zope.viewlet with repoze.bfg and chameleon
On 31 March 2010 22:41, Andrey Popp 8may...@gmail.com wrote: * Inject current view in template, because TALES expression for content providers make things work by adapting context, request, view (the last two already available inside template) to IContentProvider. That's an easy one: see z3c.pt; arguably, these View*-classes could make it to BFG (since it supports class-based views). * Make TALES expressions work with Chameleon, are there any difficulties? I think there is an issue with zope.contentprovider/configure.zcml — condition on zope.app.pagetemplate installation is set. Difficulty is that Chameleon doesn't keep variables in a dictionary per se (e.g. ``econtext``). Only some variables are kept there, namely those that need transferring between macros. What we've done instead is to reimplement certain TALES expresions including ``provider:`` and ``path:``. That's all available in z3c.pt. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Typo in Skins
On 15 March 2010 13:12, Douglas Cerna douglasce...@yahoo.com wrote: First of all, sorry for posting all these small typos on the dev mailing list. I'm starting with repoze.bfg and would like to contribute somehow. Is there a way of branching the docs, fixing the typos myself and send a diff to someone who can review and merge them? That would keep my noise low here :/ You can branch out if you get commit access; fill out contributor.pdf, gpg-sign it and send it in. Meanwhile, in http://packages.python.org/repoze.bfg.skins/ I guess: The index name now maps to the ./skins/images.pt file on disk: should be: The index name now maps to the ./skins/index.pt file on disk: correct? Yes, I have applied this fix to the repository. Thanks! \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] [issue139] Chameleon - can't create xml and doctype declarations from macro
On 4 March 2010 22:22, Shane Hathaway sh...@hathawaymix.org wrote: From a template developer's POV, it's useful to apply the same XML declarations throughout a site using metal. The current syntax is non-obvious and perhaps problematic, but workable. Some other syntax might be better, but let's not break the current syntax in the 1.1 branch. I have now implemented support for the following syntax: html metal:use-macro=main_template ... /html By passing a reference to the actual template instance, it will be used in its entirety, including any XML declarations. Please give the current trunk a spin if you have time, to ensure quality before a release. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] [issue139] Chameleon - can't create xml and doctype declarations from macro
On 4 March 2010 22:02, Kevin Kalupson b...@bugs.repoze.org wrote: I wouldn't expect the the xml headers in a macro template to be applied to the page template being rendered. It makes no sense to me that an element not contained within a macro definition would be applied to the page calling the macro under any situation. I sort of agree, except how else would we provide this functionality? Or is it actually the case that it doesn't make sense for a macro to control these headers –– I suspect it is. Plone's answer to this is to have its wrapper template manually write out the XML declaration or maybe just the DOCTYPE. That seems kind of crude as well. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] [issue139] Chameleon - can't create xml and doctype declarations from macro
On 4 March 2010 22:45, Kevin J. Kalupson z...@kevinkal.com wrote: In that case, there should be macro explicitly containing the doctype and other wanted headers. Yes, but that's unfortunately impossible. I don't think it's a syntax issue, I think it's a behavioral issue. I think the 1.1 branch exhibits broken behavior. But keep in mind that we're mimicking ``zope.pagetemplate``. Most people expect high corcordance. I just don't know about this. There's a work-around for you though: if you don't define the macro as the root node, then you won't get the doctype. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Chameleon 1.1 and z3c.pt problems
On 27 February 2010 12:10, Uli Fouquet u...@gnufix.de wrote: While trying to make megrok.chameleon compatible with zopetoolkit and groktoolkit package versions, I noticed that latest z3c.pt (1.1.0) and trunk are not completely compatible with Chameleon = 1.1.0. The tests fail. Do you think you can find time to try and reproduce this in straight Chameleon? I tried to fix it and it turned out, that compatibility problems result from different code generated by chameleon.core.codegen.Suite (while evaluating expressions in templates). Certain things changed in this release. while Chameleon 1.1.2 generates for the same input:: 'options/test' result = econtext['econtext']['_path']( econtext['econtext']['options'], econtext['econtext']['request'], True, 'test') Seems like the code that does the name transformation (codegen.py:visit_Name) should include ``econtext`` to the list of globally known symbols. This means that when executing the generated code, one has to make sure that the used locals are setup differently: econtext['econtext'] must exist to make the generated code work. You're right that this shouldn't be necessary. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Chameleon Genshi and match templates?
On 12 February 2010 21:03, Iain Duncan iainduncanli...@gmail.com wrote: Been out of the loop for a bit, did Chameleon Genshi get match template support yet? I know Malte mentioned it was a possibility about six months ago or so. Not yet, sadly. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Chameleon on GAE
On 4 February 2010 13:48, Tim Hoffman zutes...@gmail.com wrote: Do you mean it parses all templates on instance startup. If so that would be prohibitively expensive if you have a lot of templates. Yes. And startup time (just processing all the zcml, and all the other imports) is problematic as it is. (In the project just compeleted www.polytechnic.wa.edu.au, there is 131 template files. (page templates and metal macros). Our startup time You can use the CHAMELEON_CACHE=1 environment setting to cache these. for a cold instance without anything in memcache is between 4 and 8 secs. If appengine is having problems then that can blow out a very long way) It probably makes a lot of sense to memcache the templates, although memcache might decide to expunge the cached files since they won't be used much (only at startup). Do you have any idea how much it costs to parse a template first time round vs traditional zpt. Chameleon takes substantially longer than ZPT to parse and compile templates. I am going to have to have a bit of play, but parsing all templates on startup has me really worried. Memcache would alleviate that somewhat but any new instance would then still have to check to see if every template exists in memcache on startup and parse missing ones. However the main problem with a memcache strategy on google is such that anything can disappear from it at any time, which means if it's gone from memcache then you would have to parse on use of the template. Which sort of counters the whole approach. I wonder if the datastore could be used as a first line storage for the compiled templates. The they could be loaded and then cached in memcache, that way the cost would not be too high if the are not present as the loader could grab them from the datastore. I thought just that, too. This approach might be good. Can you try it out? Other than that, perhaps it's possible to fool memcached. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Problem with formencode, or chameleon.zpt ?
On 1 February 2010 18:47, georgehu geo...@gmail.com wrote: It worked without problem with other language such as de. Is it a problem of chameleon.zpt? Try and upgrade to 1.1.1, the post back. The normal process with bugs in Chameleon has been that a failing test is committed, then I'll usually get around to fixing it within a day or two at the most. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] I18n in BFG
On 29 January 2010 11:51, Hanno Schlichting ha...@hannosch.eu wrote: Ah right. Chameleon has a hard dependency on zope.i18n right now, I forgot. Not working with BFG nor Chameleon in any projects doesn't help to remember these things :) There's no hard dependencies in Chameleon at this time. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] [issue103] repoze.bitblt removes doctype
2010/1/27 Brian Sutherland b...@bugs.repoze.org: So in the next week or so, I will try re-implement regular expressions to find and replace the img tags. Given that malthe seems to think it's a reasonable idea I'll do it inside repoze.bitblt on a branch first. Please do it on trunk, and do it well. I've wanted this for a long time––and for squeeze, too. So, any ideas on how to robustly find img tags in HTML via regexes? Any example implementations? It's always robust since img is never a complex tag. Also, what kind of backwards compatibility does repoze.bitblt require? Should I replace the existing rewrite_image_tags or implement a new one alongside and implement some kind of configurability into ImageTransformationMiddleware? The primary interface is HTML, so I think we shouldn't worry much about the actual library code interface. I could be wrong on this assumption. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] Chameleon on GAE
Deep in the mountains of Austria, during a snow storm, Chameleon became compatible with Google App Engine. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Chameleon on GAE
2010/1/26 Tim Hoffman zutes...@gmail.com: So whats the secret , pre-compile everything ? Same procedure as last year, except we now use the compilation hoops from Genshi which makes it work, plus some rewrites of our code transformation logic. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Licensing of sourcecodegen and Chameleon
2010/1/12 Chris McDonough chr...@plope.com: But ethically this is Malthe's code, and the code itself has no license text in it. On chameleon.repoze.org he states Chameleon is covered by the BSD License. So I'll ask him to clarify which BSD license he means. BSD, as-is, dont-care. As for LICENSE.txt, I think it's more than enough to state the license by name; it's not difficult to find the full license text online and to my understanding, there are never any disputes. If I'm wrong, please anybody, commit necessary changes. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] python 2.5 support?
2009/12/15 Diez B. Roggisch diez.roggi...@ableton.com: I guess the question has been asked before, and I'm aware that the state of python 2.5 support is ultimately a zope-issue. Python 2.5 is supported since two years. We commonly use Python 2.6 though. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Error with ZPT
2009/12/10 george hu geo...@gmail.com: I have a submit button with value in Chinese string, some thing like: input type=submit name=form.submitted value=提交 / This has been fixed (now) in r7593. Please confirm on your end. Thanks, \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] new site based on repoze.bfg
2009/12/1 Martin Aspeli optilude+li...@gmail.com: Lest I offended anybody, I would like to insert an additional smiley at the end of that last sentence, like so: ;-) I think there was no offense, but it is only fair to mention that the British are very much at war right now, displaying a great ignorance on a daily basis. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Question about chameleon.zpt
2009/11/27 george hu geo...@gmail.com: I'm trying to use zpt to render a nested list and I found an example in the mail list of zope, Try this: http://pastie.org/722303 The problem you had was that the macro will be defined only after the tal:repeat operator; you need to split these up. In general, it's inadvisable to use METAL and TAL on the same element except ``tal:define``. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Question about chameleon.zpt
2009/11/27 george hu geo...@gmail.com: does any body know what is the problem here? I would suggest that you first use the ``CHAMELEON_CACHE=1`` and ``CHAMELEON_DEBUG=1`` environment flags to be able to inspect and step-debug through the template code. Ideally you would be able to step-debug directly in the template, but we're not quite there yet :) This is one way to do it: div tal:define=pdb import:pdb; dummy pdb.set_trace() ... /div \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Possible accept view-predicate enhancement?
2009/11/25 Alberto Valverde albe...@toscat.net: 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. This is partly the reason why some of these predicates seem a bit like meta-programming. Perhaps the ability to pass in a predicate function would have worked just as well. But it's a kind of toolbox –– with the inherent limitations of when the tools apply. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] mailing list split?
2009/11/23 Iain Duncan iaindun...@telus.net: Hey folks, just floating the idea of splitting the issue tracker mailouts on to their own mailing list? In my experience on this and other lists, it's a lot more pleasant to read the mailing list without having to scroll through the issue tracking comments. Just a thought. This would be great. The repository has grown to represent many different interests. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] object graph traversal question
2009/11/12 F. Oliver Gathmann gathm...@cenix-bioscience.com: 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?! You can use ``*subpath`` (or any other name of your choice) to retrieve this match as-is, without invoking the traverser. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.bitblt trims leading slash when transforming HTML
2009/11/4 Damien Baty damien.b...@gmail.com: For the record, this issue has been fixed today in r6960. Great! I wrote a few months ago (08/06/09): Sorry, I have that e-mail starred since June. I guess I can unstar it now :) \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] Package naming
Perhaps packages which provide middleware functionality should be named ``wsgi.*``, e.g. ``wsgi.bitblt`` or ``wsgi.who`` and we'd opt similar namespaces for packages that belong to other realms. I'm not sure this ``repoze.*`` notion is very healthy in terms of getting traction outside the Zope-community, although .what and .who have gained some popularity in spite of their nebulous namespace. What's the feeling on brand-like names such as ``WebOb``, or ``Routes``? That might be the right approach for more conceptual packages. At least that's my motivation for naming the new package ``Chameleon``. I think .who might fall in this category, not being just a library, but something more conceptual, e.g. ``Who``. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Package naming
2009/11/2 Martin Aspeli optilude+li...@gmail.com: 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. You think so? First of all, repoze != zope, and secondly, I'd rather hope people had grown out of discarding code based on a name or a namespace. With all the reach-out work Chris and others have done, I'd be surprised if the repoze.* name was turning people off. I think my worry with repoze.* is that it claims to want to be plumbing Zope into the WSGI Pipeline; that might be deprecated, but as it is, repoze as a project has some sort of direction, it's not just a group of contributors. Some of the software I've contributed under the repoze name is not very much related to this direction (e.g. repoze.formapi). Plone people (and me personally) prefer to own a namespace. What if someone else had the idea to call something Chameleon, which is not entirely unlikely? What about a more generic name? Must we always come up with a suitably quirky name when a more functional one would do? I agree to some extent; but certain pieces of software benefit from having a real name. Incidentally, I bloggedt about this stuff in the context of Plone yesterday: http://martinaspeli.net/articles/the-naming-of-things-package-names-and-namespaces/ Yes, I saw it; I'm not sure we're in alignment although I'm not sure we're not :) \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] Chameleon repackaging
I've repackaged ``chameleon.core`` and ``chameleon.zpt`` into one package, ``Chameleon``. Repository: http://svn.repoze.org/chameleon/trunk/ Note that this egg does not have a hard dependency on the ZCA libraries, or ``zope.i18n``. The first release has been given the version 1.0. During the next days, I will release new versions of the merged packages, which simply pull in the new egg. All module paths have been preserved 1:1. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Using ZPT Macros in repoze.bfg
2009/10/31 Michael Mulich mr...@psu.edu: I was using the get_template approach in my application to gain access to a macros templates prior to looking at repoze.bfg.skins. Using a view that returns a dictionary and a renderer that points to a page template (.pt file) that uses the skin expression defined in repoze.bfg.skins seems to solve some of what I think you're asking about. The new repoze.bfg.skins release (0.13) has a ``skin:`` expression translator which looks up a skin object using component lookup. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Predicates on routes vs views
2009/10/22 Chris McDonough chr...@plope.com: 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 routes. Is there anything in the way of letting them act upon ``route.match`` instead of ``view.predicate_checker``? \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] Predicates on routes vs views
Currently the predicates pertain only to views, regardless of whether they're declared using a route or a view directive (or using the ``bfg_view`` decorator). I would expect that if you declare a predicate on the route, that the route would only be used if that predicate matches. Instead, the route is used regardless, while the view which is declared on that same route is guarded with the predicate check. Does it make sense (and is it feasible in terms of backwards-compatibility concerns) to have the predicate be matched against the route, and if it does not match, go on to the next route? \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Predicates on routes vs views
2009/10/22 Tres Seaver tsea...@palladion.com: 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 view. With route, 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. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] Vaporware: repoze.esi
For essentially static content or other cacheable content, edge-side
includes are an attractive way to provide personalized o-wrap (e.g.
Hello, %{your_name}) on high-volume sites. This is a proposal for a
middleware which makes it easy.
The setup is a WSGI-application which returns cacheable HTML
responses. An HTML region which varies (vary) on some set of
variables will be marked up as follows:
span esi:vary=remote_user esi:id=pretty_usernameJohn/span
The middleware will replace this segment with an edge-side include
(here ``$url`` is the request url):
esi:include src=$url?esi=pretty_username /
The middleware will then mem-cache the HTML fragment for this particular user.
When an ESI-request (from the proxy-server) carries a header which
matches this vary value, the fragment is returned. If not, the
request is let through. It then mem-caches this and other ESI
fragments in the response, but returns only the requested fragment.
The middleware can even come equipped with a memcache-enabled ESI
implementation; it should not be difficult to implement this subset of
the ESI namespace (just the ``esi:include`` controller). This would be
useful in a development environment.
Upside:
Simple, flexible, transparent, true middleware.
Downside:
The subrequest (which is for a full HTML document) is likely more
expensive than returning just the HTML fragment using a dedicated
gateway.
Obviously, the middleware should only act on GET.
Comments appreciated.
\malthe
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] match templates in chameleon.genshi?
2009/10/3 Iain Duncan iaindun...@telus.net: Hey folks ( or rather Malte! ), wondering whether there are plans to include full match template support in chameleon.genshi? Is such a thing possible while still retaining speed? It is possible; I've previously outlined an idea for an implementation. It's not easy though as it would require us to implement XPath selection both in the compilation phase and in the rendering phase. To maintain speed, we'd need it to be quite clever. Are there other decent ways of doing template inheritance using chameleon.genshi that remove the need for it? There are macros and includes. Do you mean an OWrap-like mechanism? I am not sure actually (I'm a ZPT user). \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] chameleon.genshi with expressions inside non-XHTML attributes
Alberto Valverde wrote: Attached is a patch with a doctest showing the error. Applied and fixed in r5971. Thanks! \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] chameleon.genshi with expressions inside non-XHTML attributes
2009/7/11 Wichert Akkerman wich...@wiggy.net: This looks like a bug. Genshi syntax is pretty explicit about this having to work; it is an integral part of dynamic XIncludes for example. Definitely. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] how to extend basic User, Group, Permission model?
2009/6/25 Cezary Biele cezary.bi...@gmail.com: i'd be grateful for any suggestions how this should be achieved the right way using repoze. The default supplied security policy consults the ``__acl__`` attribute; you could make this attribute dynamic (descriptor) and grant permissions based on some owner attribute of the Gallery-object (in effect a local principal permission map). Alternatively, you can set up your own security policy which supports object ownership. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] bfg- Routes...
2009/6/25 Iain Duncan iaindun...@telus.net: For me personally (admittedly a totally new user to zope/repoze) it's a negative to have bfg moving to share fewer components with Pylons, as one of the main attractions to me of bfg is it's complementary nature to pylons. And conversely, one of the turn offs for me re Django as the rampant not-invented-here aspect. Perhaps what Chris is cooking up could be split up into a separate package; it seems to me that the motivation is that the Routes implementation could be improved upon, both in terms of performance and code quality. I could be wrong. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] how to extend basic User, Group, Permission model?
2009/6/25 Cezary Biele cezary.bi...@gmail.com: Thanks for your reply! could you please point me to some documentation? Try looking here: http://docs.repoze.org/bfg/narr/security.html#assigning-acls-to-your-model-objects \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] [Repoze-checkins] r5511 - chameleon.core/trunk/src/chameleon/core
2009/6/23 Hanno Schlichting ha...@hannosch.eu: What about tuples, lists, ... ? It's not in the specification I think; only strings and numbers (not even long or complex number). This looks like we want to check for builtin-type of some sort. The correct ways of checking here are all probably quite some performance hogs, though :( Well, actually; only strings need escaping. As it happens, I'm trying right now to see if the logic can be optimized further, but I don't seem able to. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Is it possible to integrate repoze.plone and Pylons in one WSGI application?
2009/6/18 Edwin Chu edwinche...@gmail.com: Is it possible to add repoze.plone to Pylons's WSGI pipeline so that they can be ran in the same process? I googled a while but nothing useful was found. This is fairly uncharted territory, but it should be possible in the case of Pylons (which doesn't interfere with any of Zope's globals, namely the component registry). Of course, one complication might be that you need to use Python 2.4 (until Plone 4 is out) and share all eggs between the two. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] BFG 0.9.1 / chameleon: render() takes exactly 1 non-keyword argument
2009/6/9 Chris Shenton ch...@shenton.org: I found it broke for me with .core at 1.0b33 and b34. Cache invalidation as fixed in 1.0b35. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.curry
2009/6/3 Chris Rossi ch...@archimedeanco.com: Just read over the repoze.curry docs--looks really cool! Thanks :-) 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. You may be right; ``const`` could be a better term. I'm not too much into the lingo of computer languages at large. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] Job vacancy
For those in the need of a getaway, there's an interesting opening in the unlikely place of Nairobi, Kenya: http://tinyurl.com/oaa8zu. It's zope 3 (are we allowed to say that?), wsgi, rdb and all that jazz. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] security changes...
2009/5/25 Chris McDonough chr...@plope.com: So to the end of breaking them apart, I just wrote up a bit of science fiction in code form. Could you take a look at the below and let me know what you think? It's very clear. In terms of style, for interfaces that represent would-be adapters, how do you feel about something like: def __init__(context): Adapter. ``context`` is ... Perhaps less ZCA-savvy users will find this style more informative in terms of what's really going on. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [chameleon] magic?
Atm there's a little known piece of AST magic in Chameleon (affecting all implementations): it makes attribute-access (__getattr__) fall back to dictionary acces (__getitem__). So that's magic; it was invented in the very early stages of the compiler and never really evaluated upon––I've later come to think it's a sick feature, because why should Python in templates behave differently than in code? As you can imagine, it's expensive, too, because all attribute lookups carry the cost of a function call. So unless there are big complaints, I suggest we just pull it out, before anyone notices. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] JavaScript Hash for Login
2009/5/12 Paul Johnston p...@pajhome.org.uk: I am going to have a go at adding a new authentication method to repoze.who. It's like the standard forms authentication, but uses JavaScript hashing to protect the password as it is transmitted. Excellent; there's been talking on this list previously about such a mechanism. I know many people are using my scripts, so I think this would be a good feature for repoze.who. I've not used repoze.who so far, so lets see how I get on. If anyone would like to lend a hand, just let me know. Is it correct to assume that if both the form where users originally provide their desired password and the login form both use your script, then nothing needs to be done on the server-side? \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] [Repoze-checkins] r4659 - repoze.zope2/trunk/repoze/zope2
2009/5/12 Tres Seaver tsea...@palladion.com: The server side wouldn't know that: the presence of such a field in the request is completely independent of any form (e.g., cookies passed long after logging in). I understand the issue, but shouldn't the remedy be to avoid ever displaying request data in a public view? \malthe ___ 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
2009/5/12 Chris McDonough chr...@plope.com: If we ever do release an 80%-compatible publisher replacement, we should call it something other than repoze.zope2. I doubt if we're really talking 80% though; if as Hanno suggests, it'll run CMF, Plone and what other popular Zope 2 apps/libraries, isn't it more like 95%? In that case, I think the name can remain the same. \malthe ___ 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
2009/5/12 Andrew Sawyers and...@sawdog.com: Just and FYI from a (large) consumer of the repoze.zope2 package This kind of change causes expensive test iterations. We're currently going through one now...as a result of choosing to move over to repoze.zope2 and friends. We would like to continue consuming this project work but to recommend another (expensive) test iteration to find out our app definitely runs on the next iteration would make us rethink our decision. You could peg your version and choose not to upgrade. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] Changes to Chameleon compilation system
As a general improvement (in terms of clarity) and as part of the efforts of getting Chameleon working on GAE, I've begun reworking the compilation stage. If not explicitly disabled (using ``CHAMELEON_CACHE=0``), template files (ending in .pt) will be compiled with the result written to a Python-module with the same filename (ending in .pt.py); Python will of course attempt to write a byte-code compilation (ending in .pt.pyc), which will guarantee good performance when restarting the system. Then, On template instantiation: 1) If the ``CHAMELEON_EAGER`` flag is enabled, parse template source immediately. 2) Load the template source module. 3) If the ``CHAMELEON_STATIC`` flag is enabled, compile into one-method-fits-all-arguments render methods for main template and each available macro (if required). On render: 4) If the ``CHAMELEON_STATIC`` flag is enabled, collapse keyword-arguments into dynamic context (econtext). On compilation: 5) If the render call signature (keyword arguments and macro name) matches an already compiled render-method, return it. Else: 6) Compile template (to source string). 7) Append to template source module. 8) Reload template source module and return render-method. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Changes to Chameleon compilation system
2009/5/9 Martin Aspeli optilude+li...@gmail.com: We can't go straight to .pyc? Won't GAE execute .pyc files? Who knows. By the way, can someone confirm if the GAE supports the ``execfile`` built-in? It doesn't seem to provide the ``imp`` module which we currently use to load and compile template source code. Also see the note about the _ast module earlier today. As far as I'm aware, the ``_ast`` module is the new Python 2.6 one which merely provides a much improved AST. It won't do compilation. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Changes to Chameleon compilation system
2009/5/9 Hanno Schlichting hanno...@hannosch.eu: Do we really need to be able to switch this mode via CHAMELEON_STATIC? I'd be tempted to make the static mode the default and not have it configurable. The whole compilation process is already quite complicated and I wouldn't want to increase this by adding more and more switches. True; it could be that it did this by default, and if the ``compiler`` module was available, then it would optimize by compiling at run-time. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze grok comparison
Previously Martin Aspeli wrote: You're sure about that? I find it easier to write a new grokker (whether for a decorator or a more generic class grokker that looks for a base class) than a new ZCML directive (and I've done plenty of both). Ideally a grokker and a ZCML directive handler would be the same. 2009/5/7 Wichert Akkerman wich...@wiggy.net: Approaching this from another point of view: debugging a grokker that does not behave as you expect is much harder than debugging a zcml statement or a python imperative statement. If they were the same, you'd be able to debug a grokker just as you would a ZCML-directive. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze grok comparison
2009/5/4 Hanno Schlichting hanno...@hannosch.eu: Our gut feeling told us to either stick with a very-much known beast like Zope 2.12 or go for repoze.bfg. Grok or the Zope Toolkit didn't strike us as particular interesting with any of its offerings. I do have a feeling that we might miss out some of the good features we'd might give up by going for a very minimal approach. But something that allowed us to compare our set of technical requirements against the various options would have been appreciated. I think of BFG as a microkernel; you can plug into it using WSGI and a few other interfaces. These are simple and so writing libraries for them is easy. Contrast this with Zope where libraries have to be written against an entire framework with a high level of abstraction. Contracts are easier with BFG and it makes development quick and, dare I say it, fun. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Separate 'compile' and 'execute' steps in Chameleon [was: Re: repoze.bfg trunk C-free]
2009/5/4 Carlos de la Guardia carlos.delaguar...@gmail.com: If Malthe or anyone else has a good idea about how to do this and will give me some pointers, I'm willing to use my limited abilities to make this work. Otherwise, I might try to bring in old zpt. It can be done, but it requires the introduction of a new compilation mode, which will essentially produce a source-file which will fit all; currently, the compiler produces one source-file per keyword-argument signature. That's obviously not something you can reasonably determine at compile-time. The way to go about this is probably to have the render-method do something like this: def render(**kwargs): kwargs['econtext'].update(kwargs) return render_template(econtext=kwargs['econtext']) Such that all variables will be pulled from the dynamic variable scope; this should work, but otoh, there's always some trickery with that 'econtext'. Chameleon has a mode of operation triggered by the CHAMELEON_EAGER flag; this basically parses all templates at initialization; I think we can hijack this mode to force the above-mentioned fallback compilation. The render-logic would then be something like this: 1) Do we have ``ast`` and ``compiler`` available? 2) If not, is a fallback source-file available? \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.bfg trunk C-free
2009/5/2 Chris McDonough chr...@plope.com: Tim Hoffman has been trying to get it going on GAE, and I think the trunk mostly works except for the chameleon.zpt bits (there are apparently no ast or compiler modules on GAE). Which is part of the reason why GAE is immature as a platform; it significantly decimates Python's capabilities as a dynamic language. I've played around with it previously, but I wasn't terribly impressed. The environment we have outside the GAE is currently much stronger. The GAE carries a promise of easy deployment and great scalability, but the price is high. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Genshi match templates without ``lxml``
2009/4/28 Paul Everitt p...@agendaless.com: I wonder, in light of our #repoze discussions about theming, what you think this would mean if the stuff below landed? I am not sure; maybe we need an account from someone actively using Genshi match-templates to enlighten us as to how useful the idea actually is. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.plugin documentation
2009/4/29 Chris McDonough chr...@plope.com: When you do need it, the multiplexing is awful handy (e.g. when trying to look up a view based on a context type and a request type). Except there's always this situation: View 1) for=IDocument IRequest View 2) for=Interface IPostRequest Let's say that you wanted always to do something special for POST requests. This won't work; you have to change (1) to for=IDocument IGetRequest I find that the ordering of multi-adaptation hinders me in using them in a clean way; perhaps the solution is to have some kind of priority token, e.g. for=Interface +IPostRequest You can argue that anything more than we have now is too complex; still, for multiplexing, the default adaptation ordering isn't always desirable. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.plugin documentation
2009/4/29 Chris McDonough chr...@plope.com:
That seems completely broken to me. It also doesn't match my (limited)
experience but I've never fought with it hard enough to know.
That should have read: adaptation is like an alphabet:
ABZ
ABC
ZBC
The real problem with doing the more clever thing is that it's just too hard
for any actual human to know what's going to happen. And the only real way
to fix that is to simplify the implementation, IMO. Indicators like + in
front of interface names makes me think of:
#div {
color: blue !important
}
.. and we all know how fun that is.
Hey, I... fine.
\malthe
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.plugin documentation
2009/4/28 Chris Rossi ch...@archimedeanco.com: ``zope.component.getAllUtilitiesFor`` does that. Might be called ``getAllUtilitiesRegisteredFor``, although there's another variant, too, ``getUtilitiesFor``. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] Genshi match templates without ``lxml``
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
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
Re: [Repoze-dev] bfg.repoze.org site needs testing/help
2009/4/20 Chris McDonough chr...@plope.com: Thanks to Carlos de la Guardia, repoze.bfg now has its own web presence at http://bfg.repoze.org . The site is basically just a way to browse and search BFG documentation and user-supplied content and to get an account so you can add Trac issues and tutorials. Another goal of the site is to disambiguate BFG from other repoze stuff. Excellent. Perhaps it could be source instead of software, since it's a trac-instance serving up that page. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
