From jprey at ads.ecp.fr  Sat May  1 03:45:41 2004
From: jprey at ads.ecp.fr (Jean-Philippe Rey)
Date: Sat May  1 03:45:54 2004
Subject: [ZPT] forcing a string to be a path
In-Reply-To: <20040501030722.GC16449@mail.my-balls.com>
References: <20040501030722.GC16449@mail.my-balls.com>
Message-ID: <409355A5.8000206@ads.ecp.fr>

Adam wrote:

> I am attempting to include different content based on a variable in the
> url, fish?content=trout.  In my template doing something like:
> 
> <span tal:replace="structure request/content">content goes here</span>
> 
> ends up replacing the tag with the string "trout" instead of the
> contents of the file named trout.  I thought I could work around this by
> forcing it to be interpreted as a path using path:request/content, but
> that didn't actually change anything.  Is there a way to include a file
> based on a variable like this?

This works

<span tal:replace="structure python:here.restrictedTraverse(request.content)">

This should also work

<span tal:replace="structure python:path('here/' + request.content)">

With the first solution you won't have an error if your content doesn't exist.

Depending on what you want, you may use 'container' instead of 'here' in 
the previous expressions.

-- 
Jean-Philippe Rey     Professeur informatique - ?cole Centrale Paris
jprey@ads.ecp.fr      92295 Ch?tenay-Malabry Cedex - France

From fernando at cmartins.demon.nl  Sat May  1 05:06:32 2004
From: fernando at cmartins.demon.nl (Fernando Martins)
Date: Sat May  1 05:20:44 2004
Subject: [ZPT] forcing a string to be a path
In-Reply-To: <20040501030722.GC16449@mail.my-balls.com>
Message-ID: <LPBBLICABBLMEDAGGKOFIEFCDGAA.fernando@cmartins.demon.nl>

Hi Adam,

> I am attempting to include different content based on a variable in the
> url, fish?content=trout.  In my template doing something like:
>
> <span tal:replace="structure request/content">content goes here</span>
>
> ends up replacing the tag with the string "trout" instead of the
> contents of the file named trout.

Which is correct and as expected. If I call your name, Adam, I'll get to see
your face but if I want your money in the bank I've to ask bank/adam :-). Of
course, if I want to reach a variety of people, I've to do bank/?person or
in your code sample:

<span tal:define="fish request/content" tal:replace="structure
here/?fish">content goes here</span>

See also http://zope.org/Wikis/DevSite/Projects/ZPT/VariablesInPaths

HTH,
Fernando


From andreas at andreas-jung.com  Sat May  1 01:17:30 2004
From: andreas at andreas-jung.com (Andreas Jung)
Date: Sat May  1 06:03:05 2004
Subject: [ZPT] concatenating strings in tal:attributes?
In-Reply-To: <20040430225053.GA15236@mail.my-balls.com>
References: <20040430225053.GA15236@mail.my-balls.com>
Message-ID: <D8A271C858339BFA2D7F1724@guest-092.desy.de>

use the python: or string: keyword -> ZPT Reference in the Zope  Book

.-aj

--On Freitag, 30. April 2004 18:50 Uhr -0400 Adam <genericplayer@uoxng.org> 
wrote:

> I would like to do something like this:
> <a href="URL" tal:attributes="href folders/absolute_url + '?content=' +
> docs/id">blah</a>
>
> The idea being that I would get a resulting url like
> "mysite/fish?content=trout" I can't seem to figure out what the correct
> way to do this would be though, and I don't see anything like this in any
> of the zpt docs.
>
> Adam
>
> _______________________________________________
> ZPT mailing list
> ZPT@zope.org
> http://mail.zope.org/mailman/listinfo/zpt





From genericplayer at uoxng.org  Mon May  3 15:45:31 2004
From: genericplayer at uoxng.org (Adam)
Date: Mon May  3 15:45:48 2004
Subject: [ZPT] page templates with unbalanced tags
Message-ID: <20040503194531.GA20767@mail.my-balls.com>

I am attempting to use page templates to make a site, and I have 3
elements that I want to include into all my pages.  The header, menu,
and footer.  The problem is header has an opening html and body tag,
which zope decides to close on me.  And I can't even use the footer,
which has the closing body and html tags because zope comlains about me
trying to close un-opened tags.  Is there some way to tell zope that a
file isn't "complete" on its own, its intended to be used as part of
something else, so it doesn't try to make sure its a valid page all on
its own?

Thanks
Adam

From ianb at colorstudy.com  Mon May  3 15:50:34 2004
From: ianb at colorstudy.com (Ian Bicking)
Date: Mon May  3 15:51:09 2004
Subject: [ZPT] page templates with unbalanced tags
In-Reply-To: <20040503194531.GA20767@mail.my-balls.com>
References: <20040503194531.GA20767@mail.my-balls.com>
Message-ID: <4096A28A.7060304@colorstudy.com>

Adam wrote:
> I am attempting to use page templates to make a site, and I have 3
> elements that I want to include into all my pages.  The header, menu,
> and footer.  The problem is header has an opening html and body tag,
> which zope decides to close on me.  And I can't even use the footer,
> which has the closing body and html tags because zope comlains about me
> trying to close un-opened tags.  Is there some way to tell zope that a
> file isn't "complete" on its own, its intended to be used as part of
> something else, so it doesn't try to make sure its a valid page all on
> its own?

This is where you have to use METAL templates, instead of including 
headers and footers.  It goes something like:

<html metal:define-macro="page">
header stuff...

<tal:block metal:define-slot="body">
this gets replaced...
</tal:block>

footer stuff
</html>



This way you give Zope a fully valid template.  But read up on METAL to 
learn all the details.

   Ian

From genericplayer at uoxng.org  Mon May  3 17:31:51 2004
From: genericplayer at uoxng.org (Adam)
Date: Mon May  3 17:32:00 2004
Subject: [ZPT] page templates with unbalanced tags
In-Reply-To: <4096A28A.7060304@colorstudy.com>
References: <20040503194531.GA20767@mail.my-balls.com>
	<4096A28A.7060304@colorstudy.com>
Message-ID: <20040503213151.GA27254@mail.my-balls.com>

On Mon, May 03, 2004 at 02:50:34PM -0500, Ian Bicking wrote:
> Adam wrote:
> >I am attempting to use page templates to make a site, and I have 3
> >elements that I want to include into all my pages.  The header, menu,
> >and footer.  The problem is header has an opening html and body tag,
> >which zope decides to close on me.  And I can't even use the footer,
> >which has the closing body and html tags because zope comlains about me
> >trying to close un-opened tags.  Is there some way to tell zope that a
> >file isn't "complete" on its own, its intended to be used as part of
> >something else, so it doesn't try to make sure its a valid page all on
> >its own?
> 
> This is where you have to use METAL templates, instead of including 
> headers and footers.  It goes something like:
> 
> <html metal:define-macro="page">
> header stuff...
> 
> <tal:block metal:define-slot="body">
> this gets replaced...
> </tal:block>
> 
> footer stuff
> </html>

Ok, this seems like what I need, except for one problem.  It looks like
I can only use metal in a tag that has an open and close tag.  The first
line in my header isn't the <html> tag, its my doctype declaration.  Can
you use metal on its own like you can with tal (<tal:blah blah>
</tal:blah>)?

Thanks
Adam

From ianb at colorstudy.com  Mon May  3 17:39:31 2004
From: ianb at colorstudy.com (Ian Bicking)
Date: Mon May  3 17:39:50 2004
Subject: [ZPT] page templates with unbalanced tags
In-Reply-To: <20040503213151.GA27254@mail.my-balls.com>
References: <20040503194531.GA20767@mail.my-balls.com>
	<4096A28A.7060304@colorstudy.com>
	<20040503213151.GA27254@mail.my-balls.com>
Message-ID: <4096BC13.3020106@colorstudy.com>

Adam wrote:
> Ok, this seems like what I need, except for one problem.  It looks like
> I can only use metal in a tag that has an open and close tag.  The first
> line in my header isn't the <html> tag, its my doctype declaration.  Can
> you use metal on its own like you can with tal (<tal:blah blah>
> </tal:blah>)?

You need to put the entire template in <tal:block> tags then.  Any tags 
that start with tal: will be removed from the final output, so your 
doctype will be end up as the first tag.

   Ian

From chris at simplistix.co.uk  Tue May  4 09:05:05 2004
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue May  4 09:05:16 2004
Subject: [ZPT] page templates with unbalanced tags
In-Reply-To: <20040503213151.GA27254@mail.my-balls.com>
References: <20040503194531.GA20767@mail.my-balls.com>	<4096A28A.7060304@colorstudy.com>
	<20040503213151.GA27254@mail.my-balls.com>
Message-ID: <40979501.9090006@simplistix.co.uk>

Adam wrote:
> line in my header isn't the <html> tag, its my doctype declaration.  Can
> you use metal on its own like you can with tal (<tal:blah blah>
> </tal:blah>)?

You can: <metal:blah define-macro> </metal:blah>, but most people just incldue 
their doctypes in each template...

Chris

-- 
Simplistix - Content Management, Zope & Python Consulting
            - http://www.simplistix.co.uk


From mbond at the-forgotten.org  Wed May  5 08:01:40 2004
From: mbond at the-forgotten.org (Michael Bond)
Date: Wed May  5 08:01:46 2004
Subject: [ZPT] zpt + python + variables
Message-ID: <F7DB3C29-9E8B-11D8-A601-000393D5B1BC@the-forgotten.org>


I have a zpt form, where I am generating some of the input fields on 
the fly in the zpt. Not only will the names of the field change, but 
the number of fields will change as well.

The action attribute points to a python script, however everything dies 
at this point because the python script needs an expected number of 
parameters and complains if it doesn't have exactly that.

What is the best way to handle a problem like this? Is there a way to 
ignore the parameter's list in the script definition and have the zpt 
send something else through to the script (perhaps a dict.)?

Mike.


From casey at zope.com  Wed May  5 10:19:54 2004
From: casey at zope.com (Casey Duncan)
Date: Wed May  5 10:18:37 2004
Subject: [ZPT] Re: zpt + python + variables
References: <F7DB3C29-9E8B-11D8-A601-000393D5B1BC@the-forgotten.org>
Message-ID: <20040505101954.3962aa58.casey@zope.com>

On Wed, 5 May 2004 08:01:40 -0400
Michael Bond <mbond@the-forgotten.org> wrote:

> 
> I have a zpt form, where I am generating some of the input fields on 
> the fly in the zpt. Not only will the names of the field change, but 
> the number of fields will change as well.
> 
> The action attribute points to a python script, however everything
> dies at this point because the python script needs an expected number
> of parameters and complains if it doesn't have exactly that.
> 
> What is the best way to handle a problem like this? Is there a way to 
> ignore the parameter's list in the script definition and have the zpt 
> send something else through to the script (perhaps a dict.)?

Yes, but you need to be more specific. What are the expected arguments
for the script?

It is possible have variable argument lists for scripts. Does the python
script specify the fields somehow? How is it being used exactly?

-Casey


From ianb at colorstudy.com  Wed May  5 11:50:18 2004
From: ianb at colorstudy.com (Ian Bicking)
Date: Wed May  5 11:50:47 2004
Subject: [ZPT] zpt + python + variables
In-Reply-To: <F7DB3C29-9E8B-11D8-A601-000393D5B1BC@the-forgotten.org>
References: <F7DB3C29-9E8B-11D8-A601-000393D5B1BC@the-forgotten.org>
Message-ID: <40990D3A.5060904@colorstudy.com>

Michael Bond wrote:
> 
> I have a zpt form, where I am generating some of the input fields on the 
> fly in the zpt. Not only will the names of the field change, but the 
> number of fields will change as well.
> 
> The action attribute points to a python script, however everything dies 
> at this point because the python script needs an expected number of 
> parameters and complains if it doesn't have exactly that.
> 
> What is the best way to handle a problem like this? Is there a way to 
> ignore the parameter's list in the script definition and have the zpt 
> send something else through to the script (perhaps a dict.)?

A Python script doesn't have to specify every named parameter.  If it 
receives extra parameters (through the form) it will ignore them.  Then 
you can get to the parameters through container.REQUEST.get(field_name), 
e.g., container.REQUEST.get('phone_1')

   Ian

From Antivirus at heraldnet.com  Fri May  7 18:38:24 2004
From: Antivirus at heraldnet.com (Antivirus@heraldnet.com)
Date: Fri May  7 18:38:28 2004
Subject: [ZPT] Symantec Mail Security detected an executable file in a
	message sent from your address. (SYM:37909242940700026728)
Message-ID: <cb6301c43484$020b29f0$1906b40a@heraldnet.com>

Subject of the message: Mail Delivery (failure mcdonald@heraldnet.com) [mx]
Recipient of the message: "mcdonald@heraldnet.com" <mcdonald@heraldnet.com>
If this is a legitimate file, add a 2 to the end of the file extension e.g. .zip2


From limi at plone.org  Mon May 10 22:25:04 2004
From: limi at plone.org (Alexander Limi)
Date: Mon May 10 22:50:49 2004
Subject: [ZPT] DOCTYPES in Page Templates
Message-ID: <opr7tcz2uovhba00@serafin.mshome.net>

Hi Evan & the ZPT mailing list,

I know this has been discussed in the past, but I haven't found anything  
conclusive on the mailing list about it, so I'll make it short:

Will ZPT (most likely METAL) get a mechanism for setting DOCTYPES on a  
master template?

Right now, the Plone main_template starts out like this:

<metal:page define-macro="master"><metal:doctype  
define-slot="doctype"><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0  
Transitional//EN"  
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"></metal:doctype>

(notice the total lack of spaces to conform with the spec, which states  
that the doctype has to be on the first line, without leading spaces)

This doesn't exactly work wonders for readability, but it's the only way  
to ensure that every template in Plone uses the XHTML doctype. It also  
makes the template look like a bogus page to any HTML editor.

