> hmm, well to be clear, you're still using implicit acquisition if you say
> <span tal:content="here/foo"> ... </span>
> However, TAL is much better about using explicit namespaces
Yes, explicitly using implicit acquisition. I'll give you that.
> If Zope is your first exposure to Python, I'm not sure if you
> can appreciate what I mean. :-)
Possibly not. I've often been thown into the deep end of projects.
> reference manual? which one? The Zope Book? (a fair amount of python
> is in it these days.) ZOpe Developers' Guide? (lots of python there.)
I was referring to Guido's Python Reference Manual, which is less a
reference of python modules, rather a reference of how python itself was
written. No offence intended. There's lots of python in both Zope books,
and I refer to them regularly.
> - Write as much as possible of your product's features in a class
> that doesn't inherit from *any* zope-specific base classes.
I can take that advice. Seems reasonable enough, and makes the python more
reusable in any case.
I'm currently trying to write the interface to integrate a wholesaler XML
response into our database and finding myself falling between XML stools.
My notion was to convert it to a local XML format before importing that to
the database. I figured that this layer would insulate against change in a
similar manner to the above, but it seems that generating xslt
programmatically is not something that people are doing much yet.
Thanks for your time.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -