Re: [Zope-dev] Re: stacks != easy to explain

2002-05-16 Thread Adrian Hungate

> >
> > Correct me if I am wrong, but isn't the TTW part is what is one of the
> > strenghts of Zope -
>
> Well, no, not really. Being able to edit stuff remotely is where Zope's
real strength
> lies. WebDAV and FTP are much better than using sucky HTTP forms to do
this ;-)

Babies. bathwater.

> > Just because ChrisW has gone beyond TTW editing, does not make it
> > a Bad Thing(tm) in general :)
>
> I challenge you to justify how editing in a text box is better than using
a full text
> editor, given that both can be used remotely ;-)

Hmm... now if I can only find an editor that is worth me spending my
valuable time trying to make it do what I want, instead of what it wants for
my code Or there are those nice little text boxes... they don't assume
they know better than me...

> > It seems that ZPT is mostly aimed at the Page Designer, whereas DTML is
> > mostly aimed at the Developer. Would this be a correct assesment of the
> > situation?
>
> DTML didn't have a clue who it was aimed at, which was it's main problem
;-)

Hmm... strange then that I have used (as have many others) it to produce
some very complex (And some think atractive and even elegant) sites. I had
always assumed it was aimed at people who wanted to design websites with
some server side inteligence - Seems a logical assumption, after all that is
what it allows.

> *grinz*
>
> Chris
>




___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] stacks != easy to explain

2002-05-16 Thread Don Hopkins

From: "Steve Alexander" <[EMAIL PROTECTED]>
Subject: Re: [Zope-dev] stacks != easy to explain


> > If you're using ordered attributes, then you're not using XML.
>
> Indeed, and if your indentation is meaningful in your C source-code,
> you're not using C.
>
> However, that doesn't negate the benefit of a consistent coding style.

Indentation style and the definition of XML are two different things.
The XML spec clearly states that attributes are defined as unordered.
So any XML editors or tool might rightfully reorder those attributes, thus
mangling the meaning of any so-called XML code that depends on attribute
order.
Any so-called XML tool that depends on the order of attributes incorrect,
and has a fundamental design flaw because it deviates from the agreed-upon
standard.
Just as any so-called C compiler that depends on indentation style is
incorrect.

-Don

Reference:

http://www.w3.org/TR/xml-infoset/

XML Information Set
W3C Recommendation 24 October 2001
2. Information Items
2.2. Element Information Items
An element information item has the following properties:
  5. [attributes] An unordered set of attribute information items, one for
each of the attributes (specified or defaulted from the DTD) of this
element. Namespace declarations do not appear in this set. If the element
has no attributes, this set has no members.




___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] stacks != easy to explain

2002-05-16 Thread Chris Withers

Don Hopkins wrote:
> 
> Indentation style and the definition of XML are two different things.
> The XML spec clearly states that attributes are defined as unordered.
> So any XML editors or tool might rightfully reorder those attributes, thus
> mangling the meaning of any so-called XML code that depends on attribute
> order.
> Any so-called XML tool that depends on the order of attributes incorrect,
> and has a fundamental design flaw because it deviates from the agreed-upon
> standard.
> Just as any so-called C compiler that depends on indentation style is
> incorrect.

...which is precisely why the order of attributes in ZPT source code doesn't matter and
why the order of execution of attributes is rigidly defined by ZPT, rather than being 
that
of their order in the source.

Anyone got a spare Dime Bar?

Chris

> Reference:

...no one cares.


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] stacks != easy to explain

2002-05-16 Thread Eron Lloyd

I believe what is trying to be explained is that ZPT provides a certain
sequence for attribute *processing*, which begins *after* the template
is parsed (like unordered keyword arguments in Python). How they are
ordered in the source file is irrelevant, but by ordering them in the
precise way they will be processed is recommended to aid in the
understanding of what will happen.

If you do see a concrete example of how and where this occurs that
coincides with a breach from the XML spec, please post this to the list
for us to see, so that the proper avenues of discussion, hacking, and
problem resolution can be made. ZPT is nowhere near complete, and will
surely tighten up with time.

Regards,

Eron

On Thu, 2002-05-16 at 10:32, Don Hopkins wrote:
> From: "Steve Alexander" <[EMAIL PROTECTED]>
> Subject: Re: [Zope-dev] stacks != easy to explain
> 
> 
> > > If you're using ordered attributes, then you're not using XML.
> >
> > Indeed, and if your indentation is meaningful in your C source-code,
> > you're not using C.
> >
> > However, that doesn't negate the benefit of a consistent coding style.
> 
> Indentation style and the definition of XML are two different things.
> The XML spec clearly states that attributes are defined as unordered.
> So any XML editors or tool might rightfully reorder those attributes, thus
> mangling the meaning of any so-called XML code that depends on attribute
> order.
> Any so-called XML tool that depends on the order of attributes incorrect,
> and has a fundamental design flaw because it deviates from the agreed-upon
> standard.
> Just as any so-called C compiler that depends on indentation style is
> incorrect.
> 
> -Don
> 
> Reference:
> 
> http://www.w3.org/TR/xml-infoset/
> 
> XML Information Set
> W3C Recommendation 24 October 2001
> 2. Information Items
> 2.2. Element Information Items
> An element information item has the following properties:
>   5. [attributes] An unordered set of attribute information items, one for
> each of the attributes (specified or defaulted from the DTD) of this
> element. Namespace declarations do not appear in this set. If the element
> has no attributes, this set has no members.
> 
> 
> 
> 
> ___
> Zope-Dev maillist  -  [EMAIL PROTECTED]
> http://lists.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  **
> (Related lists - 
>  http://lists.zope.org/mailman/listinfo/zope-announce
>  http://lists.zope.org/mailman/listinfo/zope )
> ---
> [This E-mail scanned for viruses by Declude Virus]
> 
> 


---
[This E-mail scanned for viruses by Declude Virus]



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] stacks != easy to explain