Is any solution planned for this? The DOCTYPE is a pretty intrinsic part  
of any web page, and it would be nice if there was a way to do this in a  
cleaner way.

-- 
__________________________________________________________________

  Alexander Limi    ?     Chief Architect     ?    Plone Solutions

  Development ? Training ? Support ? http://www.plonesolutions.com
__________________________________________________________________

  Plone Co-Founder   ?   http://plone.org   ?   Connecting Content


From jamie at audible.transient.net  Tue May 11 03:33:28 2004
From: jamie at audible.transient.net (Jamie Heilman)
Date: Tue May 11 03:34:03 2004
Subject: [ZPT] DOCTYPES in Page Templates
In-Reply-To: <opr7tcz2uovhba00@serafin.mshome.net>
References: <opr7tcz2uovhba00@serafin.mshome.net>
Message-ID: <20040511073328.GC5667@audible.transient.net>

Alexander Limi wrote:
> (notice the total lack of spaces to conform with the spec, which states  
> that the doctype has to be on the first line, without leading spaces)

Which spec?  Please cite.  Given that you may include a XML declaration
in a valid document I'm inclined to say your assertion that doctype
has to be first is either bogus or out of date.
 
-- 
Jamie Heilman                     http://audible.transient.net/~jamie/

From dieter at handshake.de  Tue May 11 13:48:26 2004
From: dieter at handshake.de (Dieter Maurer)
Date: Tue May 11 14:20:04 2004
Subject: [ZPT] DOCTYPES in Page Templates
In-Reply-To: <opr7tcz2uovhba00@serafin.mshome.net>
References: <opr7tcz2uovhba00@serafin.mshome.net>
Message-ID: <16545.4586.260986.57304@gargle.gargle.HOWL>

Alexander Limi wrote at 2004-5-11 04:25 +0200:
> ...
><metal:page define-macro="master"><metal:doctype  
>define-slot="doctype"><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0  
>Transitional//EN"  
>"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"></metal:doctype>
>
>(notice the total lack of spaces to conform with the spec, which states  
>that the doctype has to be on the first line, without leading spaces)
>
>This doesn't exactly work wonders for readability,

You can get a bit more readability with:

<metal:page define-macro="master"
><metal:doctype ...
><!DOCTYPES ...>...

-- 
Dieter

From evan at 4-am.com  Tue May 11 14:26:48 2004
From: evan at 4-am.com (Evan Simpson)
Date: Tue May 11 14:30:01 2004
Subject: [ZPT] DOCTYPES in Page Templates
In-Reply-To: <opr7tcz2uovhba00@serafin.mshome.net>
References: <opr7tcz2uovhba00@serafin.mshome.net>
Message-ID: <40A11AE8.1080507@4-am.com>

Alexander Limi wrote:
> Will ZPT (most likely METAL) get a mechanism for setting DOCTYPES on a  
> master template?

I'd like to give it one, but doing so requires digging deeply into the 
guts of TAL, and I haven't had time to devote to intensive ZPT work in 
quite a while.

Sorry,

Evan @ 4-am


From lists at elvix.com  Tue May 11 14:38:02 2004
From: lists at elvix.com (Geir Bækholt · Plone Solutions)
Date: Tue May 11 14:30:31 2004
Subject: [ZPT] DOCTYPES in Page Templates
In-Reply-To: <20040511073328.GC5667@audible.transient.net>
References: <opr7tcz2uovhba00@serafin.mshome.net>
	<20040511073328.GC5667@audible.transient.net>
Message-ID: <1442741171.20040511203802@elvix.com>

On  Tue, 11 May 2004 00:33:28 -0700 GMT 
Jamie Heilman asked the ZPT mailinglist about the following:
  
> Alexander Limi wrote:
>> (notice the total lack of spaces to conform with the spec, which states
>> that the doctype has to be on the first line, without leading spaces)

> Which spec?  Please cite.  Given that you may include a XML declaration
> in a valid document I'm inclined to say your assertion that doctype
> has to be first is either bogus or out of date.

Correct, Jamie, it does not have to be on the first line according to
the spec.

according to w3c - XHTML1.0 , which is what Plone attempts to conform to,
"There must be a DOCTYPE declaration in the document prior to the root
element"

- But - Browser redering-engine implementations (Both IE and Moz IIRC)
that switch between "backwards-compatible quirks-mode"-rendering and
"try-to-match-the-css-spec-but-still-fail"-rendering based on the Doctype
will not notice it if it is not on the first line.

-- 
__________________________________________________________________

 Geir B?kholt    ?   Interaction Engineer    ?    Plone Solutions

 Development ? Training ? Support ? http://www.plonesolutions.com
__________________________________________________________________


From limi at plone.org  Tue May 11 14:56:30 2004
From: limi at plone.org (Alexander Limi)
Date: Tue May 11 14:55:05 2004
Subject: [ZPT] Re: DOCTYPES in Page Templates
References: <opr7tcz2uovhba00@serafin.mshome.net>
	<20040511073328.GC5667@audible.transient.net>
Message-ID: <opr7umwgemvhba00@serafin.mshome.net>

On Tue, 11 May 2004 00:33:28 -0700, Jamie Heilman  
<jamie@audible.transient.net> wrote:

> Alexander Limi wrote:
>> (notice the total lack of spaces to conform with the spec, which states
>> that the doctype has to be on the first line, without leading spaces)
>
> Which spec?  Please cite.  Given that you may include a XML declaration
> in a valid document I'm inclined to say your assertion that doctype
> has to be first is either bogus or out of date.

OK, sorry - spent too much time in the Real World lately. What I meant to  
say was that it won't actually *work* unless you put it on the very first  
line. The spec allows it, the browsers don't. :)

-- 
__________________________________________________________________

  Alexander Limi    ?     Chief Architect     ?    Plone Solutions

  Development ? Training ? Support ? http://www.plonesolutions.com
__________________________________________________________________

  Plone Co-Founder   ?   http://plone.org   ?   Connecting Content


From dorneles at x3ng.com.br  Tue May 11 17:09:11 2004
From: dorneles at x3ng.com.br (=?ISO-8859-1?Q?Dorneles_Trem=E9a?=)
Date: Tue May 11 17:06:24 2004
Subject: [ZPT] Re: DOCTYPES in Page Templates
In-Reply-To: <16545.4586.260986.57304@gargle.gargle.HOWL>
References: <opr7tcz2uovhba00@serafin.mshome.net>
	<16545.4586.260986.57304@gargle.gargle.HOWL>
Message-ID: <c7rf88$hgc$1@sea.gmane.org>

Hello,

> You can get a bit more readability with:
> 
> <metal:page define-macro="master"
>   <metal:doctype ...
>   <!DOCTYPES ...>...

sorry Dieter, but if you do that, the <!DOCTYPES ...> won't
appear at first line... :-(

ZPT really should preserve line breaks/white spaces...

Regards,

-- 

Dorneles Trem?a
Caxias do Sul - RS - Brasil
+55 54 9114 9312 - UIN: 2413568
X3ng Web Technology <http://www.x3ng.com.br>

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/IT d- s:->: a24 C+++ UBL++++$ P--- L++ E-- W+++
N++ o? K? w+ O M+ V-- PS+ PE- Y-- PGP++ t+ 5 X++ R+
tv+ b(++) DI+ D++ G+>+++ e++>++++ h---- r+++ y+++**
------END GEEK CODE BLOCK------


From dorneles at x3ng.com.br  Tue May 11 19:02:27 2004
From: dorneles at x3ng.com.br (=?ISO-8859-1?Q?Dorneles_Trem=E9a?=)
Date: Tue May 11 18:59:39 2004
Subject: [ZPT] Re: DOCTYPES in Page Templates
In-Reply-To: <c7rf88$hgc$1@sea.gmane.org>
References: <opr7tcz2uovhba00@serafin.mshome.net>	<16545.4586.260986.57304@gargle.gargle.HOWL>
	<c7rf88$hgc$1@sea.gmane.org>
Message-ID: <c7rlsl$su0$1@sea.gmane.org>

Ops...

> ZPT really should preserve line breaks/white spaces...
  ^^^
...read 'TAL'.

Regards,

-- 

Dorneles Trem?a
Caxias do Sul - RS - Brasil
+55 54 9114 9312 - UIN: 2413568
X3ng Web Technology <http://www.x3ng.com.br>

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/IT d- s:->: a24 C+++ UBL++++$ P--- L++ E-- W+++
N++ o? K? w+ O M+ V-- PS+ PE- Y-- PGP++ t+ 5 X++ R+
tv+ b(++) DI+ D++ G+>+++ e++>++++ h---- r+++ y+++**
------END GEEK CODE BLOCK------


From limi at plone.org  Wed May 12 12:12:00 2004
From: limi at plone.org (Alexander Limi)
Date: Wed May 12 12:10:31 2004
Subject: [ZPT] Re: Truncating strings
References: <16277.43873.424707.437729@grendel.zope.com>
	<E09F864C-04AF-11D8-AF55-000393C2D67E@colorstudy.com>
Message-ID: <opr7v9yan6vhba00@serafin.mshome.net>

On Wed, 22 Oct 2003 11:50:44 -0500, Ian Bicking <ianb@colorstudy.com>  
wrote:

> Still... so... long... to... type...
>
> I think ZPT is giving me RSI, with the Z SQL Methods kicking me when I'm  
> down.  (But I feel productive when I can type at full speed for minutes  
> on end, practically on autopilot)
>
> Huh... tal:block must be new though.  Good to know.  Saves a few stokes  
> off <div tal:omit-tag="">...

You can even do <tal:whatever />. So for some keystroke saving and much  
better clarity, you can to stuff like this:

<tal:caravans repeat="caravan here/getCaravans">
   ...
</tal:caravans>

This will make it much easier to nest repeats, and will allow you to see  
where things end, instead of the generic </div> or </span> everywhere.

Haven't-read-the-rest-of-the-discussion-ly yours,

-- 
__________________________________________________________________

  Alexander Limi    ?     Chief Architect     ?    Plone Solutions

  Development ? Training ? Support ? http://www.plonesolutions.com
__________________________________________________________________

  Plone Co-Founder   ?   http://plone.org   ?   Connecting Content


From dieter at handshake.de  Wed May 12 14:37:47 2004
From: dieter at handshake.de (Dieter Maurer)
Date: Wed May 12 16:57:40 2004
Subject: [ZPT] Re: DOCTYPES in Page Templates
In-Reply-To: <c7rf88$hgc$1@sea.gmane.org>
References: <opr7tcz2uovhba00@serafin.mshome.net>
	<16545.4586.260986.57304@gargle.gargle.HOWL>
	<c7rf88$hgc$1@sea.gmane.org>
Message-ID: <16546.28411.130465.515055@gargle.gargle.HOWL>

Dorneles Trem?a wrote at 2004-5-11 18:09 -0300:
>> You can get a bit more readability with:
>> 
>> <metal:page define-macro="master"
>>   <metal:doctype ...
>>   <!DOCTYPES ...>...
>
>sorry Dieter, but if you do that, the <!DOCTYPES ...> won't
>appear at first line... :-(

I tried and it did (i.e. "<!DOCTYPE" at the immediate start of the page)...

Maybe, your mail reader was too intelligent and
reformatted my code. The reformatting almost surely
added whitespace before the "<!DOCTYPE" and maybe (if it is
especially stupid) a line break.

-- 
Dieter

From dorneles at x3ng.com.br  Wed May 12 17:48:33 2004
From: dorneles at x3ng.com.br (=?ISO-8859-1?Q?Dorneles_Trem=E9a?=)
Date: Wed May 12 17:45:37 2004
Subject: [ZPT] Re: DOCTYPES in Page Templates
In-Reply-To: <16546.28411.130465.515055@gargle.gargle.HOWL>
References: <opr7tcz2uovhba00@serafin.mshome.net>	<16545.4586.260986.57304@gargle.gargle.HOWL>	<c7rf88$hgc$1@sea.gmane.org>
	<16546.28411.130465.515055@gargle.gargle.HOWL>
Message-ID: <c7u5tr$iic$1@sea.gmane.org>

Hi,

Dieter Maurer:
> Dorneles Trem?a:
> > Dieter Maurer:
> > > You can get a bit more readability with:
> > >
> > > <metal:page define-macro="master"
> > >   <metal:doctype ...
> > >   <!DOCTYPES ...>...
> >
> > sorry Dieter, but if you do that, the <!DOCTYPES ...> won't
> > appear at first line... :-(
> 
> I tried and it did (i.e. "<!DOCTYPE" at the immediate start of the page)...
> 
> Maybe, your mail reader was too intelligent and
> reformatted my code. The reformatting almost surely
> added whitespace before the "<!DOCTYPE" and maybe (if it is
> especially stupid) a line break.

bingo! It was a misformatting from Thunderbird (with Quote
Colors extension installed).

Thanks... and sorry for the noise.

Regards,

-- 

Dorneles Trem?a
Caxias do Sul - RS - Brasil
+55 54 9114 9312 - UIN: 2413568
X3ng Web Technology <http://www.x3ng.com.br>

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/IT d- s:->: a24 C+++ UBL++++$ P--- L++ E-- W+++
N++ o? K? w+ O M+ V-- PS+ PE- Y-- PGP++ t+ 5 X++ R+
tv+ b(++) DI+ D++ G+>+++ e++>++++ h---- r+++ y+++**
------END GEEK CODE BLOCK------


From rjqxwqsz at com.ne.kr  Fri May 14 03:46:42 2004
From: rjqxwqsz at com.ne.kr (Megan Mackey)
Date: Fri May 14 04:17:07 2004
Subject: [ZPT] 6/ Here's the easy money
Message-ID: <EVQSVUYZYUBLTLDKURVZFDHJ@osk2.3web.ne.jp>

An HTML attachment was scrubbed...
URL: http://mail.zope.org/pipermail/zpt/attachments/20040514/4539506b/attachment.html
From jim at zope.com  Wed May 19 16:00:43 2004
From: jim at zope.com (Jim Fulton)
Date: Wed May 19 16:00:55 2004
Subject: [ZPT] RFC: TALES adapters and TAL/Tales variable namespaces
Message-ID: <40ABBCEB.9010801@zope.com>

I've posted two proposals:

   http://dev.zope.org/Zope3/TALESPathExpressionAdapters

Proposes a mechanism for easily using adapters in TALES expressions.

   http://dev.zope.org/Zope3/ZPTVariableNamespaces

proposes a mechanism for qualifying names defined in TAL and used in
TALES expressions.

Comments are welcome, here or in the pages.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From pw_lists at slinkp.com  Wed May 19 16:49:41 2004
From: pw_lists at slinkp.com (Paul Winkler)
Date: Wed May 19 16:49:54 2004
Subject: [ZPT] Re: [Zope-dev] RFC: TALES adapters and TAL/Tales variable
	namespaces
In-Reply-To: <40ABBCEB.9010801@zope.com>
References: <40ABBCEB.9010801@zope.com>
Message-ID: <20040519204941.GE6189@slinkp.com>

On Wed, May 19, 2004 at 04:00:43PM -0400, Jim Fulton wrote:
> I've posted two proposals:
> 
>   http://dev.zope.org/Zope3/TALESPathExpressionAdapters
> 
> Proposes a mechanism for easily using adapters in TALES expressions.

Quick comment from over here in non-genius-land...

-1 on the object*adapter notation.
My brain is hardwired to see that as "object times adapter" 
and I just can't make sense of that ;-)

+1 on the (adapter)object notation.
It's a pretty good mnemonic, adapting is sorta like casting.

The namespaces proposal looks fine to me, given that
one believes it is necessary. Never occurred to me before :-)

-- 

Paul Winkler
http://www.slinkp.com

From jim at zope.com  Wed May 19 17:01:57 2004
From: jim at zope.com (Jim Fulton)
Date: Wed May 19 17:02:09 2004
Subject: [ZPT] Re: [Zope3-dev] Re: RFC: TALES adapters and TAL/Tales
	variable	namespaces
In-Reply-To: <20040519163906.4274440d.casey@zope.com>
References: <40ABBCEB.9010801@zope.com>
	<20040519163906.4274440d.casey@zope.com>
Message-ID: <40ABCB45.2070509@zope.com>

Casey Duncan wrote:
> On Wed, 19 May 2004 16:00:43 -0400
> Jim Fulton <jim@zope.com> wrote:
> 
> 
>>I've posted two proposals:
>>
>>   http://dev.zope.org/Zope3/TALESPathExpressionAdapters
> 
> 
> I have to say I am not found of "*",

I'm not attached to '*'.  Feel free to suggest alternatives
(other than ':', '/', '|', or '?'. Is that all ;)

 > but using the parenthesis to "cast"
> the variable seems fairly natural and isn't colored by completelt
> different meaning in other languages.
> 
> So the example:
>   tal:content="x/y*foo.bar.baz/z"
> 
> would be:
>   tal:content="x/(foo.bar.baz)y/z"

Yup

> Which seems reasonable. The dotted notation seems ok, but it implies
> that this notation is recognized in general in path expressions which is
> confusing because it isn't. If we didn't use dots then it might look
> like:
>   tal:content="x/(modules/foo/bar/baz)y/z"

I'm not sure what you mean here. If the thing in the parens was a
path expression, it would be:

   x/(modules/foo.bar/baz)y/z

IOW, modules excepts dotted names.

> If the thing in the parenthesis is just another path expression, that
> mitigates the need for namespaces IMO. The above could then become:
>   tal:define="baz modules/foo/bar/baz"
>   tal:content="x/(baz)y/z"

True, but then, the obvious syntax would be:

   x/baz(y)/z

which is the top of a slippery slope. :)

It would also make it harder to provide predefined adapter names.

We'd like to be able to define some adapters (e.g. 'zope', 'format', etc.)
in ZCML and let people just use them in ZPT without having to use defines.


Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From casey at zope.com  Wed May 19 17:35:02 2004
From: casey at zope.com (Casey Duncan)
Date: Wed May 19 17:34:01 2004
Subject: [ZPT] Re: [Zope3-dev] Re: RFC: TALES adapters and TAL/Tales variable
 namespaces
In-Reply-To: <40ABCB45.2070509@zope.com>
References: <40ABBCEB.9010801@zope.com>
	<20040519163906.4274440d.casey@zope.com>
	<40ABCB45.2070509@zope.com>
Message-ID: <20040519173502.744a2b99.casey@zope.com>

On Wed, 19 May 2004 17:01:57 -0400
Jim Fulton <jim@zope.com> wrote:

> Casey Duncan wrote:
[..]
> > Which seems reasonable. The dotted notation seems ok, but it implies
> > that this notation is recognized in general in path expressions
> > which is confusing because it isn't. If we didn't use dots then it
> > might look like:
> >   tal:content="x/(modules/foo/bar/baz)y/z"
> 
> I'm not sure what you mean here. If the thing in the parens was a
> path expression, it would be:
> 
>    x/(modules/foo.bar/baz)y/z
> 
> IOW, modules excepts dotted names.

It does already you mean? I did not know that. Seems a bit weird, but I
can see why. Not sure I could explain it to a ZPT newbie without making
their head cave in though...
 
> > If the thing in the parenthesis is just another path expression,
> > that mitigates the need for namespaces IMO. The above could then
> > become:
> >   tal:define="baz modules/foo/bar/baz"
> >   tal:content="x/(baz)y/z"
> 
> True, but then, the obvious syntax would be:
> 
>    x/baz(y)/z
> 
> which is the top of a slippery slope. :)

