[Zope3-dev] Re: Better access to APIs in paths (was Re: needingviewsclues
- template/title troubles)
Shane Hathaway
shane@zope.com
Tue, 25 Feb 2003 14:48:36 -0500
Jeffrey P Shell wrote:
> I wonder if a Service would work here as well - a
> "DynamicContentSpaceStuffNamespaceService" that provided default
> namespaces that could be used for all template types within an area,
> with the ability to prefer to increasingly global services. The
> configuration options for this service would provide the default
> namespaces (with the chance to rename them) - context, container, and
> others that I hope stay around (modules), and the ability to
> add/register new ones like 'dc' for dublin core (which may also be
> configured by default). The Zope.app base page template code could add
> look for the service in pt_getContext (or wherever it would be better to
> go).
>
> Such a service could offer a chance to pre-bind a lot of commonly used
> template "globals" to speed up name resolution for applications/sites
> that need them, like the example shown below.
Well, what I have in mind is a little different.
Imagine for a moment that we had API namespaces in ZPT before CMF
started using ZPT. The first thing we'd do is make every tool
accessible through an API. Each template interested in using a certain
tool would declare a prefix for accessing that tool. Every template
might have declarations like this:
<div tal:namespaces="utool zope:cmf/portal_url;
mtool zope:cmf/portal_membership;
atool zope:cmf/portal_actions;
wtool zope:cmf/portal_workflow">
Most templates don't need all of those tools, so they would only declare
prefixes for the namespaces they need. (Conversion from prefix to
namespace happens when the template is compiled, so if the template uses
any non-default undeclared prefixes, the error is seen at compile time.)
Then someone would decide all those namespaces are cumbersome. "I don't
want to have to declare so many namespaces!" Well, there are two ways
to simplify. First we create a single aggregate namespace for all of
CMF. It makes the templates a little more fragile, but it's often worth
the price. Second, we register a default prefix for that namespace
within the CMF site. Now no declarations are needed at all, unless you
want to be more explicit and rely on a more specific interface.
Shane
> On Tuesday, February 25, 2003, at 10:32 AM, Shane Hathaway wrote:
>
>> John D. Heintz wrote:
>>
>>> I'm also sorry to hear you might be finished with this thread Shane.
>>> Your ideas parallel to XML namespaces is perfectly intuitive.
>>
>>
>> Thanks. As I return to work on page templates that lack API
>> declarations and use a lot of Python expressions, I long for
>> namespace-bound APIs. An example:
>>
>> <html metal:define-macro="master"
>> tal:define="utool nocall:here/portal_url;
>> mtool here/portal_membership;
>> atool here/portal_actions;
>> wtool here/portal_workflow;
>> portal_object utool/getPortalObject;
>> portal_title portal_object/Title;
>> object_title here/Title;
>> page_title page_title | template/title;
>> portal_url here/portal_url;
>> member mtool/getAuthenticatedMember;
>> isAnon mtool/isAnonymousUser;
>> actions python: atool.listFilteredActionsFor( here );
>> user_actions actions/user;
>> object_actions actions/object;
>> workflow_actions actions/workflow;
>> folder_actions actions/folder;
>> global_actions actions/global;
>> wf_state
>> python:wtool.getInfoFor(here,'review_state','');
>> ">
>>
>> This is quite brittle, but I can't fix it without breaking someone
>> else's derived templates. Namespace-bound APIs would give me a way to
>> fix this culture.
>>
>> Shane
>>
>>
>> _______________________________________________
>> Zope3-dev mailing list
>> Zope3-dev@zope.org
>> http://mail.zope.org/mailman/listinfo/zope3-dev
>