[ZPT] Editing templates not affecting templates thats use macros from it

Thu, 22 Aug 2002 13:02:26 -0400

It is indeed true that <p><div></div></p> is invalid html as <p> tags are=
=20
paragraph level (as are <h1-6>) and are allowed to contain only inline ta=
gs.

The parser sees the <div> following the <p> as an implicit close for the=20
paragraph (since closing tags are optional at the paragraph level and <di=
v>=20
is block level) resulting in it being interpreted as:

<p></p><div></div></p>

And it of course complains that the 2nd </p> at the end has no matching s=
tart=20
tag.

Getting this as a result of macro expansion is particularly evil. I think=
 it=20
warrants better documentation in a "ZPT gotchas" section in the Zope book=
=2E

-Casey

On Thursday 22 August 2002 09:03 am, Godefroid Chapelle wrote:
> At 21:15 21/08/2002, Clint Brubakken wrote:
> >If macros where expanded, it would gave me a tales error about </p> no=
t
> >matching the open tags. This same pt worked with the only macro, and t=
he
> >macro it self had no errors. The </p> it didn't like was the one of th=
e
> ><p></p> pair that surround the <span metal:fill-slot ...>...</span>.
> >
> >
> >I've even had pt's that display the new way, that when edited for othe=
r
> >reasons give me the tal error above.
>=20
> This looks like a wall I already have bumped.
>=20
> What I did not know is that the HTML parser checks for valid HTML=20
> constructs : for example it will refuse
> a <p><div>something</div></p> as it is invalid for HTML 4 (?).
>=20
> I am trying to infer from what you tell us above and have the feeling t=
hat=20
> you may be producing invalid HTML through the use of the metal slots. I=
OW=20
> can you check that you are not provoking situations like the refused I=20
> describe.
>=20
> I made some tests to check if this idea could be related to your proble=
m=20
> and found out what follows.
>=20
> It is easy to reproduce the following comportment :
>=20
> define two page templates with no macro expansion.
>=20
> 1) master  :
>=20
> <html metal:define-macro=3D"page">
>    <body>
>=20
>    <p><span metal:define-slot=3D"slot"/></p>
>=20
>    </body>
> </html>
>=20
> 2) user :
>=20
> <html metal:use-macro=3D"here/master/macros/page">
> <div metal:fill-slot=3D"slot">The slot</div>
> </html>
>=20
> If you do not expand, the rendering of user will work (no Zope error) a=
nd=20
> produces invalid (?) HTML :
>=20
> <html>
>    <body>
>=20
>    <p><div>The slot</div></p>
>=20
>    </body>
> </html>
>=20
>=20
> If you choose to expand macros in "user" page template, it gives you th=
e=20
> following back
>=20
>=20
> <html metal:use-macro=3D"here/master/macros/page">
>    <body>
>=20
> <p><div metal:fill-slot=3D"slot">The slot</div></p>
>=20
>    </body>
> </html>
>=20
> The rendering of "user" page template still works (no Zope error) and=20
> produces invalid (?) HTML.
>=20
> If later you save any changes to "user" page template, you receive the=20
> following error message:
>=20
> Compilation failed
> TAL.HTMLTALParser.NestingError: Open tags <html>, <body> do not match c=
lose=20
> tag </p>, at line 4, column 46
>=20
>=20
> !!!!!!!!! It is important to remark that the expansion alone do not=20
> generate any error message. !!!!!!!!!!
>=20
> To the community : is this something which should be added to the colle=
ctor=20
> as a bug ?
> IMHO yes, the comportment should be coherent and give an error when=20
expanding.
>=20
>=20
> --
>=20
> Godefroid Chapelle
>=20
> BubbleNet sprl
> rue Victor Horta, 18 / 202
> 1348 Louvain-la-Neuve
> Belgium
>=20
> Tel + 32 (10) 459901
> Mob + 32 (477) 363942
>=20
> TVA 467 093 008
> RC Niv 49849
>=20
>=20
> _______________________________________________
> ZPT mailing list
> ZPT@zope.org
> http://lists.zope.org/mailman/listinfo/zpt
>=20