Tempting but no way ;^). I still think "(baz)y" is pretty good. "baz(y)"
is a big ole can o' knarly worms.
 
> It would also make it harder to provide predefined adapter names.
> 
> We'd like to be able to define some adapters (e.g. 'zope', 'format',
> etc.) in ZCML and let people just use them in ZPT without having to
> use defines.

Ok, I see better the reasoning. Why not just have a new top-level name
like "adapters" or "adapt" so that we can avoid new language constructs?
That might also make it easier to read and only a bit more verbose. So
adapters would be a mapping of registered name=>adapter object. So the
above could be:
  
  tal:content="x/(adapters/baz)y/z"

That puts the adapters all in one big bag, but honestly I think it is
manageable. If desired, the adapters could be categorized through
traversal:

  tal:content="x/(adapters/zope/frobnob)y/z"

This seems nice and explicit to me. I don't mind typing the word
"adapters" and it's clear that it is one even if I'm not familiar with
the casting syntax. If I used it alot in one template I could just do:

  tal:define="frobnob adapters/zope/frobnob"

-Casey

From ianb at colorstudy.com  Wed May 19 17:33:29 2004
From: ianb at colorstudy.com (Ian Bicking)
Date: Wed May 19 17:34:12 2004
Subject: [ZPT] RFC: TALES adapters and TAL/Tales variable namespaces
In-Reply-To: <40ABBCEB.9010801@zope.com>
References: <40ABBCEB.9010801@zope.com>
Message-ID: <40ABD2A9.9000708@colorstudy.com>

Jim Fulton wrote:
> I've posted two proposals:
> 
>   http://dev.zope.org/Zope3/TALESPathExpressionAdapters

Not much opinion.  Though I fear that "(adapter)object" could lead to 
this syntax in Python itself, which would be horrid ;)  I agree that 
adapter(object) is a bad direction.  object*adapter looks fine to me, 
and it seems reasonable that only a specific set of adapters would be 
available in TAL expressions (i.e., adapters which provide ITALESAdapter).

> Proposes a mechanism for easily using adapters in TALES expressions.
> 
>   http://dev.zope.org/Zope3/ZPTVariableNamespaces
> 
> proposes a mechanism for qualifying names defined in TAL and used in
> TALES expressions.

I'm suspicious of namespaces, as they seem redundant.  Namespaces in 
Python, after all, are expressed like any other attribute traversal 
(e.g., os.path.exists).  The analog in TAL would be adapter/foo.  This 
is how TAL works right now in practice, with a small number of 
namespaces like request, container, etc.

I see a few problems with the current situation:

1. There's no clear way to indicate that you want to use a name as a 
namespace, as opposed to a normal name.  So there may be a conflict 
between the "adapter" you want to use as a namespace, and a template 
that someone writes that happens to use the variable adapter in an 
unrelated way.  This is fine now, because there is a fairly fixed number 
of namespaces (six or seven, I think), and you just don't use those 
names -- as namespaces are added (especially on a per-metal-template 
basis) this conflict is more likely, and you may not know what names 
will cause conflicts in the future.

But I'm not sure how bad the name conflict really is.  In my experience 
it's not too bad in Python code, and when it's a problem it's fairly 
easily resolved.  Or maybe another one or two namespaces can be added 
which would sufficient, and we don't need to extend the number of 
namespaces indefinitely.  Like an adapter namespace and a metal 
namespace (maybe you'd use things like 
metal/name_of_template.pt/variable_name).  To some degree this could 
even be convention, instead of building it in explicitly.

2. Another issue might be the difficulty of creating a namespace for use 
with templates -- with the proposal all namespaces start out empty and 
ready to accept new values, but if you use normal variables they start 
out as undefined, and you'd have to assign them to {} or something.

(A little thought: if you had "def namespace(): return {}", then 
tal:define="adapter namespace" would work and reads fairly well)

3. Explicit namespaces support deeper, structured assignment (but only a 
*little* deeper).  Does TAL currently allow tal:define="var/attr 
something"?  I've never tried it.  It should.  Maybe the specific 
semantics of this assignment could be refined to resolve (2) -- e.g., if 
you get a LookupError during the second-to-last segment of the 
traversal, try to assign it to {}.

Anyway, whenever I look at a language with explicit namespaces (e.g., 
Ruby), it seems really pointless.  I think they should be avoided, and 
that normal TAL path expressions can be refined instead.

It's also annoying that we'd have namespace['adapter'] in Python 
expressions.  Namespaces might be a way to introduce a more accessible 
set of typical functions, like DTML's nl2br and other formatting 
functions -- these are currently too hard to get to.  But these have to 
be used with Python syntax (at least currently), and doing 
namespace['formatters']['nl2br'](options['message']) is just bad.  I 
don't much care for tal:define="nl2br formatters:nl2br" either, as it 
feels like boilerplate.  I suppose 
"path('formatters:nl2br')(path('options/message')) is maybe a little 
better, but only a very little.

-- 
Ian Bicking  /  ianb@colorstudy.com  /  http://blog.ianbicking.org

From evan at 4-am.com  Wed May 19 18:20:03 2004
From: evan at 4-am.com (Evan Simpson)
Date: Wed May 19 18:22:40 2004
Subject: [ZPT] RFC: TALES adapters and TAL/Tales variable namespaces
In-Reply-To: <40ABBCEB.9010801@zope.com>
References: <40ABBCEB.9010801@zope.com>
Message-ID: <40ABDD93.4040106@4-am.com>

Jim Fulton wrote:
> I've posted two proposals:
> 
>   http://dev.zope.org/Zope3/TALESPathExpressionAdapters
> 
> Proposes a mechanism for easily using adapters in TALES expressions.

I'm not at all clear on how the proposed mechanism is superior to the 
implementation of path segment prefixes that exists in Zope 2.  This 
differs from the namespace proposal that you cite, in that the object 
named on the left of the colon is not a namespace or adapter.  It is 
simply a registered name that is associated with code that interprets 
the text to the right of the colon.  This allows constuctions such as 
"a/sequence/index:2" (a.sequence[2]), "a/bag/var:x/call:" (a.bag[x]()), 
and "an/object/adapt:foo.bar" (foo.bar(an.object)).

>   http://dev.zope.org/Zope3/ZPTVariableNamespaces
> 
> proposes a mechanism for qualifying names defined in TAL and used in
> TALES expressions.

This would of course conflict with prefixes as currently defined, and 
seems weakly motivated.  I can imagine getting a similar effect with a 
more consistent syntax by allowing tal:define="x/y foo" when x supports 
an ITALESNamespace interface.  The path "x/y/z" then does exactly what 
the user would expect.  A namespace "x" can be created without any new 
TAL syntax by providing a built-in constructor, as in tal:define="x 
namespace", that creates an empty dictionary-like object with support 
with ITALESNamespace.

Cheers,

Evan @ 4-am

From jim at zope.com  Thu May 20 04:41:20 2004
From: jim at zope.com (Jim Fulton)
Date: Thu May 20 04:41:45 2004
Subject: [ZPT] RFC: TALES adapters and TAL/Tales variable namespaces
In-Reply-To: <40ABDD93.4040106@4-am.com>
References: <40ABBCEB.9010801@zope.com> <40ABDD93.4040106@4-am.com>
Message-ID: <40AC6F30.4080107@zope.com>

Evan Simpson wrote:
> Jim Fulton wrote:
> 
>> I've posted two proposals:
>>
>>   http://dev.zope.org/Zope3/TALESPathExpressionAdapters
>>
>> Proposes a mechanism for easily using adapters in TALES expressions.
> 
> 
> I'm not at all clear on how the proposed mechanism is superior to the 
> implementation of path segment prefixes that exists in Zope 2.   This
> differs from the namespace proposal that you cite, in that the object 
> named on the left of the colon is not a namespace or adapter.  It is 
> simply a registered name that is associated with code that interprets 
> the text to the right of the colon.  This allows constuctions such as 
> "a/sequence/index:2" (a.sequence[2]), "a/bag/var:x/call:" (a.bag[x]()), 
> and "an/object/adapt:foo.bar" (foo.bar(an.object)).

I thought you had proposed this, but I couldn't find a proposal
or documentation.

You say this is implemented in Zope 2? Where is it documented?

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From evan at 4-am.com  Thu May 20 13:23:01 2004
From: evan at 4-am.com (Evan Simpson)
Date: Thu May 20 13:26:48 2004
Subject: [ZPT] RFC: TALES adapters and TAL/Tales variable namespaces
In-Reply-To: <40AC6F30.4080107@zope.com>
References: <40ABBCEB.9010801@zope.com> <40ABDD93.4040106@4-am.com>
	<40AC6F30.4080107@zope.com>
Message-ID: <40ACE975.2010105@4-am.com>

Jim Fulton wrote:
> I thought you had proposed this, but I couldn't find a proposal
> or documentation.
> 
> You say this is implemented in Zope 2? Where is it documented?

Actually, it's only implemented on evan-pathprefix-branch.  It has been 
quite a while since I had a chance to work on it, so I had forgotten 
that it was never merged, or properly documented for that matter. 
Pretty much all the information about it that isn't in the source code 
is in the ZPT list archives from August and September (e.g. 
http://mail.zope.org/pipermail/zpt/2003-August/004902.html)  So, no 
worries if you decide to take a completely different direction -- it was 
never released.

Cheers,

Evan


From jim at zope.com  Fri May 21 13:56:50 2004
From: jim at zope.com (Jim Fulton)
Date: Thu May 20 13:57:47 2004
Subject: [ZPT] RFC: TALES adapters and TAL/Tales variable namespaces
In-Reply-To: <40ACE975.2010105@4-am.com>
References: <40ABBCEB.9010801@zope.com> <40ABDD93.4040106@4-am.com>
	<40AC6F30.4080107@zope.com> <40ACE975.2010105@4-am.com>
Message-ID: <40AE42E2.2080902@zope.com>

Evan Simpson wrote:
> Jim Fulton wrote:
> 
>> I thought you had proposed this, but I couldn't find a proposal
>> or documentation.
>>
>> You say this is implemented in Zope 2? Where is it documented?
> 
> 
> Actually, it's only implemented on evan-pathprefix-branch.  It has been 
> quite a while since I had a chance to work on it, so I had forgotten 
> that it was never merged, or properly documented for that matter. Pretty 
> much all the information about it that isn't in the source code is in 
> the ZPT list archives from August and September (e.g. 
> http://mail.zope.org/pipermail/zpt/2003-August/004902.html)

Thanks for the pointer.


 > So, no
> worries if you decide to take a completely different direction -- it was 
> never released.

I had forgotten that there was already a notion of namespaces (local and global)
and a syntax for defining variables in those namespaces.  This is very helpful.

So, we could define an "adapter" or "prefix" namespace without providing a
generalizd namespace mechanism.

I don't inderstand what motivated the special expression types for this
namespace.  For example, to get at file-system based code, couldn't you have
used the modules variable?

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From evan at 4-am.com  Thu May 20 16:03:37 2004
From: evan at 4-am.com (Evan Simpson)
Date: Thu May 20 16:07:24 2004
Subject: [ZPT] RFC: TALES adapters and TAL/Tales variable namespaces
In-Reply-To: <40AE42E2.2080902@zope.com>
References: <40ABBCEB.9010801@zope.com> <40ABDD93.4040106@4-am.com>
	<40AC6F30.4080107@zope.com> <40ACE975.2010105@4-am.com>
	<40AE42E2.2080902@zope.com>
Message-ID: <40AD0F19.5070401@4-am.com>

Jim Fulton wrote:
> I don't inderstand what motivated the special expression types for this
> namespace.  For example, to get at file-system based code, couldn't you 
> have used the modules variable?

I started there, but went with the special expression types because the 
set of "things" that are valid to define as prefixes is completely 
disjoint from those that you would use in other TAL statements.  I've 
grown wary of tying abstract object names to Python package and module 
structure.  Also, while I find it difficult to describe precisely, I 
have a strong intuition that arbitrary objects should not be available 
for use as prefixes.

Of course, the idea of prefixes as Zope 3 adapters intead of custom-made 
prefix implementations may change things.

Cheers,

Evan @ 4-am


From jim at zope.com  Fri May 21 09:07:24 2004
From: jim at zope.com (Jim Fulton)
Date: Fri May 21 09:33:01 2004
Subject: [ZPT] Re: RFC: TALES adapters and TAL/Tales variable namespaces
In-Reply-To: <40ABBCEB.9010801@zope.com>
References: <40ABBCEB.9010801@zope.com>
Message-ID: <40ADFF0C.1070605@zope.com>

Jim Fulton wrote:
> I've posted two proposals:
> 
>   http://dev.zope.org/Zope3/TALESPathExpressionAdapters
> 
> Proposes a mechanism for easily using adapters in TALES expressions.
> 
>   http://dev.zope.org/Zope3/ZPTVariableNamespaces
> 
> proposes a mechanism for qualifying names defined in TAL and used in
> TALES expressions.

Based on initial comments, I've retracted ZPTVariableNamespaces and
updated:

   http://dev.zope.org/Zope3/TALESPathExpressionAdapters

I've thrown out a few more spellings for adapter use:

   ob->adaptername      context->dc/title

   ob~adaptername       context~dc/title

   ob[adaptername]      context[dc]/title

Of course, Steve suggested:

   ob:adaptername       context:dc/title

So far the cast syntax seems to be the most popular:

   (adaptername)ob      (dc)context/title

with one dissension. :)

One disadvantage I see with the cast notation is that it's
a bit jarring in:

   a/b/(adapter)c/d

as the adapter is applied to a/b/c. The order just doesn't
seem quite right.

I'd love to get more feedback or suggestions for the syntax.

As far as in-template definition, I'd like to borrow from Evan's
work and allow 'adapter' to be used like 'local' or 'global' in
tal:define:

   tal:define="adapter dc modules/zope.app.dublincore/IZopeDublinCore"

Thoughts?

Jim

P.S. Thanks for all the comments so far. :)

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From stephan.richter at tufts.edu  Fri May 21 10:26:58 2004
From: stephan.richter at tufts.edu (Stephan Richter)
Date: Fri May 21 10:27:21 2004
Subject: [ZPT] Re: [Zope-dev] Re: RFC: TALES adapters and TAL/Tales variable
	namespaces
In-Reply-To: <40ADFF0C.1070605@zope.com>
References: <40ABBCEB.9010801@zope.com> <40ADFF0C.1070605@zope.com>
Message-ID: <200405211026.58005.stephan.richter@tufts.edu>

On Friday 21 May 2004 09:07, Jim Fulton wrote:
> So far the cast syntax seems to be the most popular:
>
>    (adaptername)ob      (dc)context/title

Why don't we use adaptername(ob)? Then it looks exactely like in Python! Less 
to memorize.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From stephan.richter at tufts.edu  Fri May 21 10:28:12 2004
From: stephan.richter at tufts.edu (Stephan Richter)
Date: Fri May 21 10:28:33 2004
Subject: [ZPT] Re: [Zope-dev] Re: RFC: TALES adapters and TAL/Tales variable
	namespaces
In-Reply-To: <40ADFF0C.1070605@zope.com>
References: <40ABBCEB.9010801@zope.com> <40ADFF0C.1070605@zope.com>
Message-ID: <200405211028.12668.stephan.richter@tufts.edu>

On Friday 21 May 2004 09:07, Jim Fulton wrote:
> ? ?tal:define="adapter dc modules/zope.app.dublincore/IZopeDublinCore"

This looks very nice to me.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From jim at zope.com  Fri May 21 12:02:47 2004
From: jim at zope.com (Jim Fulton)
Date: Fri May 21 12:03:04 2004
Subject: [ZPT] Re: [Zope-dev] Re: RFC: TALES adapters and TAL/Tales variable
	namespaces
In-Reply-To: <200405211026.58005.stephan.richter@tufts.edu>
References: <40ABBCEB.9010801@zope.com> <40ADFF0C.1070605@zope.com>
	<200405211026.58005.stephan.richter@tufts.edu>
Message-ID: <40AE2827.9060204@zope.com>

Stephan Richter wrote:
> On Friday 21 May 2004 09:07, Jim Fulton wrote:
> 
>>So far the cast syntax seems to be the most popular:
>>
>>   (adaptername)ob      (dc)context/title
> 
> 
> Why don't we use adaptername(ob)? Then it looks exactely like in Python! Less 
> to memorize.

Because that would be the top of a slippery slope.

People would want:

   callable(arg1, arg2, arg3)

eventually:

   foo/bar/callable(x/y, a/b/c)/q/r

which is arguably the path to madness.

A number of folks replid negatively to this idea when
it was noted in the proposal.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From ianb at colorstudy.com  Fri May 21 12:20:04 2004
From: ianb at colorstudy.com (Ian Bicking)
Date: Fri May 21 12:21:06 2004
Subject: [ZPT] Re: RFC: TALES adapters and TAL/Tales variable namespaces
In-Reply-To: <40ADFF0C.1070605@zope.com>
References: <40ABBCEB.9010801@zope.com> <40ADFF0C.1070605@zope.com>
Message-ID: <40AE2C34.9080908@colorstudy.com>

Jim Fulton wrote:
> One disadvantage I see with the cast notation is that it's
> a bit jarring in:
> 
>   a/b/(adapter)c/d
> 
> as the adapter is applied to a/b/c. The order just doesn't
> seem quite right.

That is indeed jarring, especially since c isn't an object, it's just a 
name, and a/b/c is the object in question.  This would look somewhat 
better with the current : mechanism, like a/b/c:adapter/d

My concern with this use of : was that it looked like it should be 
parsed like (a/b/c):(adapter/d), as opposed to ((a/b/c):adapter)/d -- 
maybe using something other than : wouldn't imply this grouping.  Or 
maybe if I got used to it the grouping would seem more natural.  I guess 
my intuition is that / binds more closely than : (even if there isn't 
any real precedence at all in TAL expressions).

-- 
Ian Bicking  /  ianb@colorstudy.com  /  http://blog.ianbicking.org

From evan at 4-am.com  Fri May 21 12:56:10 2004
From: evan at 4-am.com (Evan Simpson)
Date: Fri May 21 12:59:52 2004
Subject: [ZPT] Re: RFC: TALES adapters and TAL/Tales variable namespaces
In-Reply-To: <40ADFF0C.1070605@zope.com>
References: <40ABBCEB.9010801@zope.com> <40ADFF0C.1070605@zope.com>
Message-ID: <40AE34AA.7020105@4-am.com>

Jim Fulton wrote:
> One disadvantage I see with the cast notation is that it's
> a bit jarring in:
> 
>   a/b/(adapter)c/d
> 
> as the adapter is applied to a/b/c. The order just doesn't
> seem quite right.

Unless I'm misunderstanding something fundamental here, in the TALES 
context an adapter is essentially a function accepting a single 
argument.  The "adapted" object that results from applying the adapter 
function is either used directly or further traversed.  All of the other 
qualities that make up an Adapter (how it's registered, that it supports 
ITALESAdapter, etc.) are irrelevant to its use in a TALES expression.

Given all that, why do we need to shoehorn the adapter's name into the 
same path segment as one of the traversal names?  The above looks much 
more natural to me as one of:

a/b/c/(adapter)/d
a/b/c/*adapter/d
a/b/c/adapter()/d
a/b/c/adapter:/d

Note that the latter two forms allow for additional arguments.  While 
not applicable to single-argument adapters, this is certainly a useful 
feature if we don't restrict the syntax to adapters only.  In 
particular, evan-pathprefix-branch uses the colon syntax to allow 
applications such as "a/b/c/index:2/d" and "a/b/c/call:x,y/d".  This 
same scheme can easily subsume adapters in either or both of two ways: 
adapter as prefix, and adapter name as argument to a prefix.

tal:define="prefix foobar adapter:foo.bar"
tal:content="a/b/c/foobar:/d"

...or...

tal:define="prefix A builtin:adapters"
tal:content="a/b/c/A:foo.bar/d"

Cheers,

Evan @ 4-am


From EUWSL at parks.lv  Sun May 23 12:30:46 2004
From: EUWSL at parks.lv (Claudette Looney)
Date: Sun May 23 11:36:31 2004
Subject: [ZPT] employers don't hire people without degrees, buy yours today
Message-ID: <LCKZECSKRCGLHFVNUIOG@entel.cl>

An HTML attachment was scrubbed...
URL: http://mail.zope.org/pipermail/zpt/attachments/20040523/c493bc10/attachment.html
From steve at z3u.com  Mon May 24 10:25:19 2004
From: steve at z3u.com (Steve Alexander)
Date: Mon May 24 10:25:39 2004
Subject: [ZPT] {Spam?} Re: [Zope3-dev] Re: RFC: TALES adapters and TAL/Tales
	variable	namespaces
In-Reply-To: <20040521124221.4a34f5d0.casey@zope.com>
References: <40ABBCEB.9010801@zope.com>	<40ADFF0C.1070605@zope.com>
	<20040521124221.4a34f5d0.casey@zope.com>
Message-ID: <40B205CF.70104@z3u.com>


>>Of course, Steve suggested:
>>
>>   ob:adaptername       context:dc/title
> 
> 
> This really doesn't make sense. To me it reads "In the namespace of
> context get the title of dublin core".

I'm not reading ":" as having anything to do with namespaces.  Rather, I 
see '/' as the "traverse" operator, and ":" as the "adapt" operator.

-- 
Steve Alexander


From casey at zope.com  Mon May 24 11:39:27 2004
From: casey at zope.com (Casey Duncan)
Date: Mon May 24 11:38:28 2004
Subject: [ZPT] Re: {Spam?} Re: [Zope3-dev] Re: RFC: TALES adapters and
 TAL/Tales variable	namespaces
In-Reply-To: <40B205CF.70104@z3u.com>
References: <40ABBCEB.9010801@zope.com> <40ADFF0C.1070605@zope.com>
	<20040521124221.4a34f5d0.casey@zope.com> <40B205CF.70104@z3u.com>
Message-ID: <20040524113927.54884660.casey@zope.com>

On Mon, 24 May 2004 17:25:19 +0300
Steve Alexander <steve@z3u.com> wrote:

> 
> >>Of course, Steve suggested:
> >>
> >>   ob:adaptername       context:dc/title
> > 
> > 
> > This really doesn't make sense. To me it reads "In the namespace of
> > context get the title of dublin core".
> 
> I'm not reading ":" as having anything to do with namespaces.  Rather,
> I see '/' as the "traverse" operator, and ":" as the "adapt" operator.

Understood, that's just how it reads to me. Adapters are in a sense like
mini-namespaces, enough so that I think it is confusing to reuse the XML
namespace token here.

-Casey

From jim at zope.com  Thu May 27 06:19:56 2004
From: jim at zope.com (Jim Fulton)
Date: Thu May 27 06:20:05 2004
Subject: [Zope3-dev] Re: [ZPT] Re: RFC: TALES adapters and
	TAL/Tales	variable namespaces
In-Reply-To: <40AE34AA.7020105@4-am.com>
References: <40ABBCEB.9010801@zope.com> <40ADFF0C.1070605@zope.com>
	<40AE34AA.7020105@4-am.com>
Message-ID: <40B5C0CC.9000901@zope.com>

Evan Simpson wrote:
> Jim Fulton wrote:
> 
...

> Unless I'm misunderstanding something fundamental here, in the TALES 
> context an adapter is essentially a function accepting a single 
> argument. 

Yes, except s/function/callable

 > The "adapted" object that results from applying the adapter
> function is either used directly or further traversed.  All of the other 
> qualities that make up an Adapter (how it's registered, that it supports 
> ITALESAdapter, etc.) are irrelevant to its use in a TALES expression.

Yes, except that systems will define some predefined standard adapters
for providing common tasks, like formatting or meta-data access.

> Given all that, why do we need to shoehorn the adapter's name into the 
> same path segment as one of the traversal names? 

We don't.  In fact, one could argue that adaptation is a bit like
a different kind of traversal. In fact, in Zope 3, we already have
a notion of this. In general, in Zope 3 paths, we can say:

   foo/++namespace++name

where "/++namespace++" can be thought of as a special form of
namespace operator (similar and partly inspired by xpaths
"/:namespace:").

So, we could also use something like:

   content/++adapter++dc/title

but I think people want something more concide for ZPT.

I should point out that this has special importance for Zope 3
because Zope3 content objects don't provide any standard APIs.
You generally have to apply adapters to them to get at any standard
apis.

 > The above looks much
> more natural to me as one of:
> 
> a/b/c/(adapter)/d
> a/b/c/*adapter/d
> a/b/c/adapter()/d
> a/b/c/adapter:/d

Let me make these more concrete:

  context/(dc)/title
  context/*dc/title
  context/dc()/title
  context/dc:/title

IMO, if we take this route, we should think of the notation as
providing an alternate traversal operator.  That is, there is
syntax that either modifies or replaces "/", so of the examples
above, only:

  context/*dc/title

works for me.  For me:

   context->dc/title

can be read the same way. Basically, '->', is just a different
traversal operator.  FWIW, I find this more "natural" than any of
your examples. Of course, naturalness is highly subjective.

> 
> Note that the latter two forms allow for additional arguments.  While 
> not applicable to single-argument adapters, this is certainly a useful 
> feature if we don't restrict the syntax to adapters only.  In 
> particular, evan-pathprefix-branch uses the colon syntax to allow 
> applications such as "a/b/c/index:2/d" and "a/b/c/call:x,y/d".  This 
> same scheme can easily subsume adapters in either or both of two ways: 
> adapter as prefix, and adapter name as argument to a prefix.
> 
> tal:define="prefix foobar adapter:foo.bar"
> tal:content="a/b/c/foobar:/d"
> 
> ...or...
> 
> tal:define="prefix A builtin:adapters"
> tal:content="a/b/c/A:foo.bar/d"

I find I have to think waaaay to hard about what's going
on in these examples.  In particular, in the above
excample, "A" is working on both "a/b/c" and "foo.bar".
Basically, there is an extra level of indirection.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Thu May 27 06:28:34 2004
From: jim at zope.com (Jim Fulton)
Date: Thu May 27 06:28:43 2004
Subject: [Zope3-dev] Re: [ZPT] Re: RFC: TALES adapters and
	TAL/Tales	variable namespaces
In-Reply-To: <40AE2C34.9080908@colorstudy.com>
References: <40ABBCEB.9010801@zope.com> <40ADFF0C.1070605@zope.com>
	<40AE2C34.9080908@colorstudy.com>
Message-ID: <40B5C2D2.7000903@zope.com>

Ian Bicking wrote:
> Jim Fulton wrote:
> 
>> One disadvantage I see with the cast notation is that it's
>> a bit jarring in:
>>
>>   a/b/(adapter)c/d
>>
>> as the adapter is applied to a/b/c. The order just doesn't
>> seem quite right.
> 
> 
> That is indeed jarring, especially since c isn't an object, it's just a 
> name, and a/b/c is the object in question.  This would look somewhat 
> better with the current : mechanism, like a/b/c:adapter/d
> 
> My concern with this use of : was that it looked like it should be 
> parsed like (a/b/c):(adapter/d), as opposed to ((a/b/c):adapter)/d -- 
> maybe using something other than : wouldn't imply this grouping.  Or 
> maybe if I got used to it the grouping would seem more natural.  I guess 
> my intuition is that / binds more closely than : (even if there isn't 
> any real precedence at all in TAL expressions).

Yes, this is another issue.  I have the same problem, somehow, with
"foo/bar->dc/title". That is "/" seems to bind more closely than "->",
probably because it's skinnier. :)  I don't have this problem with ":".


Another option is to modify the "/". For example, Evan sugested "/*", as in

   foo/bar/*dc/title

Hm

   foo/:dc/title

Sandly, nothing really jumps out as the best syntax.

So far, I like:

   foo/bar->dc/title

the best.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Thu May 27 07:05:38 2004
From: jim at zope.com (Jim Fulton)
Date: Thu May 27 07:05:47 2004
Subject: [ZPT] Re: {Spam?} Re: [Zope3-dev] Re: RFC: TALES adapters and
 TAL/Tales variable	namespaces
In-Reply-To: <40B205CF.70104@z3u.com>
References: <40ABBCEB.9010801@zope.com>	<40ADFF0C.1070605@zope.com>	<20040521124221.4a34f5d0.casey@zope.com>
	<40B205CF.70104@z3u.com>
Message-ID: <40B5CB82.9000806@zope.com>

Steve Alexander wrote:
> 
>>> Of course, Steve suggested:
>>>
>>>   ob:adaptername       context:dc/title
>>
>>
>>
>> This really doesn't make sense. To me it reads "In the namespace of
>> context get the title of dublin core".
> 
> 
> I'm not reading ":" as having anything to do with namespaces.  Rather, I 
> see '/' as the "traverse" operator, and ":" as the "adapt" operator.

Right, and the "adapt" operator can be thought of as a specialized form of traversal.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Thu May 27 07:16:39 2004
From: jim at zope.com (Jim Fulton)
Date: Thu May 27 07:16:49 2004
Subject: [ZPT] Re: [Zope3-dev] Re: RFC: TALES adapters and TAL/Tales
	variable	namespaces
In-Reply-To: <20040521124221.4a34f5d0.casey@zope.com>
References: <40ABBCEB.9010801@zope.com>	<40ADFF0C.1070605@zope.com>
	<20040521124221.4a34f5d0.casey@zope.com>
Message-ID: <40B5CE17.6040205@zope.com>

Casey Duncan wrote:
> On Fri, 21 May 2004 09:07:24 -0400
> Jim Fulton <jim@zope.com> wrote:
> 
> 
>>Jim Fulton wrote:
>>
>>>I've posted two proposals:
>>>
>>>  http://dev.zope.org/Zope3/TALESPathExpressionAdapters
>>>
>>>Proposes a mechanism for easily using adapters in TALES expressions.
>>>
>>>  http://dev.zope.org/Zope3/ZPTVariableNamespaces
>>>
>>>proposes a mechanism for qualifying names defined in TAL and used in
>>>TALES expressions.
>>
>>Based on initial comments, I've retracted ZPTVariableNamespaces and
>>updated:
>>
>>   http://dev.zope.org/Zope3/TALESPathExpressionAdapters
>>
>>I've thrown out a few more spellings for adapter use:
>>
>>   ob->adaptername      context->dc/title
> 
> 
> Hmm, C style, kinda nice, except the use of angle brakets might make
> like difficult. 

">" is not a problem. "<" would be a probkem.



> It really is hard for me to see the intended order of
> execution of this as well. It reads "context to dublin core, get title".

That's exactly right.  The order, left to right, is very simple.

The problem with:

    (dc)context/title

is that the order is: skip one, right to left, then left to right. The order is
more complicated, except that there is an alternative left to right
interpretation ...


> Having dublin core go first makes more sense to me so it would read
> "with the dublin core of context, get title". 

So, here you thinking of this as:

   start with the dublin core protocol
   adapt it from context
   get title

...

>>One disadvantage I see with the cast notation is that it's
>>a bit jarring in:
>>
>>   a/b/(adapter)c/d
>>
>>as the adapter is applied to a/b/c. The order just doesn't
>>seem quite right.
> 
> 
> It's all in the eye of the beholder I guess. This says to me "d of c
> (modified by adapter) of b of a".

Wow :)

But this seems wrong. It's really "(c of b of a) modified by adapter".

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From sidnei at awkly.org  Thu May 27 08:06:14 2004
From: sidnei at awkly.org (Sidnei da Silva)
Date: Thu May 27 08:06:44 2004
Subject: [Zope-dev] Re: [Zope3-dev] Re: [ZPT] Re: RFC: TALES adapters and
	TAL/Tales	variable namespaces
In-Reply-To: <40B5C2D2.7000903@zope.com>
References: <40ABBCEB.9010801@zope.com> <40ADFF0C.1070605@zope.com>
	<40AE2C34.9080908@colorstudy.com> <40B5C2D2.7000903@zope.com>
Message-ID: <20040527120614.GS1968@intranet.awkly.org>

| So far, I like:
| 
|   foo/bar->dc/title
| 
| the best.

OTOH, for 'valid' xhtml, u would have to write:

 foo/bar->&gt;dc/title

Totally defeating the purpose. One may argue that this would not be
part of the output, but it breaks the editors (at least nxml-mode).

-- 
Sidnei da Silva <sidnei@awkly.org>
http://awkly.org - dreamcatching :: making your dreams come true
http://www.enfoldsystems.com
http://plone.org/about/team#dreamcatcher

Linux - Where do you want to fly today?
	-- Unknown source

From jim at zope.com  Thu May 27 08:33:29 2004
From: jim at zope.com (Jim Fulton)
Date: Thu May 27 08:33:44 2004
Subject: [Zope-dev] Re: [Zope3-dev] Re: [ZPT] Re: RFC: TALES adapters
	and TAL/Tales	variable namespaces
In-Reply-To: <20040527120614.GS1968@intranet.awkly.org>
References: <40ABBCEB.9010801@zope.com> <40ADFF0C.1070605@zope.com>
	<40AE2C34.9080908@colorstudy.com> <40B5C2D2.7000903@zope.com>
	<20040527120614.GS1968@intranet.awkly.org>
Message-ID: <40B5E019.8030008@zope.com>

Sidnei da Silva wrote:
> | So far, I like:
> | 
> |   foo/bar->dc/title
> | 
> | the best.
> 
> OTOH, for 'valid' xhtml, u would have to write:

You mean well-formed.

> 
>  foo/bar-&gt;dc/title
> 
> Totally defeating the purpose. One may argue that this would not be
> part of the output, but it breaks the editors (at least nxml-mode).

Wrong. Double check the spec.  (I did. :)

http://www.w3.org/TR/2004/REC-xml11-20040204/#NT-AttValue

You only need to escape the less-than because there's no way to
mistake "a->b" as a tag.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From sidnei at awkly.org  Thu May 27 09:10:25 2004
From: sidnei at awkly.org (Sidnei da Silva)
Date: Thu May 27 09:11:21 2004
Subject: [Zope-dev] Re: [Zope3-dev] Re: [ZPT] Re: RFC: TALES adapters and
	TAL/Tales	variable namespaces
In-Reply-To: <40B5E019.8030008@zope.com>
References: <40ABBCEB.9010801@zope.com> <40ADFF0C.1070605@zope.com>
	<40AE2C34.9080908@colorstudy.com> <40B5C2D2.7000903@zope.com>
	<20040527120614.GS1968@intranet.awkly.org>
	<40B5E019.8030008@zope.com>
Message-ID: <20040527131025.GT1968@intranet.awkly.org>

| You mean well-formed.

Right.

| Wrong. Double check the spec.  (I did. :)
| 
| http://www.w3.org/TR/2004/REC-xml11-20040204/#NT-AttValue
| 
| You only need to escape the less-than because there's no way to
| mistake "a->b" as a tag.

Beats me :)

-- 
Sidnei da Silva <sidnei@awkly.org>
http://awkly.org - dreamcatching :: making your dreams come true
http://www.enfoldsystems.com
http://plone.org/about/team#dreamcatcher

Those who don't understand Linux are doomed to reinvent it, poorly.
	-- unidentified source

From tseaver at zope.com  Thu May 27 09:30:44 2004
From: tseaver at zope.com (Tres Seaver)
Date: Thu May 27 09:31:38 2004
Subject: [ZPT] Re: [Zope-dev] Re: [Zope3-dev] Re: Re: RFC: TALES adapters and
 TAL/Tales variable namespaces
In-Reply-To: <40B5E019.8030008@zope.com>
References: <40ABBCEB.9010801@zope.com>
	<40ADFF0C.1070605@zope.com>	<40AE2C34.9080908@colorstudy.com>
	<40B5C2D2.7000903@zope.com>	<20040527120614.GS1968@intranet.awkly.org>
	<40B5E019.8030008@zope.com>
Message-ID: <40B5ED84.5010408@zope.com>

Jim Fulton wrote:
> Sidnei da Silva wrote:
> 
>> | So far, I like:
>> | |   foo/bar->dc/title
>> | | the best.
>>
>> OTOH, for 'valid' xhtml, u would have to write:
> 
> You mean well-formed.
> 
>>  foo/bar-&gt;dc/title
>>
>> Totally defeating the purpose. One may argue that this would not be
>> part of the output, but it breaks the editors (at least nxml-mode).
> 
> Wrong. Double check the spec.  (I did. :)
> 
> http://www.w3.org/TR/2004/REC-xml11-20040204/#NT-AttValue
> 
> You only need to escape the less-than because there's no way to
> mistake "a->b" as a tag.

xmllint (from libxml2) doesn't think the '>' is legitimate::

   [/home/tseaver]
   $ cat > test.xml
   <?xml version="1.0"?>
   <test attribute="foo > bar" />
   [/home/tseaver]
   $ xmllint test.xml
   <?xml version="1.0"?>
   <test attribute="foo &gt; bar"/>

I would be reluctant to duel with Daniel using my XML language lawyer chops.

Tres.
-- 
===============================================================
Tres Seaver                                tseaver@zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com

From tseaver at zope.com  Thu May 27 09:30:44 2004
From: tseaver at zope.com (Tres Seaver)
Date: Thu May 27 09:44:42 2004
Subject: [ZPT] Re: [Zope-dev] Re: [Zope3-dev] Re: Re: RFC: TALES adapters and
 TAL/Tales variable namespaces
In-Reply-To: <40B5E019.8030008@zope.com>
References: <40ABBCEB.9010801@zope.com>
	<40ADFF0C.1070605@zope.com>	<40AE2C34.9080908@colorstudy.com>
	<40B5C2D2.7000903@zope.com>	<20040527120614.GS1968@intranet.awkly.org>
	<40B5E019.8030008@zope.com>
Message-ID: <40B5ED84.5010408@zope.com>

Jim Fulton wrote:
> Sidnei da Silva wrote:
> 
>> | So far, I like:
>> | |   foo/bar->dc/title
>> | | the best.
>>
>> OTOH, for 'valid' xhtml, u would have to write:
> 
> You mean well-formed.
> 
>>  foo/bar-&gt;dc/title
>>
>> Totally defeating the purpose. One may argue that this would not be
>> part of the output, but it breaks the editors (at least nxml-mode).
> 
> Wrong. Double check the spec.  (I did. :)
> 
> http://www.w3.org/TR/2004/REC-xml11-20040204/#NT-AttValue
> 
> You only need to escape the less-than because there's no way to
> mistake "a->b" as a tag.

xmllint (from libxml2) doesn't think the '>' is legitimate::

   [/home/tseaver]
   $ cat > test.xml
   <?xml version="1.0"?>
   <test attribute="foo > bar" />
   [/home/tseaver]
   $ xmllint test.xml
   <?xml version="1.0"?>
   <test attribute="foo &gt; bar"/>

I would be reluctant to duel with Daniel using my XML language lawyer chops.

Tres.
-- 
===============================================================
Tres Seaver                                tseaver@zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com


From jim at zope.com  Thu May 27 11:09:35 2004
From: jim at zope.com (Jim Fulton)
Date: Thu May 27 11:13:01 2004
Subject: [ZPT] Re: [Zope-dev] Re: [Zope3-dev] Re: Re: RFC: TALES adapters and
 TAL/Tales variable namespaces
In-Reply-To: <40B5ED84.5010408@zope.com>
References: <40ABBCEB.9010801@zope.com>
	<40ADFF0C.1070605@zope.com>	<40AE2C34.9080908@colorstudy.com>
	<40B5C2D2.7000903@zope.com>	<20040527120614.GS1968@intranet.awkly.org>
	<40B5E019.8030008@zope.com> <40B5ED84.5010408@zope.com>
Message-ID: <40B604AF.60909@zope.com>

Tres Seaver wrote:
> Jim Fulton wrote:
> 
>> Sidnei da Silva wrote:
>>
>>> | So far, I like:
>>> | |   foo/bar->dc/title
>>> | | the best.
>>>
>>> OTOH, for 'valid' xhtml, u would have to write:
>>
>>
>> You mean well-formed.
>>
>>>  foo/bar-&gt;dc/title
>>>
>>> Totally defeating the purpose. One may argue that this would not be
>>> part of the output, but it breaks the editors (at least nxml-mode).
>>
>>
>> Wrong. Double check the spec.  (I did. :)
>>
>> http://www.w3.org/TR/2004/REC-xml11-20040204/#NT-AttValue
>>
>> You only need to escape the less-than because there's no way to
>> mistake "a->b" as a tag.
> 
> 
> xmllint (from libxml2) doesn't think the '>' is legitimate::
> 
>   [/home/tseaver]
>   $ cat > test.xml
>   <?xml version="1.0"?>
>   <test attribute="foo > bar" />
>   [/home/tseaver]
>   $ xmllint test.xml
>   <?xml version="1.0"?>
>   <test attribute="foo &gt; bar"/>

Pehaps, in the tradition of lint programs, it's being conservative.

> I would be reluctant to duel with Daniel using my XML language lawyer 
> chops.

The spec is pretty clear.

But, if tools are going to be confused by this, we should avoid it.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Thu May 27 11:09:35 2004
From: jim at zope.com (Jim Fulton)
Date: Thu May 27 11:42:33 2004
Subject: [ZPT] Re: [Zope-dev] Re: [Zope3-dev] Re: Re: RFC: TALES adapters and
 TAL/Tales variable namespaces
In-Reply-To: <40B5ED84.5010408@zope.com>
References: <40ABBCEB.9010801@zope.com>
	<40ADFF0C.1070605@zope.com>	<40AE2C34.9080908@colorstudy.com>
	<40B5C2D2.7000903@zope.com>	<20040527120614.GS1968@intranet.awkly.org>
	<40B5E019.8030008@zope.com> <40B5ED84.5010408@zope.com>
Message-ID: <40B604AF.60909@zope.com>

Tres Seaver wrote:
> Jim Fulton wrote:
> 
>> Sidnei da Silva wrote:
>>
>>> | So far, I like:
>>> | |   foo/bar->dc/title
>>> | | the best.
>>>
>>> OTOH, for 'valid' xhtml, u would have to write:
>>
>>
>> You mean well-formed.
>>
>>>  foo/bar-&gt;dc/title
>>>
>>> Totally defeating the purpose. One may argue that this would not be
>>> part of the output, but it breaks the editors (at least nxml-mode).
>>
>>
>> Wrong. Double check the spec.  (I did. :)
>>
>> http://www.w3.org/TR/2004/REC-xml11-20040204/#NT-AttValue
>>
>> You only need to escape the less-than because there's no way to
>> mistake "a->b" as a tag.
> 
> 
> xmllint (from libxml2) doesn't think the '>' is legitimate::
> 
>   [/home/tseaver]
>   $ cat > test.xml
>   <?xml version="1.0"?>
>   <test attribute="foo > bar" />
>   [/home/tseaver]
>   $ xmllint test.xml
>   <?xml version="1.0"?>
>   <test attribute="foo &gt; bar"/>

Pehaps, in the tradition of lint programs, it's being conservative.

> I would be reluctant to duel with Daniel using my XML language lawyer 
> chops.

The spec is pretty clear.

But, if tools are going to be confused by this, we should avoid it.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org



From evan at 4-am.com  Thu May 27 15:13:38 2004
From: evan at 4-am.com (Evan Simpson)
Date: Thu May 27 15:17:46 2004
Subject: [ZPT] Re: [Zope3-dev] Re: Re: RFC: TALES adapters and TAL/Tales
 variable namespaces
In-Reply-To: <40B5C0CC.9000901@zope.com>
References: <40ABBCEB.9010801@zope.com>
	<40ADFF0C.1070605@zope.com>	<40AE34AA.7020105@4-am.com>
	<40B5C0CC.9000901@zope.com>
Message-ID: <40B63DE2.3050004@4-am.com>

Jim Fulton wrote:
> IMO, if we take this route, we should think of the notation as
> providing an alternate traversal operator.  That is, there is
> syntax that either modifies or replaces "/", so of the examples
> above, only:
> 
>  context/*dc/title

In that case, I'd be happy to consider adaptation as orthogonal to my 
path prefixes.  Might as well drop the slash and go with the previous 
suggestion:

context*dc/title

I can easily read the star as an adaptation operator, even with multiple 
applications.

Cheers,

Evan


From jim at zope.com  Thu May 27 15:32:43 2004
From: jim at zope.com (Jim Fulton)
Date: Thu May 27 15:32:52 2004
Subject: [ZPT] Re: [Zope3-dev] Re: Re: RFC: TALES adapters and TAL/Tales
 variable namespaces
In-Reply-To: <40B63DE2.3050004@4-am.com>
References: <40ABBCEB.9010801@zope.com>
	<40ADFF0C.1070605@zope.com>	<40AE34AA.7020105@4-am.com>
	<40B5C0CC.9000901@zope.com> <40B63DE2.3050004@4-am.com>
Message-ID: <40B6425B.4000902@zope.com>

Evan Simpson wrote:
> Jim Fulton wrote:
> 
>> IMO, if we take this route, we should think of the notation as
>> providing an alternate traversal operator.  That is, there is
>> syntax that either modifies or replaces "/", so of the examples
>> above, only:
>>
>>  context/*dc/title
> 
> 
> In that case, I'd be happy to consider adaptation as orthogonal to my 
> path prefixes. 

Yup.

 > Might as well drop the slash and go with the previous
> suggestion:
> 
> context*dc/title
> 
> I can easily read the star as an adaptation operator, even with multiple 
> applications.

On IRC, Martijn Faassen suggested (brainstormed really :) '#', as in:

   context#dc/title

I like this becase # kinda looks like a special kind of slash. :)

What do people think of this?

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From contact_tonico at yahoo.de  Thu May 27 16:00:50 2004
From: contact_tonico at yahoo.de (Tonico Strasser)
Date: Thu May 27 15:44:11 2004
Subject: [ZPT] Re: RFC: TALES adapters and TAL/Tales variable   namespaces
In-Reply-To: <40B6425B.4000902@zope.com>
References: <40ABBCEB.9010801@zope.com>	<40ADFF0C.1070605@zope.com>	<40AE34AA.7020105@4-am.com>	<40B5C0CC.9000901@zope.com>
	<40B63DE2.3050004@4-am.com> <40B6425B.4000902@zope.com>
Message-ID: <40B648F2.7040904@yahoo.de>

Jim Fulton wrote:

> Evan Simpson wrote:
> 
>> Jim Fulton wrote:
>>
>>> IMO, if we take this route, we should think of the notation as
>>> providing an alternate traversal operator.  That is, there is
>>> syntax that either modifies or replaces "/", so of the examples
>>> above, only:
>>>
>>>  context/*dc/title
>>
>>
>>
>> In that case, I'd be happy to consider adaptation as orthogonal to my 
>> path prefixes. 
> 
> 
> Yup.
> 
>  > Might as well drop the slash and go with the previous
> 
>> suggestion:
>>
>> context*dc/title
>>
>> I can easily read the star as an adaptation operator, even with 
>> multiple applications.
> 
> 
> On IRC, Martijn Faassen suggested (brainstormed really :) '#', as in:
> 
>   context#dc/title
> 
> I like this becase # kinda looks like a special kind of slash. :)

Hm, special kind of slash ... what about

context\dc/title

Tonico
(Not yet a Python developer.)



From mgedmin at b4net.lt  Thu May 27 17:32:39 2004
From: mgedmin at b4net.lt (Marius Gedminas)
Date: Thu May 27 17:33:08 2004
Subject: [ZPT] Re: [Zope3-dev] Re: Re: RFC: TALES adapters and TAL/Tales
	variable namespaces
In-Reply-To: <c95k8v$sig$1@sea.gmane.org>
References: <40ABBCEB.9010801@zope.com> <40ADFF0C.1070605@zope.com>
	<40AE34AA.7020105@4-am.com> <40B5C0CC.9000901@zope.com>
	<c95k8v$sig$1@sea.gmane.org>
Message-ID: <20040527213239.GA27803@perlas>

On Thu, May 27, 2004 at 03:55:23PM -0500, Garrett Smith wrote:
> > So, we could also use something like:
> >
> >   content/++adapter++dc/title
> >
> > but I think people want something more concide for ZPT.
> 
> I prefer this notation, even though it's more verbose. I think it should 
> be supported along with a short cut syntax.
> 
> This problem seems analogous to view lookup -- 
> "content/++view++index.html" and "content/@@index.html" are equivalent.
> 
> So, applied to adapters, we could use:
> 
>   content/++adapter++dc/title (or '++adapt++')
> 
> one could use:
> 
>   content/##dc/title
> 
> or perhaps (yuckier):
> 
>   content/**dc/title
> 
> I'd hate to see Yet Another Traversal Syntax introduced when we already 
> have a decent pattern established.

I like this train of thought.  Today I brainstormed

  content/::dc/title

on IRC.  I'm not entirely sure why, but adaptation and the ':' character
seem to be related in my mind.

Marius Gedminas
-- 
Never be afraid to tell the world who you are.
                -- Anonymous
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mail.zope.org/pipermail/zpt/attachments/20040528/da9a9d91/attachment.bin
From garrett at mojave-corp.com  Thu May 27 16:55:23 2004
From: garrett at mojave-corp.com (Garrett Smith)
Date: Thu May 27 17:51:30 2004
Subject: [ZPT] Re: [Zope3-dev] Re: Re: RFC: TALES adapters and TAL/Tales
 variable namespaces
In-Reply-To: <40B5C0CC.9000901@zope.com>
References: <40ABBCEB.9010801@zope.com>
	<40ADFF0C.1070605@zope.com>	<40AE34AA.7020105@4-am.com>
	<40B5C0CC.9000901@zope.com>
Message-ID: <c95k8v$sig$1@sea.gmane.org>

Jim Fulton wrote:

 > We don't.  In fact, one could argue that adaptation is a bit like
 > a different kind of traversal. In fact, in Zope 3, we already have
 > a notion of this. In general, in Zope 3 paths, we can say:
 >
 >   foo/++namespace++name
 >
 > where "/++namespace++" can be thought of as a special form of
 > namespace operator (similar and partly inspired by xpaths
 > "/:namespace:").
 >
 > So, we could also use something like:
 >
 >   content/++adapter++dc/title
 >
 > but I think people want something more concide for ZPT.

I prefer this notation, even though it's more verbose. I think it should 
be supported along with a short cut syntax.

This problem seems analogous to view lookup -- 
"content/++view++index.html" and "content/@@index.html" are equivalent.

So, applied to adapters, we could use:

   content/++adapter++dc/title (or '++adapt++')

one could use:

   content/##dc/title

or perhaps (yuckier):

   content/**dc/title

I'd hate to see Yet Another Traversal Syntax introduced when we already 
have a decent pattern established.

  -- Garrett



From Joe.Nguyen at coair.com  Thu May 27 18:30:47 2004
From: Joe.Nguyen at coair.com (Nguyen, Joe)
Date: Thu May 27 18:32:45 2004
Subject: [ZPT] tal:repeat problem
Message-ID: <28A471EF3151244187A887958F39415D0D95B02D@nhqjexc02.nam.coair.com>

Hi list, 

 

I've trying to figure out a problem that seems pretty trivial but I couldn't
figure it out.

I've been racking my brains over this.  Here's my problem:

 

Let's say I have a list that I pass to a zpt.  I'll call this  nameList,
with lets say there are 1000+ names on the list.

I want to display this within a table with only 12 columns. This is where my
problem lies.  I'm sure there's an easy way but I couldn't quit figure it
out!  I have something like this but it doesn't work at all, just to give
you an idea

 

 

 

<tr tal:repeat="x python:range(0,1000)">

    <td align="center" tal:repeat="y range(0,12)"

                       tal:content="python:nameList[x]">

    </td>

</tr>

 

Also, is there a function that can tell if it's at the end of the list?

Thanks in advance!

 

Joe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.zope.org/pipermail/zpt/attachments/20040527/7890e7b0/attachment.html
From Doug.Tillman at grainger.com  Thu May 27 23:07:50 2004
From: Doug.Tillman at grainger.com (Doug Tillman)
Date: Thu May 27 23:08:10 2004
Subject: [ZPT] Accessing Brains Using ZPT
Message-ID: <s0b666c6.082@ni7nmc_nigwia1_s.7300.grainger.com>

I'm attempting to use a Brain bound to a ZSQL method.  While I have no
trouble finding a DTML example of how to access a method of my bound
class in a loop I can't find a tal:repeat example.  Is this even doable
with ZPT?

I tried a variety of approaches canibalized from various references.  I
had great hopes for this one:
<span tal:define="doc nocall:container/cvsusersobj"
      tal:content="string:${doc/fullName}">Full Name</span>

where cvsuserobj is a DTML method that defined the class fullName
attribute in a dtml-var.

Any help, code snippets, pointers to resources or examples would be
most welcome.


Doug

From philipp at weitershausen.de  Fri May 28 02:48:04 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Fri May 28 02:53:08 2004
Subject: [ZPT] Re: RFC: TALES adapters and TAL/Tales variable   namespaces
In-Reply-To: <c95k8v$sig$1@sea.gmane.org>
References: <40ABBCEB.9010801@zope.com>	<40ADFF0C.1070605@zope.com>	<40AE34AA.7020105@4-am.com>	<40B5C0CC.9000901@zope.com>
	<c95k8v$sig$1@sea.gmane.org>
Message-ID: <40B6E0A4.5000100@weitershausen.de>

Garrett Smith wrote:
> This problem seems analogous to view lookup -- 
> "content/++view++index.html" and "content/@@index.html" are equivalent.
> 
> So, applied to adapters, we could use:
> 
>   content/++adapter++dc/title (or '++adapt++')

+1 on ++adapt++.

I think using the the traversal machinery and its syntax would be a very 
elegant solution. Then using either ##, ** or :: as a shortcut (in 
analogy to @@) would be even more consistent, since in current 
component-architecture-speak, views are multi-adapters.

Just compare them visually:

   - context/@@absolute_url

   - context/date/**format

or

   - context/@@standard_macros/page

   - context/**dc/title

> one could use:
> 
>   content/##dc/title

Using # in path expressions always reminds me of anchors in HTML, e.g. 
http://foo/bar#section2

> or perhaps (yuckier):
> 
>   content/**dc/title

+1

> I'd hate to see Yet Another Traversal Syntax introduced when we already 
> have a decent pattern established.

Indeed. Especially introducing non-slash characters as separaters in 
path expressions, such as parentheses, would mean getting rid of their 
beauty through simplicity. I feel very strongly about keeping path 
expressions simple and not cryptic.

Philipp


From contact_tonico at yahoo.de  Fri May 28 06:05:52 2004
From: contact_tonico at yahoo.de (Tonico Strasser)
Date: Fri May 28 05:48:59 2004
Subject: [ZPT] Re: tal:repeat problem
In-Reply-To: <28A471EF3151244187A887958F39415D0D95B02D@nhqjexc02.nam.coair.com>
References: <28A471EF3151244187A887958F39415D0D95B02D@nhqjexc02.nam.coair.com>
Message-ID: <40B70F00.7000300@yahoo.de>

Nguyen, Joe wrote:

> Let?s say I have a list that I pass to a zpt.  I?ll call this  nameList, 
> with lets say there are 1000+ names on the list.
> 
> I want to display this within a table with only 12 columns. This is 
> where my problem lies.  I?m sure there?s an easy way but I couldn?t quit 
> figure it out!  I have something like this but it doesn?t work at all, 
> just to give you an idea
> 

Not sure what you mean, maybe you want something like this:

<table tal:define="items python: 1000;
                    cols python: 12;
                    remainder python: items % cols;
                    rows python: items / cols;
                    rows python: test(remainder, rows + 1, rows);">
   <tr tal:repeat="row python: range(rows);">
     <td tal:define="start python: cols * row;
                     end python: start + cols;"
         tal:repeat="item python: range(start, end);"
         tal:content="python: test(item <= items, item, 'x');"/>
   </tr>
</table>

> Also, is there a function that can tell if it?s at the end of the list?

Yes, see the ZPT help in the ZMI or the Zope book.

Tonico


From stephan.richter at tufts.edu  Fri May 28 06:53:35 2004
From: stephan.richter at tufts.edu (Stephan Richter)
Date: Fri May 28 06:54:30 2004
Subject: [ZPT] Re: [Zope3-dev] Re: RFC: TALES adapters and TAL/Tales
	variable namespaces
In-Reply-To: <40B6E0A4.5000100@weitershausen.de>
References: <40ABBCEB.9010801@zope.com> <c95k8v$sig$1@sea.gmane.org>
	<40B6E0A4.5000100@weitershausen.de>
Message-ID: <200405280653.35984.stephan.richter@tufts.edu>

On Friday 28 May 2004 02:48, Philipp von Weitershausen wrote:
> Garrett Smith wrote:
> > This problem seems analogous to view lookup --
> > "content/++view++index.html" and "content/@@index.html" are equivalent.
> >
> > So, applied to adapters, we could use:
> >
> > ? content/++adapter++dc/title (or '++adapt++')
>
> +1 on ++adapt++.
>
> I think using the the traversal machinery and its syntax would be a very
> elegant solution. Then using either ##, ** or :: as a shortcut (in
> analogy to @@) would be even more consistent, since in current
> component-architecture-speak, views are multi-adapters.
>
> Just compare them visually:
>
> ? ?- context/@@absolute_url

+1
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From stephan.richter at tufts.edu  Fri May 28 11:21:29 2004
From: stephan.richter at tufts.edu (Stephan Richter)
Date: Fri May 28 11:22:08 2004
Subject: [ZPT] Re: [Zope3-dev] Re: RFC: TALES adapters and TAL/Tales
	variable namespaces
In-Reply-To: <c97l2o$6q2$1@sea.gmane.org>
References: <40ABBCEB.9010801@zope.com>
	<200405280653.35984.stephan.richter@tufts.edu>
	<c97l2o$6q2$1@sea.gmane.org>
Message-ID: <200405281121.29484.stephan.richter@tufts.edu>

On Friday 28 May 2004 11:21, Garrett Smith wrote:
> ? ?context/##dc/title

Not so good; looks convoluted.

> ? ?context/**dc/title

This one looks good. Remind me of the power of a number, like dc takes over 
context. :-)

> ? ?context/::dc/title

I am fine with this one as well.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From stephan.richter at tufts.edu  Fri May 28 11:22:48 2004
From: stephan.richter at tufts.edu (Stephan Richter)
Date: Fri May 28 11:23:25 2004
Subject: [ZPT] Re: [Zope3-dev] Re: RFC: TALES adapters and TAL/Tales
	variable namespaces
In-Reply-To: <c97l2o$6q2$1@sea.gmane.org>
References: <40ABBCEB.9010801@zope.com>
	<200405280653.35984.stephan.richter@tufts.edu>
	<c97l2o$6q2$1@sea.gmane.org>
Message-ID: <200405281122.48372.stephan.richter@tufts.edu>

On Friday 28 May 2004 11:21, Garrett Smith wrote:
> What was the reasoning behind selecting @@ for the view namespace
> shortcut?

Because it looks like two eyes.

> (IIRC, the motivation was to use characters that could be used 
> in URLs, but I'm not sure that's an issue for adapters...or is it?)

That was one consideration; there was extensive research done on which 
characters would be permissible. I do not think we have the same issue with 
the adapters though.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From jim at zope.com  Fri May 28 11:41:53 2004
From: jim at zope.com (Jim Fulton)
Date: Fri May 28 11:42:10 2004
Subject: [ZPT] Re: [Zope3-dev] Re: RFC: TALES adapters and TAL/Tales
	variable	namespaces
In-Reply-To: <c97l2o$6q2$1@sea.gmane.org>
References: <40ABBCEB.9010801@zope.com>	<c95k8v$sig$1@sea.gmane.org>	<40B6E0A4.5000100@weitershausen.de>	<200405280653.35984.stephan.richter@tufts.edu>
	<c97l2o$6q2$1@sea.gmane.org>
Message-ID: <40B75DC1.6000908@zope.com>

Garrett Smith wrote:

> What was the reasoning behind selecting @@ for the view namespace 
> shortcut? (IIRC, the motivation was to use characters that could be used 
> in URLs, but I'm not sure that's an issue for adapters...or is it?)

Legal in urls, no English. @@ looks like two eyes viwing something. :)

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org

From jim at zope.com  Fri May 28 11:54:56 2004
From: jim at zope.com (Jim Fulton)
Date: Fri May 28 11:55:15 2004
Subject: [ZPT] Re: [Zope3-dev] Re: Re: RFC: TALES adapters and TAL/Tales
 variable namespaces
In-Reply-To: <c95k8v$sig$1@sea.gmane.org>
References: <40ABBCEB.9010801@zope.com>	<40ADFF0C.1070605@zope.com>	<40AE34AA.7020105@4-am.com>	<40B5C0CC.9000901@zope.com>
	<c95k8v$sig$1@sea.gmane.org>
Message-ID: <40B760D0.3010003@zope.com>


I want to thank everyone who's participating in this
thread. The input is extremely valuable.

Garrett Smith wrote:
> Jim Fulton wrote:
> 
>  > We don't.  In fact, one could argue that adaptation is a bit like
>  > a different kind of traversal. In fact, in Zope 3, we already have
>  > a notion of this. In general, in Zope 3 paths, we can say:
>  >
>  >   foo/++namespace++name
>  >
>  > where "/++namespace++" can be thought of as a special form of
>  > namespace operator (similar and partly inspired by xpaths
>  > "/:namespace:").
>  >
>  > So, we could also use something like:
>  >
>  >   content/++adapter++dc/title
>  >
>  > but I think people want something more concide for ZPT.
> 
> I prefer this notation, even though it's more verbose. I think it should 
> be supported along with a short cut syntax.
> 
> This problem seems analogous to view lookup -- 
> "content/++view++index.html" and "content/@@index.html" are equivalent.
> 
> So, applied to adapters, we could use:
> 
>   content/++adapter++dc/title (or '++adapt++')
> 
> one could use:
> 
>   content/##dc/title
> 
> or perhaps (yuckier):
> 
>   content/**dc/title
> 
> I'd hate to see Yet Another Traversal Syntax introduced

Too late. :) Path expressions already introduce separate syntax.
This is, in part, to take advantage of the TALES variable namespaces,
which aren't relevent to generic path traversal.

 > when we already
> have a decent pattern established.

We are talking about two different systems here.
The ++namespace++name syntax is part of Zope's generic path execution
machinery, which Zope 3 TALES uses.  When we use this syntax, or @@name.
all of the work is done by the namespace machinery, not by TALES. This means
that TALES has no control over it.

So, if you rely solely on the standard traversal machinery, you won't
be able to define short names within the template.

I suggest that whatever short syntax we come up with should be handled by
TALES, not the standard path traversal machinery.

Given that, I still prefer context#dc to context/##dc.

Jim


-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org

From contact_tonico at yahoo.de  Fri May 28 13:59:02 2004
From: contact_tonico at yahoo.de (Tonico Strasser)
Date: Fri May 28 13:42:04 2004
Subject: [ZPT] Re: tal:repeat problem
In-Reply-To: <40B70F00.7000300@yahoo.de>
References: <28A471EF3151244187A887958F39415D0D95B02D@nhqjexc02.nam.coair.com>
	<40B70F00.7000300@yahoo.de>
Message-ID: <c97tl1$51t$1@sea.gmane.org>

Tonico Strasser wrote:
> 
> <table tal:define="items python: 1000;
>                    cols python: 12;
>                    remainder python: items % cols;
>                    rows python: items / cols;
>                    rows python: test(remainder, rows + 1, rows);">
>   <tr tal:repeat="row python: range(rows);">
>     <td tal:define="start python: cols * row;
>                     end python: start + cols;"
>         tal:repeat="item python: range(start, end);"
>         tal:content="python: test(item <= items, item, 'x');"/>
>   </tr>
> </table>

-         tal:content="python: test(item <= items, item, 'x');"/>
+         tal:content="python: test(item < items, item, 'x');"/>

Small correction :-)

Tonico


From gary at modernsongs.com  Fri May 28 14:51:26 2004
From: gary at modernsongs.com (Gary Poster)
Date: Fri May 28 15:21:18 2004
Subject: [ZPT] Re: RFC: TALES adapters and TAL/Tales variable   namespaces
In-Reply-To: <40B760D0.3010003@zope.com>
References: <40ABBCEB.9010801@zope.com>	<40ADFF0C.1070605@zope.com>	<40AE34AA.7020105@4-am.com>	<40B5C0CC.9000901@zope.com>	<c95k8v$sig$1@sea.gmane.org>
	<40B760D0.3010003@zope.com>
Message-ID: <c981lj$hhv$1@sea.gmane.org>

Jim Fulton wrote:

> Given that, I still prefer context#dc to context/##dc.

+1, also in preference to "/#" and the other options I've seen.

Gary


From dieter at handshake.de  Fri May 28 15:05:13 2004
From: dieter at handshake.de (Dieter Maurer)
Date: Fri May 28 17:06:21 2004
Subject: [ZPT] Accessing Brains Using ZPT
In-Reply-To: <s0b666c6.082@ni7nmc_nigwia1_s.7300.grainger.com>
References: <s0b666c6.082@ni7nmc_nigwia1_s.7300.grainger.com>
Message-ID: <16567.36201.142031.375825@gargle.gargle.HOWL>

Doug Tillman wrote at 2004-5-27 22:07 -0500:
>I'm attempting to use a Brain bound to a ZSQL method.  While I have no
>trouble finding a DTML example of how to access a method of my bound
>class in a loop I can't find a tal:repeat example.  Is this even doable
>with ZPT?
>
>I tried a variety of approaches canibalized from various references.  I
>had great hopes for this one:
><span tal:define="doc nocall:container/cvsusersobj"
>      tal:content="string:${doc/fullName}">Full Name</span>
>
>where cvsuserobj is a DTML method that defined the class fullName
>attribute in a dtml-var.

Help! What are you doing here?

  What does it have to do with a ZSQL Method brain?

You access the method of a brain in exactly the same way
as you access any method. E.g.:

   <XXX tal:repeat="brain ZSQL">
     <YYY tal:content="brain/method1" />
     <YYY tal:content="python: brain.method2(...)" />
   </XXX>

-- 
Dieter

From chris at simplistix.co.uk  Mon May 31 06:40:58 2004
From: chris at simplistix.co.uk (Chris Withers)
Date: Mon May 31 06:41:07 2004
Subject: [ZPT] Re: [Zope3-dev] Re: RFC: TALES adapters and TAL/Tales
	variable	namespaces
In-Reply-To: <c97p1r$k60$1@sea.gmane.org>
References: <40ABBCEB.9010801@zope.com>	<40ADFF0C.1070605@zope.com>	<40AE34AA.7020105@4-am.com>	<40B5C0CC.9000901@zope.com>	<c95k8v$sig$1@sea.gmane.org>	<40B760D0.3010003@zope.com>
	<c97p1r$k60$1@sea.gmane.org>
Message-ID: <40BB0BBA.4010101@simplistix.co.uk>

Garrett Smith wrote:

>> I want to thank everyone who's participating in this
>> thread. The input is extremely valuable.
> 
> This might get an award for longest thread before The Edict is handed 
> down ;)

Yeah, and I have to admit being a bemused bystander...

I thought we had this whole discussion about 1-2 years ago, and I REMEMBER 
writing CODE for this back then that involved : as the adapter indicator.

Why are we having this whole discussion again?

Was there something wrong with the code? :-S

Chris

-- 
Simplistix - Content Management, Zope & Python Consulting
            - http://www.simplistix.co.uk


From os2mac at earthlink.net  Mon May 31 13:12:41 2004
From: os2mac at earthlink.net (Michael A Rowley)
Date: Mon May 31 13:11:52 2004
Subject: [ZPT] writing data to zope objects
Message-ID: <B97AFB95-B325-11D8-BF7E-000A95675988@earthlink.net>

hello all

I am still battling this problem...  I have an application that records 
a lot of data from user input.  Much of this data is repetative, but 
stored independantly.  Specifically, vital signs on patients.  There 
are 5 vital signs... pulse, respirations, blood pressure (stored as 
systolic and diastolic)height and weight.  Now, generally all of these 
are collected everytime a patient comes in, but occasionally, they will 
have to be repeated on the same visit, for example, a repeat 
temperature, so they are all stored in separate objects.

The problem I have is trying to collect the data on the same page.  
Having to select "Save" after each data point entry is not workable. It 
just takes to long.  It means having a minimum of 6 mouse clicks just 
to store the vital signs.  So, I am trying to write a page template 
that will allow the collection of all the data on one page, then update 
the individual objects on submission...

I have figured out that the *_edit.cpt objects handle the data 
collection, and apparently the submission.  The resulting html page has 
the form being submitted back to the *_edit zpt... for example 
base_edit as an attribute of the object in question.  I think that the 
edit macros are using the widget.populate functions to populate the 
objects, but I can't find out how this function actually saves the 
data....

The code looks like :

tal:define =" visState....
		   edit_accessor python:field.getEditAccessor(here);
                       value python:widget.populate and edit_accessor 
and edit_accessor() or '';
		   value python:test(widget.postback and request.has_key(fileName), 
request.get(fieldName, value), value);
		   error_id....

Now, I am assuming the the postback function gets the data from html 
post function, and the populate function, writes the data to the 
object....  but I can't locate these two functions to see how the work, 
and I still haven't solved this problem....

I think that I should be able to use these functions to write the data 
to the relative objects... I thought that the edit_macros would do this 
automatically, as they are passed the appropriate objects, they get the 
accessor data, so I thought that they would write the field data to the 
appropriate objects.  But, _nothing_ happens.  here is the code I am 
using...

	<table cellpadding="0" cellspacing="0" border="1" width="100%">
	<tr tal:define = "global fileDict 
python:here.parentFolderObjsByType()">
	<td>
	    <span tal:repeat="object python:fileDict['Height']">
	    <b metal:use-macro="python:object.widget(object, 'Height', 
mode='edit')">content</b><br/>
	    </span>
	</td>
         </tr>
         </table>

This gives me the relevant object data on the page in edit mode, but 
when I save it, it is not saved.... parentFoldersObjsByType is an 
external method that I wrote, here it is....

def parentFolderObjsByType(self):

    """
    Creates a dicionary of lists of objects in the parent folder by 
meta_type.  This should be the name
    of the object as it appears in the 'allowed_content_types' in the 
archetypes definition, or the registerType name.

    Returns the dictionary of lists.
    """
    filelist = self.getFolderContents()
    fileDict = {}
    for object in filelist:

       typeName = (object.meta_type)

       fileDict.setdefault(typeName,[]).append(object)

    return fileDict



Can anyone help me with this?  Or give me a direction?


any help would be appreciated.

Michael


From os2mac at earthlink.net  Mon May 31 22:04:51 2004
From: os2mac at earthlink.net (Michael A Rowley)
Date: Mon May 31 22:04:01 2004
Subject: Fwd: [ZPT] writing data to zope objects
Message-ID: <11158562-B370-11D8-BF7E-000A95675988@earthlink.net>

Ok, this is driving me nuts!  I have fished through the source till I 
am almost cross eye'ed...  I can find no-where in the source calls 
where any reference to REQUEST is made to get the post data, or to any 
method to write the data to the objects... I have read the Formulator 
stuff, and am thinking it may be doing this automatically?  I have no 
idea how that is done....  But I think I can brute force this with 
something like

object.field=REQUEST[field_name] as long as all my field names are 
unique in my archetypes definitions...  I can write a validator to do 
this (I think).

I can't believe I am the first person to want to do this!  Someone with 
more experience at this than me must have visited this before.  I have 
literally been searching for a way to do this for months.  (To be fair, 
I have also been learning Python, archetypes, and zope also... It has 
been an uphill struggle.  I only started this in February...  that is 
why I really believe that there _must_ be a better way to do this...)

When looking through the code, this is the code path I get....

use-macro:"python:object.widget(object, fieldName, mode=mode)"

def widget(self, field_name, mode="view", **kwargs):
	widget=self.Schema()[field_name].widget
	return renderer.render(field_name, mode, widget, self, **kwargs)

class renderer:
	def render(self, field_name, mode, widget, instance=None, field=None, 
accessor=None, **kwargs):
         		if field is None:
             		field = instance.Schema()[field_name]

         		if accessor is None:
             		accessor = field.getAccessor(instance)

         		context = self.setupContext(field_name, mode, widget, 
instance, field, accessor, **kwargs)

         		result = widget(mode, instance, context)

         		del context
         		return result

	def setupContext(self, field_name, mode, widget, instance, field, 
accessor, **kwargs):
         		return {}

Now, I guess "result=widget(mode, instance, context) is calling the 
class widget in lib/python/generator/widget.py?  I still can't see 
where in this mess it is calling the edit macros, which I can find in 
Archetypes field/widget definitions...

What am I missing here?  Please help, for my sanity...

Michael.

Begin forwarded message:

> From: Michael A Rowley <os2mac@earthlink.net>
> Date: Mon May 31, 2004  2:21:44 PM US/Eastern
> To: Michael A Rowley <os2mac@earthlink.net>
> Subject: Re: [ZPT] writing data to zope objects
>
> Ok, more research, widget.postback, and widget.populate are simply 
> archetypes boolean variables.
>
> Now I am back at square one... How is the post information put into 
> the object?
>
> I am becoming unconvinced that an object database is better than a 
> relational db.  At least with a relational db I would know how to do 
> this :|
>
> M
>
> On Monday, May 31, 2004, at 01:12 PM, Michael A Rowley wrote:
>
>> hello all
>>
>> I am still battling this problem...  I have an application that 
>> records a lot of data from user input.  Much of this data is 
>> repetative, but stored independantly.  Specifically, vital signs on 
>> patients.  There are 5 vital signs... pulse, respirations, blood 
>> pressure (stored as systolic and diastolic)height and weight.  Now, 
>> generally all of these are collected everytime a patient comes in, 
>> but occasionally, they will have to be repeated on the same visit, 
>> for example, a repeat temperature, so they are all stored in separate 
>> objects.
>>
>> The problem I have is trying to collect the data on the same page.  
>> Having to select "Save" after each data point entry is not workable. 
>> It just takes to long.  It means having a minimum of 6 mouse clicks 
>> just to store the vital signs.  So, I am trying to write a page 
>> template that will allow the collection of all the data on one page, 
>> then update the individual objects on submission...
>>
>> I have figured out that the *_edit.cpt objects handle the data 
>> collection, and apparently the submission.  The resulting html page 
>> has the form being submitted back to the *_edit zpt... for example 
>> base_edit as an attribute of the object in question.  I think that 
>> the edit macros are using the widget.populate functions to populate 
>> the objects, but I can't find out how this function actually saves 
>> the data....
>>
>> The code looks like :
>>
>> tal:define =" visState....
>> 		   edit_accessor python:field.getEditAccessor(here);
>>                       value python:widget.populate and edit_accessor 
>> and edit_accessor() or '';
>> 		   value python:test(widget.postback and request.has_key(fileName), 
>> request.get(fieldName, value), value);
>> 		   error_id....
>>
>> Now, I am assuming the the postback function gets the data from html 
>> post function, and the populate function, writes the data to the 
>> object....  but I can't locate these two functions to see how the 
>> work, and I still haven't solved this problem....
>>
>> I think that I should be able to use these functions to write the 
>> data to the relative objects... I thought that the edit_macros would 
>> do this automatically, as they are passed the appropriate objects, 
>> they get the accessor data, so I thought that they would write the 
>> field data to the appropriate objects.  But, _nothing_ happens.  here 
>> is the code I am using...
>>
>> 	<table cellpadding="0" cellspacing="0" border="1" width="100%">
>> 	<tr tal:define = "global fileDict 
>> python:here.parentFolderObjsByType()">
>> 	<td>
>> 	    <span tal:repeat="object python:fileDict['Height']">
>> 	    <b metal:use-macro="python:object.widget(object, 'Height', 
>> mode='edit')">content</b><br/>
>> 	    </span>
>> 	</td>
>>         </tr>
>>         </table>
>>
>> This gives me the relevant object data on the page in edit mode, but 
>> when I save it, it is not saved.... parentFoldersObjsByType is an 
>> external method that I wrote, here it is....
>>
>> def parentFolderObjsByType(self):
>>
>>    """
>>    Creates a dicionary of lists of objects in the parent folder by 
>> meta_type.  This should be the name
>>    of the object as it appears in the 'allowed_content_types' in the 
>> archetypes definition, or the registerType name.
>>
>>    Returns the dictionary of lists.
>>    """
>>    filelist = self.getFolderContents()
>>    fileDict = {}
>>    for object in filelist:
>>
>>       typeName = (object.meta_type)
>>
>>       fileDict.setdefault(typeName,[]).append(object)
>>
>>    return fileDict
>>
>>
>>
>> Can anyone help me with this?  Or give me a direction?
>>
>>
>> any help would be appreciated.
>>
>> Michael