[Grok-dev] Neanderthal sprint topics
Martijn Faassen
Here is a summery of the proposed sprint topics, with some added by
myself as I think of them. I'd like all sprint attendees to think about
picking 2 topics:
* a smaller topic that they think they can get completed and checked in
by the end of day 1 or early day 2.
* a larger, possibly more risky/experimental topic that would take more
time for the rest of the sprint.
I'd like to get at least all topics listed here discussed with various
people at the sprint.
The idea is that we'll get more chance to actually get things finished.
Of course on monday we'll need to plan it out in more detail, as people
are intended to work in pairs, and some people are will only be there
for part of the sprint as well.
The sprint topics
-----------------
* The Grok website. Let's get a Plone skin going with Sebastian's
skin in there. Then let's start organizing content. (large topic,
but could be split into multiple smaller ones)
* Continue the work on making it easier to write (f)tests for
applications written *with* Grok. See also:
http://thread.gmane.org/gmane.comp.web.zope.grok.devel/1749
http://thread.gmane.org/gmane.comp.web.zope.grok.devel/1752
http://thread.gmane.org/gmane.comp.web.zope.grok.devel/1781
* Associating additional info to events (probably more of an Zope-3
issue initially). See also:
https://bugs.launchpad.net/zope3/+bug/98483
http://jw.n--tree.net/irclogs/%23grok/%23grok.2007-09-04.log.html
* Reference documentation. Publishing this online would be good.
* ZCML configuration actions for grok. Currently grok does CA
registrations immediately. We should change this so grok generates
zope.configuration actions so that it works better with ZCML.
* KSS for Grok. Godefroid will be there for at least the first half of
the sprint I heard, so I hope we'll get some KSS integration work
done. Having this would make me really excited, as there's all sorts
of cool things we can do with KSS. Besides integration code, I hope
this can also result in some form of tutorial.
* Viewlets in Grok. Some work was already done on this. Let's step back
and see how we can make this look natural with Grok.
* Theming hook for Grok. I know JW and Lennart need to talk on this.
* Improving the Admin UI. The Admin UI is now there and looking good.
Now that we start using it, there are a ton of ideas on how to improve
it, let's get some of them done.
* Supporting 'pinning versions' in Grok. We should make a good list of
versions of Grok dependencies, and publish a list on some URL that
buildout can then reuse. grokproject needs some adjustments too
to support this.
* Grok and WSGI. Philipp, who unfortunately won't be there, has done
quite a bit of work on Zope 3/Grok and WSGI. We could investigate this
work, experiment with some WSGI middleware, and devise a plan to
get this integrated into Grok.
* Grok release planning. It would be good to sit together and discuss
the planning of the next release(s).
* Security; make the Grok security "policy" optional/configurable.
Partially related to this:
http://thread.gmane.org/gmane.comp.web.zope.grok.devel/885
This could be looking into supporting model-level security. JW also
wants to consider the option to be able to switch from "views
are public by default" to "views are closed by default".
* Security and the catalog
An interesting security feature would be to port the catalog magic
that CMF does to the Zope 3 catalog, as discussed recently on this
list.
http://svn.zope.org/Products.CMFCore/trunk/Products/CMFCore/CatalogTool.py
* Review, extend and merge the REST branch I did.
Please add your sprint topics!
Regards,
Martijn
_______________________________________________
Grok-dev mailing list
Grok...@zope.org
http://mail.zope.org/mailman/listinfo/grok-dev
Leonardo Rochael Almeida
at z3c.formlib and seeing if it makes sense to base grok forms on
those.
Cheers, Leo
Martijn Faassen
On 9/28/07, Leonardo Rochael Almeida <leoro...@gmail.com> wrote:
> I won't be there, but I'd like to sugest a sprint topic regard looking
> at z3c.formlib and seeing if it makes sense to base grok forms on
> those.
Good point, I had forgotten about this. I looked into z3c.form for a
while last weekend. Unfortunately it didn't really handle the central
use case I was looking for (yet); it supports nested forms through
subforms, and while these are flexible it also seems to induce much
manual labor on the form author - too much for my particular use
cases.
There is no doubt however that z3c.form is in many ways an improvement
over what has gone before, so it would be very valuable to have some
pair see whether we can integrate it. It can't break backwards
compatibility though. :)
Kevin Smith
Possible sprint topic: Groklets
A Grok take on viewlets. I've been using some prototype code that
simplifies 'viewlet' registration for the
common-case by eliminating the need for a 'viewletmanager'.
In a nut shell...
class MyView(grok.View):
grok.context(App)
grok.name('index')
class MyGroklet(Groklet): # registers directly with the view
grok.context(MyView)
grok.name('center') # the 'provider' name
order = 10 # optional
def render(self):
return "<h2>groklet 1</h2>"
class MyGroklet2(Groklet):
grok.context(MyView) # associate with a specific view or shared
interface
grok.name('center')
order = 20
def render(self):
return "<h2>groklet 2</h2>"
The groklets are available using the 'groklet' tal namespace.
app_templates/myview.pt
<span tal:replace="structure view/groklet:center" />
output...
<h2>groklet 1</h2><h2>groklet2</h2>
Whereas with a traditional viewlet...
class MyView(grok.View):
grok.context(App)
grok.name('index')
class MyViewletManager(ViewletManager):
# unless customized, this is a dead chicken
grok.context(MyView)
grok.name('center')
class MyViewlet1(Viewlet):
grok.viewletmanager(MyViewletManager)
order =10
def render(self):
return "<h2>viewlet 1</h2>"
class MyViewlet2(Viewlet):
grok.viewletmanager(MyViewletManager)
order = 20
def render(self):
return "<h2>viewlet 2</h2>"
app_templates/myview.pt
<span tal:replace="structure view/provider:center" />
output...
<h2>viewlet 1</h2><h2>viewlet2</h2>
In this example it may not seem obvious, but when you have a 'left',
'center', 'right', 'header', 'footer' providers, the dead chickens pile
up quick, since in the common case the viewletmanager does nothing more
than associate the provider name.
Each groklet can act as a viewletmanager if indeed a custom manager is
needed.
If this is something the community is interested in persuing, I can
send along the relevant code, but won't have time to do anything proper
with it for a month or two.
Kevin
PS: +10000 for pinning versions (before I pull all of my hair out :) )
Martijn Faassen
On 9/28/07, Kevin Smith <ke...@mcweekly.com> wrote:
> Possible sprint topic: Groklets
>
> A Grok take on viewlets. I've been using some prototype code that
> simplifies 'viewlet' registration for the
> common-case by eliminating the need for a 'viewletmanager'.
[snip]
> If this is something the community is interested in persuing, I can
> send along the relevant code, but won't have time to do anything proper
> with it for a month or two.
By all means! Could you check this in somewhere in svn.zope.org?
Besides discussing this at the sprint (and then possibly working on
it), I'd like to get some opinions on the list by people more familiar
with viewlets than I am and who won't be at the sprint. Philipp?
Martin?
Leonardo Rochael Almeida
The usage pattern of Storm is very ligthweight (grokish you could
say), and it has a zodb TM already integrated.
I can think of two straigthforward integration aspects
* A folderish type that implements the containment API by putting and
fetching objects from Storm
* An AutoFields variant that scans a model class for Storm fields
instead of zope schema fields, or alternatively, a grok declaration
that sets Storm class attributes on a model based on the fields of a
zope schema.
In time, a class for Storm stored instances doesn't need any special
base classes or metaclasses. All it needs are class attributes from
Storm which declare that these attributes in the instance will be
stored in the relational DB and what their types are, so I think we
can freely use Grok model classes for them. Check the tutorial:
https://storm.canonical.com/Tutorial
The artifact of such a sprint might as well be merely documentation on
using Grok with Storm instead of actual Storm support in grok.
On 9/28/07, Martijn Faassen <faa...@startifact.com> wrote:
> Hi there,
>
> Here is a summery of the proposed sprint topics,
> [...]
> Please add your sprint topics!
Martijn Faassen
On 9/28/07, Leonardo Rochael Almeida <leoro...@gmail.com> wrote:
> Another sugestion: Integration with Storm:
>
> https://storm.canonical.com/
>
> The usage pattern of Storm is very ligthweight (grokish you could
> say), and it has a zodb TM already integrated.
I'm a bit dubious about this one. We already have SQLAlchemy
integrated into Zope 3 and various people experimented with Grok. I'd
like to continue with that for the time being.
Regards,
Martijn
Brandon Craig Rhodes
> Another sugestion: Integration with Storm:
> https://storm.canonical.com/
>
> ... I can think of two straigthforward integration aspects
>
> * A folderish type that implements the containment API by putting and
> fetching objects from Storm
You might start with the recipe at the bottom of:
http://grok.zope.org/minitutorials/transient-objects.html
where I investigated the same issue in preparation for hooking Grok to
SQLAlchemy (though I made the tutorial I wound up writing independent
of the back-end from which you are getting objects).
> * An AutoFields variant that scans a model class for Storm fields
> instead of zope schema fields, or alternatively, a grok declaration
> that sets Storm class attributes on a model based on the fields of a
> zope schema.
I am interested in the same thing between SQLAlchemy and Zope 3! But,
I am not sure that it would wind up sharing any code with a similar
product for Storm.
> In time, a class for Storm stored instances doesn't need any special
> base classes or metaclasses ... so I think we can freely use Grok
> model classes for them.
I have strenuously avoided using Grok model classes for objects that
aren't persistent in the ZODB, because if they aren't in the ZODB,
then I have a superstition that they should not inherit from
Persistent!
But no one more experienced has ever weighed in on whether I'm correct
in avoiding inheriting temporary objects from grok.Model. It sure
would be nice to have 'index' be their default view name again! And
having a traverse() method right on the object would be kind of nice
too, though I'm still puzzled on whether mixing traversal information
in with an object is a good idea.
> The artifact of such a sprint might as well be merely documentation
> on using Grok with Storm instead of actual Storm support in grok.
In my project that's using SQLAlchemy with Grok, the big question
turns out to be neither schemas (I can, for the moment, live with
re-writing each relation as a Zope schema, and I think there are even
advantages to doing so), nor navigation (since I can just mock up
Traversers for the moment while I work on the "Trails" that I proposed
recently).
The big issue, instead, is getting Zope to commit the open database
transaction when a request finishes being processed. Fortunately
there is for SQLAlchemy a product named "z3c.zalchemy" that did this
for me, so I did not have to write any code. Maybe your sprint could
focus first on producing a "z3c.zstorm" that does the same thing,
borrowing from the zalchemy code? I think that's more fundamental a
thing to get working than the other.
Good luck! I wish I were attending.
--
Brandon Craig Rhodes bra...@rhodesmill.org http://rhodesmill.org/brandon
Uli Fouquet
Am Freitag, den 28.09.2007, 17:06 +0200 schrieb Martijn Faassen:
> Here is a summery of the proposed sprint topics, with some added by
> myself as I think of them. I'd like all sprint attendees to think about
> picking 2 topics:
A good idea :-)
I really run into trouble, reducing the choice down to two topics. If I
had to make a preference list, I would first do the things, that really
could be done in short time:
(1) i18n-branch (half a day or less)
(2) grok.testing (one day)
(3) reference (long)
(4) build website (unknown time, depends on specific subtopics)
This is only a proposal. I am open to other assignments.
> The sprint topics
> -----------------
>
> * The Grok website. Let's get a Plone skin going with Sebastian's
> skin in there. Then let's start organizing content. (large topic,
> but could be split into multiple smaller ones)
I at least would like to help starting this really large topic.
> * Continue the work on making it easier to write (f)tests for
> applications written *with* Grok. See also:
Could be my 'small' topic.
> * Reference documentation. Publishing this online would be good.
If everybody helps (cover one or two directives/classes) the reference
could be nearly completed by the end of sprint.
As some may have noticed, I already built a reference in ReST format,
which makes use of the special roles and directives that come with the
'sphinx' package. sphinx extends the standard docutils roles and
directives remarkably and is used to build the new Python 2.6 ReST
documentation.
The build process, however, is terrible: you need esoteric packages,
Python 2.5 and must apply patches. Beside this ugliness no PDF output is
supported. One advantage of this complicated build process: once set up,
it's easy to rebuild things and the output is really lovely.
Because of the complicated build with 'sphinx', in the last days I
started an effort to build a docutils.writer/.reader, which produces
latex-output from ReST ('rst2manual'), suitable for use with mkhowto.
This is a quite complicated task and far from being finished. But it's
much easier to build the reference with it (well, once finished).
To sum it up: if we do reference documentation at the sprint, I would
like at least to present the ReST reference and maybe we could also make
some progress with the build process. Anyway, some discussion about
formats etc. would be highly appreciated from my side.
> * KSS for Grok. Godefroid will be there for at least the first half of
> the sprint I heard, so I hope we'll get some KSS integration work
> done. Having this would make me really excited, as there's all sorts
> of cool things we can do with KSS. Besides integration code, I hope
> this can also result in some form of tutorial.
Yeah! Would _love_ to have it for the admin-UI and other tasks.
Unfortunately I know nearly nothing about KSS. So, this is not my topic.
> * Improving the Admin UI. The Admin UI is now there and looking good.
> Now that we start using it, there are a ton of ideas on how to improve
> it, let's get some of them done.
Oh, my very own topic ;-) I can at least bring another ton of ideas to
the sprint and will collect ideas from everybody. Duration depends much
on the ideas.
> Please add your sprint topics!
* Review and merge the i18n branch I did.
This should be a half-a-day topic or less.
Kind regards,
--
Uli
Fernando Correa Neto
I won't be there too, but to me some things that I believe that
deserves attention would be:
* Pinning down eggs (definitely);
* Skinning/theming end of story;
* At least one sane way to have SQL going, though I love ZODB...but
the biz don't;
Although Zope3 has a story with SQLAlchemy, I will agree with
Leonardo here because I've seen storm before and this is way easier to
integrate IMHO;
* KSS would be very cool if people chooses it as Grok's Ajax framework;
* WSGI is another subject that deserves some attention because it
opens the Grok world to another apps and vice-versa;
* Forms. I don't know how bad zope.formlib is compared to z3c.form and
if this is time for a change. But having a look at it, this is too
much to build forms I think (considering subforms and wizards etc).
Having the RESTfull implementation would be cool as well.
I think that if at least 30% of the topics could be completed or even
started, would result in a very productive sprint.
Regards,
Fernando
Leonardo Rochael Almeida
> "Leonardo Rochael Almeida" <leoro...@gmail.com> writes:
>
> > Another sugestion: Integration with Storm:
> > https://storm.canonical.com/
> >
>
> In my project that's using SQLAlchemy with Grok, the big question
>
> The big issue, instead, is getting Zope to commit the open database
> transaction when a request finishes being processed. Fortunately
> there is for SQLAlchemy a product named "z3c.zalchemy" that did this
> for me, so I did not have to write any code. Maybe your sprint could
> focus first on producing a "z3c.zstorm" that does the same thing,
> borrowing from the zalchemy code? I think that's more fundamental a
> thing to get working than the other.
Fortunately, storm was developed from the get go with zope3
compatibility in mind, since most web products comming from Canonical
are based on zope3 technologies. Specifically, there is a "storm.zope"
package that, as I mentioned, implements the ZODB Transaction Manager
API for grok.
> Good luck! I wish I were attending.
Me too, actually :-)
Cheers, Leo
Wichert Akkerman
> "Leonardo Rochael Almeida" <leoro...@gmail.com> writes:
> > In time, a class for Storm stored instances doesn't need any special
> > base classes or metaclasses ... so I think we can freely use Grok
> > model classes for them.
>
> I have strenuously avoided using Grok model classes for objects that
> aren't persistent in the ZODB, because if they aren't in the ZODB,
> then I have a superstition that they should not inherit from
> Persistent!
You could use something else, but I don't see a real problem with using
grok.Model with SQLAlchemy. I'm doing that for a project and it's been
working very well.
Wichert.
--
Wichert Akkerman <wic...@wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
Philipp von Weitershausen
> Hi there,
>
> Here is a summery of the proposed sprint topics, with some added by
> myself as I think of them.
[snip]
I'm +1 on pretty much all topics. I wouldn't give any a particular
priority except the reference. I think we really need one.
> * KSS for Grok. Godefroid will be there for at least the first half of
> the sprint I heard, so I hope we'll get some KSS integration work
> done. Having this would make me really excited, as there's all sorts
> of cool things we can do with KSS. Besides integration code, I hope
> this can also result in some form of tutorial.
I created an experimental thing a while ago:
http://svn.zope.org/Sandbox/philikon/megrok.kiss/. When I tried it out
recently, it didn't work, but I'm sure it can be made to.
> * Theming hook for Grok. I know JW and Lennart need to talk on this.
By the way, I looked at integrating Genshi into Zope 3 the other day.
It's shockingly easy. Takes you about 3 lines of code. I wouldn't mind
ditching PageTemplates (at least as the preferred option) altogether
since Genshi
* has more appealing templating syntax (I think it's much faster)
* is much more push-oriented (rather than ZPT's orientation towards pull)
* has support for theming and pipelining.
I know this sounds a bit revolutionary, but a prototype would be cool.
> * Grok and WSGI. Philipp, who unfortunately won't be there, has done
> quite a bit of work on Zope 3/Grok and WSGI. We could investigate this
> work, experiment with some WSGI middleware, and devise a plan to
> get this integrated into Grok.
I have created a branch of grokproject already that uses zopeproject as
the underlying machinery (and therefore creates sandboxes that use
WSGI+Paste). This worked when I did it (haven't tried it since).
After some refactorings in zopeproject, it could even be made simpler
yet. In fact, I'm suggesting that they should be folded into one egg. A
Zope3-style zopeproject and a Grok-style zopeproject are very close in
many ways (which is good for both, I think). So let's make them just two
faces of the same thing. This should help Zope's overall entry story
anyway: you can always point people to this one tool.
If anyone would like to work on this, let me know and I'll give you some
additional pointers.
--
http://worldcookery.com -- Professional Zope documentation and training
Brandon Craig Rhodes
> I wouldn't mind ditching PageTemplates (at least as the preferred
> option) altogether since Genshi ...
+1
I had not looked at Genshi before. It looks like a wonderful
improvement! Could a View auto-detect which kind of template it had
been given so that Grok could continue to support old-time Zopers?
--
Brandon Craig Rhodes bra...@rhodesmill.org http://rhodesmill.org/brandon
Martin Aspeli
> By the way, I looked at integrating Genshi into Zope 3 the other day.
> It's shockingly easy. Takes you about 3 lines of code. I wouldn't mind
> ditching PageTemplates (at least as the preferred option) altogether
> since Genshi
>
> * has more appealing templating syntax (I think it's much faster)
>
> * is much more push-oriented (rather than ZPT's orientation towards pull)
>
> * has support for theming and pipelining.
>
> I know this sounds a bit revolutionary, but a prototype would be cool.
+1 for prototype. I've used Genshi, and it's very good.
That said, don't make using ZPTs too difficult, please, and make sure
that things still interoperate. I don't see why they wouldn't, but you
need to be able to re-use a viewlet that's ZPT based at the very least.
There would also be some impedance mis-match if e.g. you had components
that presented UI with macros and slots for you to plug into, but that's
really more of a problem for a pluggable system such as Plone than a
start-from-scratch Grok app.
Martin
--
Acquisition is a jealous mistress
Jan-Wijbrand Kolman
>> * Theming hook for Grok. I know JW and Lennart need to talk on this.
>
> By the way, I looked at integrating Genshi into Zope 3 the other day.
> It's shockingly easy. Takes you about 3 lines of code. I wouldn't mind
> ditching PageTemplates (at least as the preferred option) altogether
> since Genshi
>
> * has more appealing templating syntax (I think it's much faster)
>
> * is much more push-oriented (rather than ZPT's orientation towards pull)
>
> * has support for theming and pipelining.
>
> I know this sounds a bit revolutionary, but a prototype would be cool.
I'm all for provides more templating alternatives. But maybe I'm a bit
more conservative here, if I'd like to say:
* Providing Genshi as a templating option should not be just on the Grok
layer. If I understand you correctly, your prototype was indeed on a
Zope-3 level, and that's good! If we were to embrace Genshi (or whatever
other alternative templating system), we should (IMHO) make sure it is a
usable alternative for Zope-3 itself first too.
* I would not like the idea of having Genshi as the *default* templating
system when using Grok, as long as Zope-3 itself uses ZPT as the
default. Still, I fully agree that we should provide an easily
accessible way of choosing a templating system for your application
development.
Kind regards,
jw
Philipp von Weitershausen
>> I wouldn't mind ditching PageTemplates (at least as the preferred
>> option) altogether since Genshi ...
>
> +1
>
> I had not looked at Genshi before. It looks like a wonderful
> improvement! Could a View auto-detect which kind of template it had
> been given so that Grok could continue to support old-time Zopers?
I think that would be the idea.
--
http://worldcookery.com -- Professional Zope documentation and training
Lennart Regebro
Right. I finally finished the hook (for Zope3, Grok would need it's
publisher updated or overridden in a separate product, but that's
easy).
http://regebro.wordpress.com/2007/09/29/grok-sprint-report-on-theming/
http://svn.zope.org/z3c.themehook/
--
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64
Fernando Correa Neto
On 9/29/07, Philipp von Weitershausen <phi...@weitershausen.de> wrote:
> Brandon Craig Rhodes wrote:
> >> I wouldn't mind ditching PageTemplates (at least as the preferred
> >> option) altogether since Genshi ...
> >
> > +1
> >
> > I had not looked at Genshi before. It looks like a wonderful
> > improvement! Could a View auto-detect which kind of template it had
> > been given so that Grok could continue to support old-time Zopers?
>
> I think that would be the idea.
Would it be something like grok.Buffet view? Since buffet has
everything in place already, that would be very nice indeed.
Regards,
Fernando
Philipp von Weitershausen
> Hey!
>
> On 9/29/07, Philipp von Weitershausen <phi...@weitershausen.de> wrote:
>> Brandon Craig Rhodes wrote:
>>>> I wouldn't mind ditching PageTemplates (at least as the preferred
>>>> option) altogether since Genshi ...
>>> +1
>>>
>>> I had not looked at Genshi before. It looks like a wonderful
>>> improvement! Could a View auto-detect which kind of template it had
>>> been given so that Grok could continue to support old-time Zopers?
>> I think that would be the idea.
>
>
> Would it be something like grok.Buffet view? Since buffet has
> everything in place already, that would be very nice indeed.
Well, I think we should still call it grok.View. Grok code is
declarative, grok.Buffet doesn't mean anything.
But yeah, using Buffet would certainly sound sensible, if
zope.pagetemplates could be made one of the Buffet plugins.
--
http://worldcookery.com -- Professional Zope documentation and training
Martijn Faassen
[snip]
> I have strenuously avoided using Grok model classes for objects that
> aren't persistent in the ZODB, because if they aren't in the ZODB,
> then I have a superstition that they should not inherit from
> Persistent!
>
> But no one more experienced has ever weighed in on whether I'm correct
> in avoiding inheriting temporary objects from grok.Model. It sure
> would be nice to have 'index' be their default view name again! And
> having a traverse() method right on the object would be kind of nice
> too, though I'm still puzzled on whether mixing traversal information
> in with an object is a good idea.
It's fine to derive from a persistent object and simply never attach it
to the persistent "tree". It will be temporary and go away.
[snip]
> The big issue, instead, is getting Zope to commit the open database
> transaction when a request finishes being processed. Fortunately
> there is for SQLAlchemy a product named "z3c.zalchemy" that did this
> for me, so I did not have to write any code. Maybe your sprint could
> focus first on producing a "z3c.zstorm" that does the same thing,
> borrowing from the zalchemy code? I think that's more fundamental a
> thing to get working than the other.
I understood that this was already taken care of by the Storm
integration code?
Regards,
Martijn
Martijn Faassen
> Philipp von Weitershausen wrote:
>
>> By the way, I looked at integrating Genshi into Zope 3 the other day.
>> It's shockingly easy. Takes you about 3 lines of code. I wouldn't mind
>> ditching PageTemplates (at least as the preferred option) altogether
>> since Genshi
>>
>> * has more appealing templating syntax (I think it's much faster)
>>
>> * is much more push-oriented (rather than ZPT's orientation towards pull)
>>
>> * has support for theming and pipelining.
>>
>> I know this sounds a bit revolutionary, but a prototype would be cool.
>
> +1 for prototype. I've used Genshi, and it's very good.
>
> That said, don't make using ZPTs too difficult, please, and make sure
> that things still interoperate. I don't see why they wouldn't, but you
> need to be able to re-use a viewlet that's ZPT based at the very least.
> There would also be some impedance mis-match if e.g. you had components
> that presented UI with macros and slots for you to plug into, but that's
> really more of a problem for a pluggable system such as Plone than a
> start-from-scratch Grok app.
+1 too (as people already knew). I think the sprinters, if they pick
this topic, should concentrate on:
* testing basic use cases with Genshi (static content, equivalent of
macros, calling up zope 3 views on 'context', viewlets, etc, etc)
* Basic ZPT interoperability of some kind
Buffet is rather framework bound, so isn't straightforwardly reusable.
The proposed successor hasn't gotten off the ground yet. So while this
is definitely still interesting to me, let's see about getting Genshi
integrated first.
Some hints from Philipp (a branch?) would be interesting to see.
Regards,
Martijn
Martijn Faassen
[snip]
> * Providing Genshi as a templating option should not be just on the Grok
> layer. If I understand you correctly, your prototype was indeed on a
> Zope-3 level, and that's good! If we were to embrace Genshi (or whatever
> other alternative templating system), we should (IMHO) make sure it is a
> usable alternative for Zope-3 itself first too.
Actually there is really no Zope 3 layer for template integration to
speak of right now, so you'd have to invent one. You use pagetemplates
by importing from the zope.pagetemplate package and such. We'd use
Genshi by importing from the Genshi package.
It's quite possible of course eventually some small integration logic
will be written, in which case we should release this as a Zope 3
package preferably. It can't be our priority on the near term though, as
we don't really know what "Zope 3 integration of template languages" means.
And eventually some buffet successor will hopefully arise for template
language pluggability. Though I spoke to Jim about this in may and he
was very skeptical about such efforts, and he said: "just use the
package and use 'import'". While I disagree with his skepticism, he does
have a point: it's definitely the right way to get started. :)
> * I would not like the idea of having Genshi as the *default* templating
> system when using Grok, as long as Zope-3 itself uses ZPT as the
> default. Still, I fully agree that we should provide an easily
> accessible way of choosing a templating system for your application
> development.
The first question is what 'default' means in terms of Grok templating
languages.
If we support two template languages, X and Y, in Grok, which one is the
default? My idea is that they're recognized on a file extension basis,
so if you drop something with an extension for X into foo_templates,
it'll use template language X, and if you drop something in with an
extension for Y it'll use template language Y. So far there's no default.
I can see three meanings for a template language X being the default for
Grok:
* it's presented in our official documentations as the main template
language. So, the tutorial examples are all in template language X,
except where we give an example of how you can also use template language Y.
* Grok itself preferably uses it, for instance in the Admin UI
implementation. More generally, existing Grok code out there uses
template language X.
* It's the most solidly implemented template language. I.e. the least
buggy, it's clear it got the most banging on so actually works, unlike
template language Z, which is theoretically integrated but actually
crashes when you macroify the groklet with the adaptoids and then it
breaks, how horrible, has anyone be using this?
Regards,
Martijn
Martin Aspeli
> Buffet is rather framework bound, so isn't straightforwardly reusable.
> The proposed successor hasn't gotten off the ground yet. So while this
> is definitely still interesting to me, let's see about getting Genshi
> integrated first.
I certainly haven't tried *all* Python templating languages, but I did
look through a few since Pylons gives you a choice. Genshi was the only
one I thought could be better than ZPT for serious use. IMHO, of course. :)
Martin
--
Acquisition is a jealous mistress
_______________________________________________
Kevin Smith
Kevin Smith
Lennart Regebro
> By the way, I looked at integrating Genshi into Zope 3 the other day.
> It's shockingly easy. Takes you about 3 lines of code. I wouldn't mind
> ditching PageTemplates (at least as the preferred option) altogether
> since Genshi
We are going too look at integrating other templating languages today,
starting with Genshi. So... do you have any hints of how to do this?
--
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64
Philipp von Weitershausen
> On 9/28/07, Philipp von Weitershausen <phi...@weitershausen.de>
> wrote:
>> By the way, I looked at integrating Genshi into Zope 3 the other day.
>> It's shockingly easy. Takes you about 3 lines of code. I wouldn't
>> mind
>> ditching PageTemplates (at least as the preferred option) altogether
>> since Genshi
>
> We are going too look at integrating other templating languages today,
> starting with Genshi. So... do you have any hints of how to do this?
Not really. I just did a very simple hack to get Genshi working. I
don't know it well enough by far to suggest some good patterns. All I
know is that it should feel natural to Grok *and* Genshi developers.
Genshi uses the "push" model for templates (the view code pushes the
data that the template needs into the template, rather than ZPTs
fetching the data they need). I very much like "push". In Grok we
typically have "semi-push" where the view class prepares data as
attributes of self in update() and the the template accesses it as
view.foo. So Genshi templates need to at least get the 'view' object,
and the 'request' probably too. Perhaps 'context'. But really, I
think everything else should be "pushed" in from the view class.
Lennart Regebro
> Not really. I just did a very simple hack to get Genshi working. I
> don't know it well enough by far to suggest some good patterns. All I
> know is that it should feel natural to Grok *and* Genshi developers.
Not being a Genshi developer, I wouldn't know what is natural. :-)
> Genshi uses the "push" model for templates (the view code pushes the
> data that the template needs into the template, rather than ZPTs
> fetching the data they need). I very much like "push". In Grok we
> typically have "semi-push" where the view class prepares data as
> attributes of self in update() and the the template accesses it as
> view.foo. So Genshi templates need to at least get the 'view' object,
> and the 'request' probably too. Perhaps 'context'.
So far so good. :-) We probably need to make the push story slightly simpler.
But basically, it works now, except of course, you don't have any path
expressions, mening you can't find any other views an call them, and
that would be useful.
But that's probably for another day.
--
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64
Wichert Akkerman
> On 10/2/07, Philipp von Weitershausen <phi...@weitershausen.de> wrote:
> > Not really. I just did a very simple hack to get Genshi working. I
> > don't know it well enough by far to suggest some good patterns. All I
> > know is that it should feel natural to Grok *and* Genshi developers.
>
> Not being a Genshi developer, I wouldn't know what is natural. :-)
>
> > Genshi uses the "push" model for templates (the view code pushes the
> > data that the template needs into the template, rather than ZPTs
> > fetching the data they need). I very much like "push". In Grok we
> > typically have "semi-push" where the view class prepares data as
> > attributes of self in update() and the the template accesses it as
> > view.foo. So Genshi templates need to at least get the 'view' object,
> > and the 'request' probably too. Perhaps 'context'.
>
> So far so good. :-) We probably need to make the push story slightly simpler.
> But basically, it works now, except of course, you don't have any path
> expressions, mening you can't find any other views an call them, and
> that would be useful.
Is that necessary in a push model? If the template needs another view
your view can push that?
Wichert.
--
Wichert Akkerman <wic...@wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
Leonardo Rochael Almeida
> [... comments on genshi implementation ...]
> But basically, it works now, except of course, you don't have any path
> expressions, mening you can't find any other views an call them, and
> that would be useful.
This, for me, should be a method on the view instance, but in any
case, the push model of genshi also means, you shouldn't be doing a
lot of navigation. The view should munch everything for the template
and give it what it already needs. Templates should be as dumb as
possible.
Philipp von Weitershausen
> On 10/2/07, Philipp von Weitershausen <phi...@weitershausen.de>
> wrote:
>> Not really. I just did a very simple hack to get Genshi working. I
>> don't know it well enough by far to suggest some good patterns. All I
>> know is that it should feel natural to Grok *and* Genshi developers.
>
> Not being a Genshi developer, I wouldn't know what is natural. :-)
Great... Looks like we should obduct somebody from the other web
frameworks ;).
>> Genshi uses the "push" model for templates (the view code pushes the
>> data that the template needs into the template, rather than ZPTs
>> fetching the data they need). I very much like "push". In Grok we
>> typically have "semi-push" where the view class prepares data as
>> attributes of self in update() and the the template accesses it as
>> view.foo. So Genshi templates need to at least get the 'view' object,
>> and the 'request' probably too. Perhaps 'context'.
>
> So far so good. :-) We probably need to make the push story
> slightly simpler.
> But basically, it works now, except of course, you don't have any path
> expressions, mening you can't find any other views an call them, and
> that would be useful.
I don't think that's necessarily a bad thing. You're not really
supposed to do too many fancy things in templates anyway. And you'll
always have view.url() to compute URLs, so no need for
@@absolute_url. Then we only need to make resources work, possibly
also through a convenience method on the view or so. That should get
most of the stuff covered.
Lennart Regebro
> Is that necessary in a push model? If the template needs another view
> your view can push that?
True, but I think it's a rather common pattern, so it seems like a
simple way of doing this would be helpful. A traverse() method on the
view could be enough...?
--
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64
Martijn Faassen
> On 2 Oct 2007, at 17:41 , Lennart Regebro wrote:
>>> Genshi uses the "push" model for templates (the view code pushes the
>>> data that the template needs into the template, rather than ZPTs
>>> fetching the data they need). I very much like "push". In Grok we
>>> typically have "semi-push" where the view class prepares data as
>>> attributes of self in update() and the the template accesses it as
>>> view.foo. So Genshi templates need to at least get the 'view' object,
>>> and the 'request' probably too. Perhaps 'context'.
>>
>> So far so good. :-) We probably need to make the push story slightly
>> simpler.
>> But basically, it works now, except of course, you don't have any path
>> expressions, mening you can't find any other views an call them, and
>> that would be useful.
>
> I don't think that's necessarily a bad thing. You're not really supposed
> to do too many fancy things in templates anyway. And you'll always have
> view.url() to compute URLs, so no need for @@absolute_url. Then we only
> need to make resources work, possibly also through a convenience method
> on the view or so. That should get most of the stuff covered.
'static' doesn't work. That's a bad thing. :)
In general, I don't think we should make this difficult deliberately. We
should push in a helper function that allows you to easily do this.
On it being a push model, we push the context, request and view to the
template. :) Genshi doesn't really require anything. It might be nice to
also *in addition* push in other things easily, though of course we
already have the update() method to set things up on the view.
Regards,
Martijn
Philipp von Weitershausen
> On 10/2/07, Lennart Regebro <reg...@gmail.com> wrote:
>> [... comments on genshi implementation ...]
>> But basically, it works now, except of course, you don't have any path
>> expressions, mening you can't find any other views an call them, and
>> that would be useful.
>
> This, for me, should be a method on the view instance, but in any
> case, the push model of genshi also means, you shouldn't be doing a
> lot of navigation. The view should munch everything for the template
> and give it what it already needs. Templates should be as dumb as
> possible.
I agree with that general sentiment.
--
http://worldcookery.com -- Professional Zope documentation and training
Philipp von Weitershausen
> Philipp von Weitershausen wrote:
>> On 2 Oct 2007, at 17:41 , Lennart Regebro wrote:
> [snip]
>>>> Genshi uses the "push" model for templates (the view code pushes the
>>>> data that the template needs into the template, rather than ZPTs
>>>> fetching the data they need). I very much like "push". In Grok we
>>>> typically have "semi-push" where the view class prepares data as
>>>> attributes of self in update() and the the template accesses it as
>>>> view.foo. So Genshi templates need to at least get the 'view' object,
>>>> and the 'request' probably too. Perhaps 'context'.
>>>
>>> So far so good. :-) We probably need to make the push story slightly
>>> simpler.
>>> But basically, it works now, except of course, you don't have any path
>>> expressions, mening you can't find any other views an call them, and
>>> that would be useful.
>>
>> I don't think that's necessarily a bad thing. You're not really
>> supposed to do too many fancy things in templates anyway. And you'll
>> always have view.url() to compute URLs, so no need for @@absolute_url.
>> Then we only need to make resources work, possibly also through a
>> convenience method on the view or so. That should get most of the
>> stuff covered.
>
> 'static' doesn't work. That's a bad thing. :)
So, ok: context, request, view, static... That's what we should support :).
> In general, I don't think we should make this difficult deliberately.
Agreed. But, Grok also has had the tendency to push people in the right
direction. By *carefully* doing this (not *annyoingly* obviously) we
should be able to do this.
> We should push in a helper function that allows you to easily do this.
>
> On it being a push model, we push the context, request and view to the
> template. :)
Well, yeah. But you'd be surprised how many ZPT templates you see in
Zope (2) applications (such as Plone) that abuse the availability of
'context' and reach waaaaaay too much into content space. Admittedly
it's a combination of having 'context', acquisition and Python
expressions. But still. We should try to find a decent compromise.
> Genshi doesn't really require anything. It might be nice to
> also *in addition* push in other things easily, though of course we
> already have the update() method to set things up on the view.
Yup. I think we should focus on documenting the "semi-push" pattern by
setting stuff on the view object in update(). People will always figure
out that they can do much more in the template than they should actually
be able to. In fact, Genshi makes it a bit easier because it has no ugly
path expressions but actual Python expressions. It's actually also a
reason why I think Genshi is nicer (things like tuple unpacking,
iteration edge cases, etc. are ugly in ZPT).
ME GROK LIKE GENSHI.
--
http://worldcookery.com -- Professional Zope documentation and training
Tres Seaver
Hash: SHA1
Philipp von Weitershausen wrote:
> Martijn Faassen wrote:
>> On it being a push model, we push the context, request and view to the
>> template. :)
>
> Well, yeah. But you'd be surprised how many ZPT templates you see in
> Zope (2) applications (such as Plone) that abuse the availability of
> 'context' and reach waaaaaay too much into content space. Admittedly
> it's a combination of having 'context', acquisition and Python
> expressions. But still. We should try to find a decent compromise.
I would actually avoid a compromise: don't even *offer* context to new
views by default, especially ones coming from "push" land: even 'view'
and 'request' are probably a bad idea. Instead, make the view class
responsible for constructing an explicit namespace for the template.
Such an approach has a number of benefits:
- The template contains no "heaving lifting" / API-dependent logic
(because it can't get to the APIs at all).
- The contract of the view class becomes explicit and testable.
- The view renders faster, because no security checks need be done
*at all* in a push-model view (the class is implicitly trusted,
and the template only gets what the trustee gives it).
For an example of using this model under ZPT, see:
http://agendaless.com/Members/tseaver/software/pushpage/
Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 tse...@palladion.com
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHAsUA+gerLs4ltQ4RAsmaAKDcQR/UKVUlfa6/eiB1FvNBuLw1nwCdGK39
XiVagBP/c5+YZ1HSVze1yBY=
=BE9f
-----END PGP SIGNATURE-----
Tres Seaver
Hash: SHA1
Philipp von Weitershausen wrote:
> Martijn Faassen wrote:
>> On it being a push model, we push the context, request and view to the
>> template. :)
>
> Well, yeah. But you'd be surprised how many ZPT templates you see in
> Zope (2) applications (such as Plone) that abuse the availability of
> 'context' and reach waaaaaay too much into content space. Admittedly
> it's a combination of having 'context', acquisition and Python
> expressions. But still. We should try to find a decent compromise.
I would actually avoid a compromise: don't even *offer* context to new
http://agendaless.com/Members/tseaver/software/pushpage/
_______________________________________________
Wichert Akkerman
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Philipp von Weitershausen wrote:
>
> > Martijn Faassen wrote:
>
> >> On it being a push model, we push the context, request and view to the
> >> template. :)
> >
> > Well, yeah. But you'd be surprised how many ZPT templates you see in
> > Zope (2) applications (such as Plone) that abuse the availability of
> > 'context' and reach waaaaaay too much into content space. Admittedly
> > it's a combination of having 'context', acquisition and Python
> > expressions. But still. We should try to find a decent compromise.
>
> I would actually avoid a compromise: don't even *offer* context to new
> views by default, especially ones coming from "push" land: even 'view'
> and 'request' are probably a bad idea. Instead, make the view class
> responsible for constructing an explicit namespace for the template.
>
> Such an approach has a number of benefits:
>
> - The template contains no "heaving lifting" / API-dependent logic
> (because it can't get to the APIs at all).
>
> - The contract of the view class becomes explicit and testable.
>
> - The view renders faster, because no security checks need be done
> *at all* in a push-model view (the class is implicitly trusted,
> and the template only gets what the trustee gives it).
+1
Wichert.
--
Wichert Akkerman <wic...@wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
Brandon Craig Rhodes
> - The view renders faster, because no security checks need be done
> *at all* in a push-model view (the class is implicitly trusted, and
> the template only gets what the trustee gives it).
I probably misunderstand what's being discussed here, so let me
outline a quick example.
The "easy way" to do things, I suppose, is to access objects and
attributes from Genshi itself:
<li py:for="person in context.people">
<a href="view.url(person)">${person.name} (${person.address.street})</a>
</li>
It seems, instead, that you are advocating that this simple and
obvious code be broken into two steps: one piece that gathers data in
the view, then a template that uses only that data for rendering:
...
def update(self):
people = [ { 'name': person.name,
'street_address': person.address.street,
'url': self.url(person) }
for person in self.context.people ]
self.template_info = { 'people': people }
...
<li py:for="person in people">
<a href="person.url">${person.name} (${person.street_address})</a>
</li>
Now, if this is the only difference you are talking about, then I'm
completely puzzled as to where you see a difference in security -
unless you are planning on having templates written by someone you do
not trust! (Or perhaps submitted by users?)
Templates written according to the first example are much easier to
read, making it much easier to see and audit where information is
coming from than if there's a level of gratuitous indirection for the
reader to follow. Except where obfuscation is involved, I, at least,
always find briefer and simpler code easier to check.
Now, perhaps I am wrong, and you are thinking instead about the
"if-then" logic of who-can-see-what. For example, a student on our
campus who chooses to make their data "confidential" can not have
their name displayed except to campus personnel. Let's imagine an app
that displays a class, and ask: where should the security check go
that protects someone's name? One answer - a bad answer! - is "in the
view", and maybe this is the sort of thing you're objecting to:
<li py:for="person in people">
<a href="view.url(person)">
<py:choose>
<span py:when="not request.is_admin_user and person.confidential">
CONFIDENTIAL</span>
<span py:otherwise="">${py:person.name}</span>
</py:choose>
</a>
</li>
If this is indeed what you're objecting to, then I completely agree -
these sort of checks do not belong in templates! But, I'm going to go
a step farther, and also claim that they have no place in templates.
Doing the following is, I'll claim, just as bad:
def update(self):
def persondict(person):
d = { 'street_address': person.address.street,
'url': self.url(person) }
if not self.request.is_admin_user and person.confidential:
d['name'] = 'CONFIDENTIAL'
else:
d['name'] = person.name
return d
people = [ persondict(person) for person in self.people ]
self.template_info = { 'people': people }
Why is this just as bad? Because this exact same logic will then have
to be repeated ten, or twenty, or thirty times, in *every single view
that could possibly need to display a person's name*!
Security checks belong neither in the template nor in the view,
because then the question "Who can see Brandon's name" can only be
answered by an exhaustive examination of every single view template
and view class in the system, followed by auditing of the templates or
classes that mention "name" anywhere in them.
Instead, the most fundamental security checks need to lie between the
view and the model. Of course, there might be sensible restrictions
that one wants to add to views themselves ("only admins can see the
admin page", and so forth), but these are conveniences, and can never
take the place of real security itself, which always involves
protecting two sets of data:
- Pieces of information
- Actions or operations the user can invoke
and protecting them in such a way that they stay protected whether
they're mentioned in a view template, fetched from a view class, or
delivered when an object gets presented through an adapter.
--
Brandon Craig Rhodes bra...@rhodesmill.org http://rhodesmill.org/brandon
Martijn Faassen
I think in certain settings being very strict and explicit about what
enters your page templates ("push") makes sense. This way your template
can only reach information prepared by the programmers and the template
developer will never be confronted with weird errors coming from deep in
the system due to method calls and such (no ComponentLookupError). I
think this can make sense for larger, team-driven projects, especially
those which have the template developer role in a separate individual
than the model developers. In some cases (though not with Genshi in
particular) can see such a special 'push' step can increase performance
as the template language can be simpler.
For smaller projects, such as one person projects, this strict
separation can hinder, for reasons Brandon talks about.
So I want to separate the concerns:
* We want to make Genshi work with Grok. That is, all the use cases that
we can fulfill with ZPT can be fulfilled with Genshi templates as well.
* We want to explore push mechanisms. We want the ability to work with
Genshi in a setting where we strictly limit which objects get pushed
into the template.
Currently at the sprint we're interested in the first concern: just have
the raw ability to use Genshi with Grok and letting us do whatever we want.
We're also thinking about ways to adjust the way Grok views work so that
the controlled "push" scenario becomes implementable, but that's not our
primary goal right now. I think this is the right way to go about it, as
otherwise we'll get lost in the complexity of how to make this work
right away, before we know we can even create a link to a static image
with Genshi.
Regards,
Martijn
Sebastian Ware
explicitly to the template was to make it easy to access the same
view method (skipping the template) for ajax stuff.
Mvh Sebastian
3 okt 2007 kl. 18.49 skrev Martijn Faassen:
> Hey,
>
> I think in certain settings being very strict and explicit about
> what enters your page templates ("push") makes sense.
Tres Seaver
Hash: SHA1
Sebastian Ware wrote:
> In Turbo Gears, the main motivation of having to push all of the data
> explicitly to the template was to make it easy to access the same
> view method (skipping the template) for ajax stuff.
Testability (of the view) and maintainability (of the template( goes up
in push mode, too. What if the "compromise" is to add a base class
whose namespace generator pushes the traditional TAL bindings; people
who want to use those names from Genshi templates can then derive from
that class, while those who want "purer" push can use the base (whose
'namespace' method might just raise NotImplementedError).
Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 tse...@palladion.com
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHA9JB+gerLs4ltQ4RAoJjAJ9iBITGaWr407nAnsdaYDeQJhdEvgCg1i0+
sG4L3Z4isHdieFv0+2TNmkI=
=8mkx
-----END PGP SIGNATURE-----
Tres Seaver
Hash: SHA1
Sebastian Ware wrote:
> In Turbo Gears, the main motivation of having to push all of the data
> explicitly to the template was to make it easy to access the same
> view method (skipping the template) for ajax stuff.
Testability (of the view) and maintainability (of the template( goes up
in push mode, too. What if the "compromise" is to add a base class
whose namespace generator pushes the traditional TAL bindings; people
who want to use those names from Genshi templates can then derive from
that class, while those who want "purer" push can use the base (whose
'namespace' method might just raise NotImplementedError).
Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 tse...@palladion.com
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHA9JB+gerLs4ltQ4RAoJjAJ9iBITGaWr407nAnsdaYDeQJhdEvgCg1i0+
sG4L3Z4isHdieFv0+2TNmkI=
=8mkx
-----END PGP SIGNATURE-----
_______________________________________________
Lennart Regebro
> In Turbo Gears, the main motivation of having to push all of the data
> explicitly to the template was to make it easy to access the same
> view method (skipping the template) for ajax stuff.
I don't think we should force people who don't want to do Ajax stuff
to do much more work just to make it easier for Ajax stuff. :-) I vote
for keeping context by default. If you don't want it, you will be
allowed to override the code that puts it into the namespace. ;-)
--
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64
Brandon Craig Rhodes
> I think in certain settings being very strict and explicit about
> what enters your page templates ("push") makes sense. This way your
> template can only reach information prepared by the programmers and
> the template developer will never be confronted with weird errors
> coming from deep in the system...
Ah, that makes sense! We don't have separate template developers so
it was hard for me to think out how things could go wrong.
Tres Seaver <tse...@palladion.com> writes:
> Testability (of the view) and maintainability (of the template) goes
> up in push mode, too. What if the "compromise" is to add a base
> class whose namespace generator pushes the traditional TAL bindings;
> people who want to use those names from Genshi templates can then
> derive from that class, while those who want "purer" push can use
> the base (whose 'namespace' method might just raise
> NotImplementedError).
I assume you mean the base-of-the-base? :-)
+1
--
Brandon Craig Rhodes bra...@rhodesmill.org http://rhodesmill.org/brandon