2002-05-16 Thread Nicola Larosa

[Lots of Cc: deleted]


My turn...


> So any XML editors or tool might rightfully reorder those attributes, thus
> mangling the meaning of any so-called XML code that depends on attribute
> order.

The so-called XML code does *not* depend on attribute order.


> Any so-called XML tool that depends on the order of attributes incorrect,
> and has a fundamental design flaw because it deviates from the agreed-upon
> standard.

The so-called XML code does *not* depend on attribute order.

The so-called XML code evaluates attributes in a prespecified order, 
whatever the attribute order in the so-called XML code itself.


> Just as any so-called C compiler that depends on indentation style is
> incorrect.

That's why it's so-called Python. ;^)


-- 
Two witches watch two watches. Which witch watched which watch?

Nicola Larosa - [EMAIL PROTECTED]



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Re: References to hypertext templating languages

2002-05-16 Thread Nicola Larosa

[Lots of Cc: deleted...]


> Hello?! How much stuff... sorry, I didn't even read it

You should have, it's interesting stuff, better not dismissing it so lightly.


-- 
Two witches watch two watches. Which witch watched which watch?

Nicola Larosa - [EMAIL PROTECTED]



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] References to hypertext templating languages

2002-05-16 Thread Ken Manheimer

Don, it sounds like HyperTIES Markup Language addresses some similar
purposes in similar ways to Zope Page Templates.  There are also some
significant differences, which may interest you.  ZPT has some
distinctive features particularly aimed to promote ease of collaboration 
between web designers and programmers (or between those two sides of a 
developer, working with themselves.-)

Chief among those features is use of tag attributes for computation hookup
- variable access, conditionals, loops, method invocation, etc. By using
tags on standard XHTML, the results of adapting a page for hookup with the
rest of the application retains the structure and parsability that the
designers originally created.  The original structure is preserved, and
conversely, typical design tools preserve foreign tags (generally,
ignoring them, maybe even colorizing them distinctively), so we avoid
disruption in both directions.

(It's a pleasure to be able, as a programmer, to take designer's markup
and add the right tags, capitalizing on their designs without disrupting
them - and to be able to trade the result back and forth, evolving it
without having to retrofit changes again and again.  I've done this, on 
customer projects, and was **not** able to do so when we were using DTML.)

The issue about "order of tags" seems to be a misunderstanding - the
order being described was order of _execution_ - precedence of the
tags, to serve the programmers purpose.  For more information, see the
TAL (Template Attribute Language) specification:

  http://dev.zope.org/Wikis/DevSite/Projects/ZPT/TAL%20Specification%201.4

The discussion about "procedural versus templating language" may be based
on misuse of terms.  I think the issue is block-structured versus
page/layout markup.

It's common to see templating languages that hookup to underlying
programming logic by interspersing block-structured code with page-layout
directives.  Both in principle and as someone who has used a few of these
systems, i think they're fatally flawed for anything more than simple
layouts. I know that we *can* accomplish elaborate layouts with such
systems - god knows, i've done so.  I'm just saying they're unnecessarily
hard to unravel, change, and debug - because of an "impedence mismatch",
where the structuring of one syntax does not obey the structuring of the
other.

(Recently i posted something equating this intermixing of structural
boundaries with undisciplined use of goto in a high-level language - both
defeat many of the benefits of clean structuring.  This sort of thing is
especially galling, eg in DTML, to those of us that came to Zope with an
appreciation of Python for its tendency to exceptionally readable,
comprehensible code.  I also like lisp, particularly for its elementary
syntax and susceptibility to programmatic manipulation, but have been won
over beyond lisp by python's economies...)

Using XML for your language, as i gather HyperTIES does, avoids the
structural disruptions, since XML is strict and consistent with HTML.  By
sticking with HTML, however, we also leverage pervasive expertise - at
least being able to use the efforts of the numerous folk familiar with
HTML, and in some cases enabling them to do various levels of their own
programming hookup with ZPT.

There may seem to be ways we restrict our templating language by using
HTML, and in some ways, that's right.  In fact, that's another, very
important benefit, here.

The Zope environment provides numerous ways to express elaborate
business logic, ways that are much easier to read and process than any
markup-oriented language can provide.  (These ways include things like
web-editable python scripts, standalone "external" methods, and
product methods, as well as SQL methods and so forth.)  Markup is best
used for presentation - the only procedural logic we want in our
templates should be presentation specific, or calls out to tap the
results of the application business logic, underneath.

Conversely, the business logic should not have to produce presentation -
just provide the fodder for it.

ZPT sits in this balance, very nicely i think.

I haven't been following the conversation very carefully, so don't
know whether or not you've gotten acquainted with ZPT - the canonical
place is:

  http://dev.zope.org/Wikis/DevSite/Projects/ZPT

Considering the approach of HyperTIES, you may find a lot to like
there.

-- 
Ken Manheimer
[EMAIL PROTECTED]




___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )