[Zope-dev] FS PageTemplates and XML generation issues
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I have some PT skins I'm using to generate XML responses and am getting
some strange behaviour. I'm not sure if its because I misunderstand
something, there are bugs, or the API could be made more useful.
I will focus this discussion around the following ZPT:
?xml version=1.0 encoding=UTF-8?
repomd xmlns=http://linux.duke.edu/metadata/repo;
~ data type=other tal:repeat=source here/objectValues
tal:attributes=type source/meta_type
~location href= tal:attributes=href string:repodata/${source/id}/
~checksum type=sha tal:content=source/checksum/
~timestamp tal:content=source/timestamp/
~open-checksum type=sha tal:content=source/open_checksum/
~ /data
/repomd
What is happening with this is that it's not doing any TAL rendering at
all and just returning this 'raw' xml. However, if I customise my skin
and assure the content-type is text/html, then it indeed renders this 'xml'.
I have experimented with the xmlns on this to no avail. Besides, it
surely must be implicit in the choice of making this a FSPT, that I am
anticipating TAL/METAL rendering, and that any non-(ME)TAL tags in the
raw text are to be passed thru to the client...
I am also concerned that the FSPT code has implicitly assumed that the
content type is text/xml. While I'd prefer this to be the type, at this
stage, this choice does not work ...
I would however have thought that in lieu of an explicit statement, any
FSPT would be of type text/html...
This brings me to my other question: how do I set the content-type on
an FSPT?? It would seem that content-type=xxx in the [default] section
of the .metadata file is ignored.
I'd someone to comment upon my observations before investigating further.
Alan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFByS4YCfroLk4EZpkRAk+pAKCZKz6swAiPjCASlYeTRNr1aayhjQCgqvMs
tAhtC2jRk9mOPsA3ObH3Ow0=
=/vDj
-END PGP SIGNATURE-
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] i18n:translate - problem
Bernd Dorn wrote: When I do .po files with the same domain, e.g: Domain: CMS\n and they have different Language-Code: header e.g: Language-Code: pl\n and Language-Code: en\n Zope chooses language based on web browser settings :(. When I'm setting xml:lang and lang attributtes it doesen't make effect. i suppose you need a manual lang switch on your site ... take a look at PlacelessTranslationService/Negotiator.py you can set a cookie called 'pts_language' ...or you can just write a negotiator that behaves the way you want. Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] FS PageTemplates and XML generation issues
Alan Milligan [EMAIL PROTECTED] wrote:
I have some PT skins I'm using to generate XML responses and am getting
some strange behaviour. I'm not sure if its because I misunderstand
something, there are bugs, or the API could be made more useful.
I will focus this discussion around the following ZPT:
?xml version=1.0 encoding=UTF-8?
repomd xmlns=http://linux.duke.edu/metadata/repo;
~ data type=other tal:repeat=source here/objectValues
tal:attributes=type source/meta_type
~location href= tal:attributes=href string:repodata/${source/id}/
~checksum type=sha tal:content=source/checksum/
~timestamp tal:content=source/timestamp/
~open-checksum type=sha tal:content=source/open_checksum/
~ /data
/repomd
What is happening with this is that it's not doing any TAL rendering at
all and just returning this 'raw' xml. However, if I customise my skin
and assure the content-type is text/html, then it indeed renders this 'xml'.
I have experimented with the xmlns on this to no avail. Besides, it
surely must be implicit in the choice of making this a FSPT, that I am
anticipating TAL/METAL rendering, and that any non-(ME)TAL tags in the
raw text are to be passed thru to the client...
ZPT will process tal instructions in XML templates only if the proper
namespace is declared. You must have:
xmlns:tal=http://xml.zope.org/namespaces/tal;
I am also concerned that the FSPT code has implicitly assumed that the
content type is text/xml. While I'd prefer this to be the type, at this
stage, this choice does not work ...
The ?xml start switches page template files to text/xml.
I would however have thought that in lieu of an explicit statement, any
FSPT would be of type text/html...
This brings me to my other question: how do I set the content-type on
an FSPT?? It would seem that content-type=xxx in the [default] section
of the .metadata file is ignored.
Use:
[default]
content_type = text/foobar
Florent
--
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] FS PageTemplates and XML generation issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Florent Guillaume wrote: | | ZPT will process tal instructions in XML templates only if the proper | namespace is declared. You must have: | | xmlns:tal=http://xml.zope.org/namespaces/tal; | Ok, I've explicitly included this now as well, and it behaves properly :) What is the rationale for this behaviour?? Is there any situation whereby I would NOT expect this namespace to be present implicitly?? If this were so, there'd be no dynamic content in my XML and I'd simply choose to store it on the ZODB as a File ... | Use: | | [default] | content_type = text/foobar No, this doesn't work either :( Regards, Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFByY6bCfroLk4EZpkRArjcAKC7XHjydBxHoaMdtignZfQ8zP3MLwCgieBP 3dDpu6TQ26k3Pcfiswg88A0= =ZeNO -END PGP SIGNATURE- ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] FS PageTemplates and XML generation issues
Alan Milligan wrote: | ZPT will process tal instructions in XML templates only if the proper | namespace is declared. You must have: | | xmlns:tal=http://xml.zope.org/namespaces/tal; | Ok, I've explicitly included this now as well, and it behaves properly :) What is the rationale for this behaviour?? Is there any situation whereby I would NOT expect this namespace to be present implicitly?? If this were so, there'd be no dynamic content in my XML and I'd simply choose to store it on the ZODB as a File ... You could possibly have pre-exising XML with another tal namespace used for something else. Declaring all namespaces in XML is pretty much the standard way of doing things anyway. | Use: | | [default] | content_type = text/foobar No, this doesn't work either :( Well it should, there are unit tests in CMFCore that explicitely test this kind of .metadata file. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] FS PageTemplates and XML generation issues
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Florent Guillaume wrote:
| | Use:
| |
| | [default]
| | content_type = text/foobar
|
| No, this doesn't work either :(
|
|
| Well it should, there are unit tests in CMFCore that explicitely test
| this kind of .metadata file.
|
No, I had a look and there's a strange test with a FSPT which explicitly
sets the REQUEST content-type. There's no test which checks this from a
.metadata file. There is a test which checks the title in a .properties
file.
I extended these tests (test_DirectoryView.py) and indeed setting
content_type as a property does pass the test. I also added a .metadata
test and it actually does pass this test too, although .metadata and
.properties files do appear mutually exclusive.
I've attached the patch of these tests if you want to apply it.
So, now I can't explain why my real-world .metadata content_type is
being ignored!
Cheers, Alan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFByaZvCfroLk4EZpkRAkibAKCOHPMge3kaoT9nqDJMiDnc75g2+wCfTjK1
aFEDZCvkqQ8oiCi+oFrD7sc=
=wgyp
-END PGP SIGNATURE-
diff -Naur tests.orig/fake_skins/fake_skin/testPT2.pt tests/fake_skins/fake_skin/testPT2.pt
--- tests.orig/fake_skins/fake_skin/testPT2.pt 1970-01-01 10:00:00.0 +1000
+++ tests/fake_skins/fake_skin/testPT2.pt 2004-12-23 03:45:59.000568152 +1100
@@ -0,0 +1 @@
+div tal:replace=request/SERVER_NAME /
\ No newline at end of file
diff -Naur tests.orig/fake_skins/fake_skin/testPT2.pt.metadata tests/fake_skins/fake_skin/testPT2.pt.metadata
--- tests.orig/fake_skins/fake_skin/testPT2.pt.metadata 1970-01-01 10:00:00.0 +1000
+++ tests/fake_skins/fake_skin/testPT2.pt.metadata 2004-12-23 03:40:28.149865104 +1100
@@ -0,0 +1,3 @@
+[default]
+title=Zope Pope
+content_type=text/foobar
diff -Naur tests.orig/test_DirectoryView.py tests/test_DirectoryView.py
--- tests.orig/test_DirectoryView.py 2004-12-23 03:31:18.220467080 +1100
+++ tests/test_DirectoryView.py 2004-12-23 03:47:10.077762776 +1100
@@ -123,6 +123,11 @@
Make sure the directory view is reading properties
self.assertEqual(self.ob.fake_skin.testPT.title, 'Zope Pope')
+def test_metadata(self):
+Make sure the directory view is reading properties
+ self.assertEqual(self.ob.fake_skin.testPT2.content_type, 'text/foobar')
+self.assertEqual(self.ob.fake_skin.testPT2.title, 'Zope Pope')
+
def test_ignored(self):
Test that the .test1.py is ignored
assert('#test1' not in self.ob.fake_skin.objectIds())
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] FS PageTemplates and XML generation issues
Alan Milligan wrote:
Florent Guillaume wrote:
| | Use:
| |
| | [default]
| | content_type = text/foobar
|
| No, this doesn't work either :(
|
|
| Well it should, there are unit tests in CMFCore that explicitely test
| this kind of .metadata file.
|
No, I had a look and there's a strange test with a FSPT which explicitly
sets the REQUEST content-type. There's no test which checks this from a
.metadata file. There is a test which checks the title in a .properties
file.
Ah sorry, the test is only on CMF 1.5 and HEAD. Not sure whether this
feature works on 1.4.
Florent
I extended these tests (test_DirectoryView.py) and indeed setting
content_type as a property does pass the test. I also added a .metadata
test and it actually does pass this test too, although .metadata and
.properties files do appear mutually exclusive.
I've attached the patch of these tests if you want to apply it.
So, now I can't explain why my real-world .metadata content_type is
being ignored!
Cheers, Alan
diff -Naur tests.orig/fake_skins/fake_skin/testPT2.pt
tests/fake_skins/fake_skin/testPT2.pt
--- tests.orig/fake_skins/fake_skin/testPT2.pt 1970-01-01
10:00:00.0 +1000
+++ tests/fake_skins/fake_skin/testPT2.pt 2004-12-23 03:45:59.000568152
+1100
@@ -0,0 +1 @@
+div tal:replace=request/SERVER_NAME /
\ No newline at end of file
diff -Naur tests.orig/fake_skins/fake_skin/testPT2.pt.metadata
tests/fake_skins/fake_skin/testPT2.pt.metadata
--- tests.orig/fake_skins/fake_skin/testPT2.pt.metadata 1970-01-01
10:00:00.0 +1000
+++ tests/fake_skins/fake_skin/testPT2.pt.metadata 2004-12-23
03:40:28.149865104 +1100
@@ -0,0 +1,3 @@
+[default]
+title=Zope Pope
+content_type=text/foobar
diff -Naur tests.orig/test_DirectoryView.py tests/test_DirectoryView.py
--- tests.orig/test_DirectoryView.py 2004-12-23 03:31:18.220467080 +1100
+++ tests/test_DirectoryView.py 2004-12-23 03:47:10.077762776 +1100
@@ -123,6 +123,11 @@
Make sure the directory view is reading properties
self.assertEqual(self.ob.fake_skin.testPT.title, 'Zope Pope')
+def test_metadata(self):
+Make sure the directory view is reading properties
+ self.assertEqual(self.ob.fake_skin.testPT2.content_type, 'text/foobar')
+self.assertEqual(self.ob.fake_skin.testPT2.title, 'Zope Pope')
+
def test_ignored(self):
Test that the .test1.py is ignored
assert('#test1' not in self.ob.fake_skin.objectIds())
--
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
