date:20050901

On Thursday 01 September 2005 16:42, Garanin Michael wrote:
> Sorry, but i can not found "package-includes" in the
> http://svn.zope.org/Zope3/trunk/ . Is it normal?

Oh, and by the way, do not add ZCML files manually. Add a SETUP.cfg that adds 
the ZCML file.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] package-includes

On Thursday 01 September 2005 16:42, Garanin Michael wrote:
> Sorry, but i can not found "package-includes" in the
> http://svn.zope.org/Zope3/trunk/ . Is it normal?

Yes, its in zopeskel/etc/ these days.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Should major for-reaching changes be made for purposes of style?

2005-09-01 Thread Dieter Maurer

Jim Fulton wrote at 2005-8-31 17:05 -0400:
> ...
>I'm interested in hearing what people think about this in general.
>Should we make far reaching code changes to enforce a consistent
>style?  Or should we update style when making other changes?
>I tend to do the later.  I think that the developers of Python
>prefer that changes like this be made more gradually. They've
>been burned by mass changes in the past.
>
>Thoughts?

I am not very concerned about style (in foreign code).
Well chosen "speaking" names are much more important
than style aspects.

Consequently, I would make style changes gradually (if at all).

-- 
Dieter
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] package-includes

2005-09-01 Thread Garanin Michael

  
Hello!
Sorry, but i can not found "package-includes" in the
http://svn.zope.org/Zope3/trunk/ . Is it normal? 

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: XML header and TAL interpretor

2005-09-01 Thread Andreas Reuleaux

On Thu, Sep 01, 2005 at 06:58:42PM +0200, Tonico Strasser wrote:
> ... 
> What's your point?

Well, from reading your conversation with Philipp I got the
impression, that you wanted to say something like
"XML-Mode in PTs respectively XHTML is useless if served with
the wrong MIME type" --- You did not use the term "useless"
so I might have overinterpreted what you wrote, sorry for that.

Fact is, that XML-Mode in PTs / XHTML is *not* made useless
by any MIME-Type, the MIME-Type application/xhtml+xml 
is just another way of assuring your XHTML is correct.
Basically you are free to choose any method that helps
you write valid XHTML pages:

* that can be Zope's XML-Mode for PTs
* that can just as well be external validation
* or that can be the browser, that is unforgiving
  if serverd application/xhtml+xml

But if your XHTML is valid (e. g. if you have checked your page at
validator.w3.org) then application/xhtml+xml won't show you any
additional otherwise hidden mistakes.

The onliest thing that can make your XHTML useless is doctype
switching, say a wrong doctype or a bug that causes IE to go into
quirks mode (mentioned before).

-Andreas

PS: I have also just read your second answer to my E-mail and
I am glad you could make some sense of it.
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Atomic reads w ZEO and ZODB

2005-09-01 Thread David Huttleston Jr

On Wed, Aug 31, 2005 at 09:19:43PM -0400, Gary Poster wrote:
> 
> On Aug 31, 2005, at 12:07 PM, David Huttleston Jr wrote:
> ...
> >But, I'm fuzzy on how the zodb prevents inconsistent reads.
> ...
> 
> Hi David.  A quick answer is that the ZODB implements optimistic  
> multi-version concurrency control, similar to the default PostgreSQL  
> behavior.  This link describes the proposal, which is pretty close to  
> the way it turned out, as far as I know.
> 
> http://www.zope.org/Wikis/ZODB/MultiVersionConcurrencyControl

Thanks for your time, Gary.  This is what I needed to see.

Dave
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: XML header and TAL interpretor


Andreas Reuleaux schrieb:

On Thu, Sep 01, 2005 at 11:44:48AM +0200, Tonico Strasser wrote:


...
And, as long pages are served as text/html they are treated as old-style
HTML by browsers anyway[1].

XHTML pages served as text/html must follow the compatibility
guidelines[2]. E.g. in ZPT HTML mode, elements like  will be
converted to  automagically (with space before the slash). That is
a good thing IMHO.

[1] Serving XHTML 1.0


[2] HTML Compatibility Guidelines


Tonico
...



Tonico, I think you misunderstood something: While it is true that
pages served as text/html are treated as HTML by browsers,
there are still quite some differences how they treat the HTML,
i. e. in which mode they operate (doctype switching).


After rereading your posting, I think I understand what you mean. If you 
serve a XHTML page as text/html, a browser will treat this page as 
HTML4.x *not* XHTML. I'm not talking about browser rendering modes. 
That's why pages served as text/html should follow the XHTML 
compatibility guidelines, I think.


You can test this, create a HTML page and insert a document.write with 
JavaScript somewhere. You will notice, that it does not work in pages 
served as application/xhtml+xml. (You must use a browser which 
understands XHTML e.g. Mozilla, Opera or Konqueror).


Why document.write() doesn't work in XML
http://ln.hixie.ch/?start=1091626816&count=1

Tonico

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: XML header and TAL interpretor

2005-09-01 Thread Sidnei da Silva

On Thu, Sep 01, 2005 at 11:56:59AM -0400, Derrick Hudson wrote:
| The ZPT processor/renderer shouldn't dictate this as it is clear that
| ZPTs can be used to create a wide variety of types of content.
| 
| I think the content-type sent to the browser should be controlled by
| the  directive.  The HTTP content-type is really part of
| the browser interaction and not necessarily part of the template
| processing.   could default to text/html or text/xml or
| whatever people decide is the most commonly desired type and include
| an attribute to override it.
| 
| Hypothetically speaking, because I don't have any relevant experience
| to support this, a different type of view may want to use the same ZPT
| with a different content-type.  Maybe the XML-RPC or WebDAV publishers
| have different constraints and want to send application/xhtml+xml for
| a given template while the browser publisher must degrade it to
| text/html for IE.

That smells to me like we need a mime-type negotiator or something,
pretty much like we have a language negotiator for deciding which
language to use for translations.

-- 
Sidnei da Silva
Enfold Systems, LLC.
http://enfoldsystems.com


signature.asc
Description: Digital signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: XML header and TAL interpretor


Andreas Reuleaux schrieb:

On Thu, Sep 01, 2005 at 11:44:48AM +0200, Tonico Strasser wrote:


...
And, as long pages are served as text/html they are treated as old-style
HTML by browsers anyway[1].

XHTML pages served as text/html must follow the compatibility
guidelines[2]. E.g. in ZPT HTML mode, elements like  will be
converted to  automagically (with space before the slash). That is
a good thing IMHO.

[1] Serving XHTML 1.0


[2] HTML Compatibility Guidelines


Tonico
...



Tonico, I think you misunderstood something: While it is true that
pages served as text/html are treated as HTML by browsers,
there are still quite some differences how they treat the HTML,
i. e. in which mode they operate (doctype switching).


I know.


Serving pages as text/html just makes the browser more forgiving.
E. g. a plain  tag won't normally be flagged as an error, while in
application/xhtml+xml it will be flagged as an error by the browser
(and Mozilla/Gecko does so). IE does not understand
application/xhtml+xml, so this is only a choice for intranets without
IE right now. For the Internet there is currently no choice but text/html
(maybe negotiating the MIME type depending on the browser).


Ok.


Also there is nothing wrong with serving XHTML as text/html (except
that you are missing some browser error messages - if you want to make
sure your XHTML is correct, you can always rely on external
validation, see below)


Ok.


Still - and that is my point - even IE (that only understands
text/html) has different modes of operation (basically standards mode
and quirks mode), triggerd by doctype switching.


What's your point?


If you want to use XHTML and make sure that that XHTML is correct,
this is what you can do:

  (1) rely on the zope machinery to find possible mistakes: XML-mode
  is not as forgiving as HTML-Mode for page templates - and I
  think that is a good thing, and therefore I am also in favor of
  making XML-Mode the default (+1).

  Be aware though that even in HTML-Mode you can currently write
  perfectly valid XHTML pages - you are just loosing Zope's
  ability to detect XHTML errors.

  (2) rely on external validation: html://validator.w3.org
  this should probably be done much more often anyways

  (3) rely on the browser to flag errors
  e. g. Mozilla/Gecko in application/xhtml+xml, NOT possible
  in IE.



I do the same :)
http://mail.zope.org/pipermail/zpt/2004-July/005387.html


Beware: this is all about what input is accepted as valid XHTML,
interpreting the input as XHTML is the next step: normally you want
that XHTML to be interpreted in standards mode (that's why you wrote
XHTML in the first place) and you tell the browser by doctype
switching.

Philipp: If XML-Mode is the default, and therefore no xml-declaration
is needed (and the aforementioned unfortunate IE bug is therefore
circumvented) how would one toggle on HTML-Mode? - Am I missing
something? The situation right now is
  xml-declaration -> XML-Mode
  no xml-declaration -> HTML-Mode
HTML mode might still be needed in some situations (Fred gave some
examples)



Tonico

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: RDFLib and Zope 3

2005-09-01 Thread Daniel Krech



On Sep 1, 2005, at 11:00 AM, Florent Guillaume wrote:


Gary Poster wrote:


On Aug 23, 2005, at 8:07 PM, Michel Pelletier wrote:


On Tue, 2005-08-23 at 18:04 -0400, Gary Poster wrote:




The relationship between ZODB content objects, their int id as
provided by the pertinent intid utility, and a (theoretical)
corresponding RDF URI is what I'm having a hard time not making  
hacky

in my mind.  I'll think about it some more.




They might not be that hacky, this might be the wrong direction  
to  take

but URI's don't have to be visually meaningful, blank nodes, for
example, are usually just '_:' concatenated to a random opaque  
string.
If the URI were 'zope:' (maybe path/to/intid/ 
util:)  that

would work just as well, it would also be trival to transform into a
feasible join key if the URI was also a URL that looked up,  
instead of

some network resource, an intid.

Actually being able to trivially transform an intid to an rdflib URI
might be something to think about.  Thinking about it more, the   
current
Zemantic uses the physical path of the object as the rdf:about=""  
URI
when an object adds itself, because honestly I could think of no  
other
URI in Zope.  This is obviously wrong, but I didn't have a  
better  answer
in paris.  Why not use the `intid` plus some URI sugar?  If the  
URI  and
the intid can be easily converted from one to the other then  
that  should

solve the whole problem, no?



Here's another way to work with intids that I think could work:

In rdflib in some backends like IOMemory, and internal id is found  
for a subject (or predicate or object) to use in the internal  
storage datastructures. rdflib uses some randid() for that.


I propose that instead of calling randid(), it called self.assignid 
(subject) which would be pluggable. By default this would be the  
default randid, but you could allow Zope to create a graph with an  
assignid that assigned ids based on the intid service.


This should definitely work for BNodes and think it can work for  
URIRef and Literals (will just need a second to think about it). I'll  
definitely keep this in mind as we're formalizing the interfaces with  
zope.interface -- which hopefully we can get a first cut done this  
weekend.


Then if a subject or object passed to rdflib is an integer instead  
of a URI, it would be used directly. In effect you'd give access to  
the internal ids.


(There are more details to solve (assignid needs to check for  
collisions sometimes), but I think that's a good starting point).


I agree. We'll give it a go.


Florent

--
Florent Guillaume, Nuxeo (Paris, France)   CTO, Director of R&D
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]



Daniel Krech, http://eikeon.com/

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: XML header and TAL interpretor


Derrick Hudson schrieb:

On Thu, Sep 01, 2005 at 05:00:37PM +0200, Tonico Strasser wrote:
| Philipp von Weitershausen schrieb:
| >>>Ah, good. It wasn't at all clear that you actually supported the
| >>>proposal :).
| >>
| >>Yes, if it's still possible to trigger HTML mode. But what about
| >>backwards compatibility if we make XML the default mode?
| >
| >Well, the namespace stuff would probably account for a major breakage.
| >Thus, over the span of two Zope releases, XML mode could be forgiveful
| >when people forget to register namespace declarations. Of course, it
| >would render deprecation warnings.
| >
| >I can't imagine a smooth transition for the other "features" of HTML
| >mode because they are like on/off switches. Either you convert  to
| > or you don't. Same with  vs. 
| >and the other things.
| 
| I ask because I don't know: if I serve a ZPT page in Zope 3 in XML mode, 
| which mime type is sent to the browser? Is this independent of the ZTP 
| XML/HTML mode?


As I just stated in the other subthread, I believe the HTTP
Content-Type is (should be) independent of the "mode" the ZPT
machinery uses to process the template.  The  directive
or some other suitable explicit configuration should control the
browser-specific items like content-type.  I suppose maybe the
publisher could add its two sense and handle IE and Mozilla
differently presenting a facade to IE so it doesn't trip over itself
and presenting the more-correct-by-the-spec information to Mozilla.


FWIW: I just tried it out: If I change the content_type in 
pagetemplate.py line 61 to 'text/xml' the default mode in page templates 
changes to XML and they are served as, you guessed it, text/xml by default.


Tonico

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: XML header and TAL interpretor

2005-09-01 Thread Andreas Reuleaux

On Thu, Sep 01, 2005 at 11:44:48AM +0200, Tonico Strasser wrote:
> ...
> And, as long pages are served as text/html they are treated as old-style
> HTML by browsers anyway[1].
>
> XHTML pages served as text/html must follow the compatibility
> guidelines[2]. E.g. in ZPT HTML mode, elements like  will be
> converted to  automagically (with space before the slash). That is
> a good thing IMHO.
>
> [1] Serving XHTML 1.0
> 
>
> [2] HTML Compatibility Guidelines
> 
>
> Tonico
> ...

Tonico, I think you misunderstood something: While it is true that
pages served as text/html are treated as HTML by browsers,
there are still quite some differences how they treat the HTML,
i. e. in which mode they operate (doctype switching).

Serving pages as text/html just makes the browser more forgiving.
E. g. a plain  tag won't normally be flagged as an error, while in
application/xhtml+xml it will be flagged as an error by the browser
(and Mozilla/Gecko does so). IE does not understand
application/xhtml+xml, so this is only a choice for intranets without
IE right now. For the Internet there is currently no choice but text/html
(maybe negotiating the MIME type depending on the browser).

Also there is nothing wrong with serving XHTML as text/html (except
that you are missing some browser error messages - if you want to make
sure your XHTML is correct, you can always rely on external
validation, see below)

Still - and that is my point - even IE (that only understands
text/html) has different modes of operation (basically standards mode
and quirks mode), triggerd by doctype switching.

If you want to use XHTML and make sure that that XHTML is correct,
this is what you can do:

  (1) rely on the zope machinery to find possible mistakes: XML-mode
  is not as forgiving as HTML-Mode for page templates - and I
  think that is a good thing, and therefore I am also in favor of
  making XML-Mode the default (+1).

  Be aware though that even in HTML-Mode you can currently write
  perfectly valid XHTML pages - you are just loosing Zope's
  ability to detect XHTML errors.

  (2) rely on external validation: html://validator.w3.org
  this should probably be done much more often anyways

  (3) rely on the browser to flag errors
  e. g. Mozilla/Gecko in application/xhtml+xml, NOT possible
  in IE.

Beware: this is all about what input is accepted as valid XHTML,
interpreting the input as XHTML is the next step: normally you want
that XHTML to be interpreted in standards mode (that's why you wrote
XHTML in the first place) and you tell the browser by doctype
switching.

Philipp: If XML-Mode is the default, and therefore no xml-declaration
is needed (and the aforementioned unfortunate IE bug is therefore
circumvented) how would one toggle on HTML-Mode? - Am I missing
something? The situation right now is
  xml-declaration -> XML-Mode
  no xml-declaration -> HTML-Mode
HTML mode might still be needed in some situations (Fred gave some
examples)

-Andreas
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: XML header and TAL interpretor

2005-09-01 Thread Florent Guillaume


Philipp von Weitershausen wrote:

Julien Anguenot wrote:


I got a problem with the standard macros use and the XML header.

I've a view defined like the one below :


http://xml.zope.org/namespaces/tal";
   xmlns:metal="http://xml.zope.org/namespaces/metal";

 
   
 


And there, I got the following error when Zope's trying to render it :
[snip]
   (`macroName`, `mode`), self.position)
METALError: macro u'context/@@standard_macros/page' has incompatible
mode 'html', at line 6, column 3

If I remove the xml header the error disappears.



It sucks, don't it?



Has anyone tried removing the macro mode check (in 
TALIntepreter.do_userMacro)? What would break?
At least I think it wouldn't be a problem to allow inclusing of a XML macro 
in an HTML slot (or maybe the other way round -- I guess one of them works, 
as one is always stricter than the other).


Florent

--
Florent Guillaume, Nuxeo (Paris, France)   CTO, Director of R&D
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: XML header and TAL interpretor

2005-09-01 Thread Derrick Hudson

On Thu, Sep 01, 2005 at 05:00:37PM +0200, Tonico Strasser wrote:
| Philipp von Weitershausen schrieb:
| >>>Ah, good. It wasn't at all clear that you actually supported the
| >>>proposal :).
| >>
| >>Yes, if it's still possible to trigger HTML mode. But what about
| >>backwards compatibility if we make XML the default mode?
| >
| >Well, the namespace stuff would probably account for a major breakage.
| >Thus, over the span of two Zope releases, XML mode could be forgiveful
| >when people forget to register namespace declarations. Of course, it
| >would render deprecation warnings.
| >
| >I can't imagine a smooth transition for the other "features" of HTML
| >mode because they are like on/off switches. Either you convert  to
| > or you don't. Same with  vs. 
| >and the other things.
| 
| I ask because I don't know: if I serve a ZPT page in Zope 3 in XML mode, 
| which mime type is sent to the browser? Is this independent of the ZTP 
| XML/HTML mode?

As I just stated in the other subthread, I believe the HTTP
Content-Type is (should be) independent of the "mode" the ZPT
machinery uses to process the template.  The  directive
or some other suitable explicit configuration should control the
browser-specific items like content-type.  I suppose maybe the
publisher could add its two sense and handle IE and Mozilla
differently presenting a facade to IE so it doesn't trip over itself
and presenting the more-correct-by-the-spec information to Mozilla.

-D

-- 
If you want to know what God thinks about money,
just look at the people He gives it to.
-- Old Irish Saying
 
www: http://dman13.dyndns.org/~dman/jabber: [EMAIL PROTECTED]


signature.asc
Description: Digital signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: XML header and TAL interpretor

2005-09-01 Thread Derrick Hudson

On Thu, Sep 01, 2005 at 04:20:08PM +0200, Tonico Strasser wrote:
| Philipp von Weitershausen schrieb:
| >Tonico Strasser wrote:
| >>Philipp von Weitershausen schrieb:
| >>>Tonico Strasser wrote:
| Philipp von Weitershausen schrieb:
| 
| >If we make XML the default mode, I don't see how it would
| >impact IE very much.
| 
| IE would try to dowload HTML pages not served as text/html.
| Pages in XML mode should be served as XML not text/html.

[...]

| >The point of all this is that text/xml just isn't enough. It's a good
| >fallback, but it's not enough, especially including serving HTML. From
| >that I conclude that the "should" in your sentence above is wrong.
| 
| And to which media type should ZPTs in XML mode default to?

The ZPT processor/renderer shouldn't dictate this as it is clear that
ZPTs can be used to create a wide variety of types of content.

I think the content-type sent to the browser should be controlled by
the  directive.  The HTTP content-type is really part of
the browser interaction and not necessarily part of the template
processing.   could default to text/html or text/xml or
whatever people decide is the most commonly desired type and include
an attribute to override it.

Hypothetically speaking, because I don't have any relevant experience
to support this, a different type of view may want to use the same ZPT
with a different content-type.  Maybe the XML-RPC or WebDAV publishers
have different constraints and want to send application/xhtml+xml for
a given template while the browser publisher must degrade it to
text/html for IE.

-D

-- 
If you want to know what God thinks about money,
just look at the people He gives it to.
-- Old Irish Saying
 
www: http://dman13.dyndns.org/~dman/jabber: [EMAIL PROTECTED]


signature.asc
Description: Digital signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: XML header and TAL interpretor

2005-09-01 Thread Derrick Hudson

On Thu, Sep 01, 2005 at 02:33:19PM +0200, Philipp von Weitershausen wrote:
| Derrick Hudson wrote:
| > On Wed, Aug 31, 2005 at 03:54:45PM +0200, Philipp von Weitershausen wrote:
| > | Julien Anguenot wrote:
| > [...]
| > 
| > | > If you change the header like this then it can be succesfully included :
| > | > 
| > | > 
| > | > http://www.w3.org/1999/xhtml";
| > | >   xmlns:tal="http://xml.zope.org/namespaces/tal";
| > | >   xmlns:metal="http://xml.zope.org/namespaces/metal";
| > | >   xmlns:i18n="http://xml.zope.org/namespaces/i18n";
| > | >   i18n:domain="zope">
| > | > 
| > | > 
| > | > What kind of issue could we have changing the headers like this on all
| > | > the standard macros since it's xhtml already ?
| > | 
| > | I'm not sure if this is a good idea. Because once Zope3's macros are XML
| > | mode, all other templates using those macros need to be XML mode. That,
| > | in turn, means that all templates need to carry the 
| > | processing instruction because that's the only way XML mode is currently
| > | triggered. Since that processing instruction is optional (as opposed to
| > | namespace declarations which are mandatory), I wouldn't want to force it
| > | on template authors.
| > 
| > Don't forget that IE will then have an insane tendency to render the
| > pages wrong.  I don't recall all of the details, but it was something
| > like if the document began with  IE would switch to "quirks
| > mode" and do funny things with boxes, margins, and the overall layout.
| > The details are in this list's archives (if they aren't it's in the
| > zope@zope.org list archives).
| 
| I know about quirks mode and how it's provoked with .

Ok.

| Exactly because of that it has been impossible to use ZPT's XML mode to
| render web pages -- because IE will choke on the  that is
| necessary to put the ZPT machinery into XML in the first place... a
| vicious circle so to speak.

Yeah.  Earlier in this subthread (quoted above) the question was asked
if leaving the ZPT processing untouched and putting  in every
template would have negative side effects.  I didn't want this one to
be forgotten.

| If we make XML the default mode, I don't see how it would impact IE very
| much. After all, the  processing instruction would then be
| optional and could be left out for XHTML pages. It would finally be
| possible to properly embed XForms, SVG etc. into XHTML though.

Right.  The logic ZPT uses to render the content doesn't have to
dictate the content-type or any processing instructions in the
resulting output.

As I noted in a different post I am in favor of changing the
processing logic to "XML Mode".

-D

-- 
UNIX is basically a simple operating system,
but you have to be a genius to understand the simplicity.
   -- Dennis Ritchie
 
www: http://dman13.dyndns.org/~dman/jabber: [EMAIL PROTECTED]


signature.asc
Description: Digital signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: XML header and TAL interpretor

2005-09-01 Thread Julien Anguenot

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Philipp von Weitershausen wrote:
> Julien Anguenot wrote:
> 
I think it's time to sketch out a proposal :).
>>
>>+1 Do you want to write it ?
> 
> 
> I can start, then you, Tonica and others can pad it out in the wiki.
>

yup. works for me.

J.

- --
Julien Anguenot | Nuxeo R&D (Paris, France)
CPS Platform : http://www.cps-project.org
Zope3 / ECM   : http://www.z3lab.org
mail: anguenot at nuxeo.com; tel: +33 (0) 6 72 57 57 66
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFDFx10GhoG8MxZ/pIRAqKwAJ95QKmQGoDLz0usZGBAvWvA5njCywCdGfgQ
E7nmIefcahkOdBpuTfgWT6k=
=1VUF
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: file objects and formlib

2005-09-01 Thread Florent Guillaume


Martijn Faassen wrote: [quotes reordered]
  - for an add form, if something goes wrong and the form is redisplayed 
with some validation errors, the uploaded file information is lost. This 
is bad because for a required file field, it requires multiple uploads 
where one should suffice, and for a non-required file field, it's even 
worse, as a user would have no motivation to re-upload the same file 
after validation failure and redisplay of the form, resulting in no file 
being uploaded at all.

>
> I've already solved [this] problem by storing
> files in a session temporarily. This isn't efficient, but I *also*
> developed something that will lick that problem and that I'll present in
> a lightning talk at the Plone conference.

Yes that's a generic HTTP problem, and you *have* to use some kind of 
session to deal with it. There's no way around.


Florent

--
Florent Guillaume, Nuxeo (Paris, France)   CTO, Director of R&D
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: XML header and TAL interpretor


Philipp von Weitershausen schrieb:

Ah, good. It wasn't at all clear that you actually supported the
proposal :).


Yes, if it's still possible to trigger HTML mode. But what about
backwards compatibility if we make XML the default mode?



Well, the namespace stuff would probably account for a major breakage.
Thus, over the span of two Zope releases, XML mode could be forgiveful
when people forget to register namespace declarations. Of course, it
would render deprecation warnings.

I can't imagine a smooth transition for the other "features" of HTML
mode because they are like on/off switches. Either you convert  to
 or you don't. Same with  vs. 
and the other things.


I ask because I don't know: if I serve a ZPT page in Zope 3 in XML mode, 
which mime type is sent to the browser? Is this independent of the ZTP 
XML/HTML mode?


Tonico

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: RDFLib and Zope 3

2005-09-01 Thread Florent Guillaume


Gary Poster wrote:


On Aug 23, 2005, at 8:07 PM, Michel Pelletier wrote:


On Tue, 2005-08-23 at 18:04 -0400, Gary Poster wrote:



The relationship between ZODB content objects, their int id as
provided by the pertinent intid utility, and a (theoretical)
corresponding RDF URI is what I'm having a hard time not making hacky
in my mind.  I'll think about it some more.



They might not be that hacky, this might be the wrong direction to  take
but URI's don't have to be visually meaningful, blank nodes, for
example, are usually just '_:' concatenated to a random opaque string.
If the URI were 'zope:' (maybe path/to/intid/util:)  that
would work just as well, it would also be trival to transform into a
feasible join key if the URI was also a URL that looked up, instead of
some network resource, an intid.

Actually being able to trivially transform an intid to an rdflib URI
might be something to think about.  Thinking about it more, the  current
Zemantic uses the physical path of the object as the rdf:about="" URI
when an object adds itself, because honestly I could think of no other
URI in Zope.  This is obviously wrong, but I didn't have a better  answer
in paris.  Why not use the `intid` plus some URI sugar?  If the URI  and
the intid can be easily converted from one to the other then that  should
solve the whole problem, no?


Here's another way to work with intids that I think could work:

In rdflib in some backends like IOMemory, and internal id is found for a 
subject (or predicate or object) to use in the internal storage 
datastructures. rdflib uses some randid() for that.


I propose that instead of calling randid(), it called self.assignid(subject) 
which would be pluggable. By default this would be the default randid, but 
you could allow Zope to create a graph with an assignid that assigned ids 
based on the intid service.


Then if a subject or object passed to rdflib is an integer instead of a URI, 
it would be used directly. In effect you'd give access to the internal ids.


(There are more details to solve (assignid needs to check for collisions 
sometimes), but I think that's a good starting point).


Florent

--
Florent Guillaume, Nuxeo (Paris, France)   CTO, Director of R&D
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: XML header and TAL interpretor

Julien Anguenot wrote:
>>>I think it's time to sketch out a proposal :).
> 
> +1 Do you want to write it ?

I can start, then you, Tonica and others can pad it out in the wiki.

Philipp
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: XML header and TAL interpretor

2005-09-01 Thread Julien Anguenot

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Philipp von Weitershausen wrote:
> Tonico Strasser wrote:
> 
>>Philipp von Weitershausen schrieb:
>>
>>
>>>Tonico Strasser wrote:
>>>
>>>
Philipp von Weitershausen schrieb:



>Tonico Strasser wrote:
>
>
>
>>Philipp von Weitershausen schrieb:
>>
>>
>>
>>
>>>I'm not so sure that this is such a good thing. ZPT seems to enforce
>>>*guidelines* that not everyone might want to follow (e.g. if I
>>>want to
>>>output my XHTML as c14n or something similar). For me, ZPT's HTML
>>>mode
>>>just does too many things, most of which won't hurt to be the
>>>template
>>>author's responsibility. I definitely consider  vs. 
>>>one of
>>>them.
>>
>>
>>
>>You have different use cases, obviously. For me, HTML mode is a good
>>thing including  to  conversion. (I don't like to write >/> all the time, all our web pages are served as text/html for
>>non-XHTML
>>browsers like MSIE, and we follow the compatibility guidelines from
>>the
>>XHTML standard).
>
>
>
>
>That's good and I agree that there should be tools that aid you in
>making your HTML work better with the guidelines. But if that means
>introducing weird obstacles for ZPT authors, I don't think these tools
>should be part of the ZPT renderer. If you don't want to write 
>all the time, use a "guideline compliance maker" tool (maybe xmllint
>will do) and feed your template to it... Templating XML is part of
>ZPT's
>job; I question if it should do much more at this point.

But that's why ZTPs have HTML mode, no?
>>>
>>>Yes. But rather than helping us, those features are more and more in our
>>>way. And with XML and HTML modes being incompatible, I rather opt for
>>>XML mode and sacrifice a small convenience that I could even bring back
>>>by using additional tools.
>>>
>>>
>>I agree that it should be possible to trigger XML mode without the
>>prolog for use cases like yours.
>
>
>That won't help because HTML mode macros and XML mode macros aren't
>compatible. I really would like to see XML be the default, including
>Zope 3's skin macros.


Yes, would also like to see this.
>>>
>>>Ah, good. It wasn't at all clear that you actually supported the
>>>proposal :).
>>
>>Yes, if it's still possible to trigger HTML mode. But what about
>>backwards compatibility if we make XML the default mode?
> 
> 
> Well, the namespace stuff would probably account for a major breakage.
> Thus, over the span of two Zope releases, XML mode could be forgiveful
> when people forget to register namespace declarations. Of course, it
> would render deprecation warnings.
> 
> I can't imagine a smooth transition for the other "features" of HTML
> mode because they are like on/off switches. Either you convert  to
>  or you don't. Same with  vs. 
> and the other things.
> 
> I think it's time to sketch out a proposal :).

+1 Do you want to write it ?

J.

- --
Julien Anguenot | Nuxeo R&D (Paris, France)
CPS Platform : http://www.cps-project.org
Zope3 / ECM   : http://www.z3lab.org
mail: anguenot at nuxeo.com; tel: +33 (0) 6 72 57 57 66
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFDFxUnGhoG8MxZ/pIRAvEMAJ0XxFB4peOaIgPyLtdDXIy+j85X0wCcDs4S
z76EIi9Zd8UU8SbqVUaQZtw=
=qWcz
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: XML header and TAL interpretor

Tonico Strasser wrote:
> Philipp von Weitershausen schrieb:
> 
>> Tonico Strasser wrote:
>>
>>> Philipp von Weitershausen schrieb:
>>>
>>>
 Tonico Strasser wrote:


> Philipp von Weitershausen schrieb:
>
>
>
>> I'm not so sure that this is such a good thing. ZPT seems to enforce
>> *guidelines* that not everyone might want to follow (e.g. if I
>> want to
>> output my XHTML as c14n or something similar). For me, ZPT's HTML
>> mode
>> just does too many things, most of which won't hurt to be the
>> template
>> author's responsibility. I definitely consider  vs. 
>> one of
>> them.
>
>
>
> You have different use cases, obviously. For me, HTML mode is a good
> thing including  to  conversion. (I don't like to write  /> all the time, all our web pages are served as text/html for
> non-XHTML
> browsers like MSIE, and we follow the compatibility guidelines from
> the
> XHTML standard).




 That's good and I agree that there should be tools that aid you in
 making your HTML work better with the guidelines. But if that means
 introducing weird obstacles for ZPT authors, I don't think these tools
 should be part of the ZPT renderer. If you don't want to write 
 all the time, use a "guideline compliance maker" tool (maybe xmllint
 will do) and feed your template to it... Templating XML is part of
 ZPT's
 job; I question if it should do much more at this point.
>>>
>>> But that's why ZTPs have HTML mode, no?
>>
>> Yes. But rather than helping us, those features are more and more in our
>> way. And with XML and HTML modes being incompatible, I rather opt for
>> XML mode and sacrifice a small convenience that I could even bring back
>> by using additional tools.
>>
> I agree that it should be possible to trigger XML mode without the
> prolog for use cases like yours.


 That won't help because HTML mode macros and XML mode macros aren't
 compatible. I really would like to see XML be the default, including
 Zope 3's skin macros.
>>>
>>>
>>> Yes, would also like to see this.
>>
>> Ah, good. It wasn't at all clear that you actually supported the
>> proposal :).
> 
> Yes, if it's still possible to trigger HTML mode. But what about
> backwards compatibility if we make XML the default mode?

Well, the namespace stuff would probably account for a major breakage.
Thus, over the span of two Zope releases, XML mode could be forgiveful
when people forget to register namespace declarations. Of course, it
would render deprecation warnings.

I can't imagine a smooth transition for the other "features" of HTML
mode because they are like on/off switches. Either you convert  to
 or you don't. Same with  vs. 
and the other things.

I think it's time to sketch out a proposal :).

Philipp
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: XML header and TAL interpretor

Philipp von Weitershausen schrieb:

Tonico Strasser wrote:

Philipp von Weitershausen schrieb:

Tonico Strasser wrote:

Philipp von Weitershausen schrieb:

I'm not so sure that this is such a good thing. ZPT seems to enforce
*guidelines* that not everyone might want to follow (e.g. if I want to
output my XHTML as c14n or something similar). For me, ZPT's HTML mode
just does too many things, most of which won't hurt to be the template
author's responsibility. I definitely consider vs. one of
them.

You have different use cases, obviously. For me, HTML mode is a good
thing including to conversion. (I don't like to write all the time, all our web pages are served as text/html for non-XHTML
browsers like MSIE, and we follow the compatibility guidelines from the
XHTML standard).

That's good and I agree that there should be tools that aid you in
making your HTML work better with the guidelines. But if that means
introducing weird obstacles for ZPT authors, I don't think these tools
should be part of the ZPT renderer. If you don't want to write
all the time, use a "guideline compliance maker" tool (maybe xmllint
will do) and feed your template to it... Templating XML is part of ZPT's
job; I question if it should do much more at this point.

But that's why ZTPs have HTML mode, no?

Yes. But rather than helping us, those features are more and more in our
way. And with XML and HTML modes being incompatible, I rather opt for
XML mode and sacrifice a small convenience that I could even bring back
by using additional tools.

I agree that it should be possible to trigger XML mode without the
prolog for use cases like yours.

That won't help because HTML mode macros and XML mode macros aren't
compatible. I really would like to see XML be the default, including
Zope 3's skin macros.

Yes, would also like to see this.

Ah, good. It wasn't at all clear that you actually supported the
proposal :).

Yes, if it's still possible to trigger HTML mode. But what about
backwards compatibility if we make XML the default mode?

Tonico

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: XML header and TAL interpretor


Philipp von Weitershausen schrieb:

Tonico Strasser wrote:


Philipp von Weitershausen schrieb:



Tonico Strasser wrote:



Philipp von Weitershausen schrieb:




If we make XML the default mode, I don't see how it would impact IE
very
much.



IE would try to dowload HTML pages not served as text/html. Pages in XML
mode should be served as XML not text/html.




I think that last sentence is a bit strong and IMO even plain wrong.
ZPT's mode of operation has nothing to do with how it's served in an
HTTP response. 



I thougth this is part of the XML spec. No?

http://www.xml.com/pub/a/2004/07/21/dive.html
http://www.ietf.org/rfc/rfc3023.txt



The RFC you cite here introduces five (!) new media types for XML, two
of which are text/xml and application/xml. So that's already ambiguous.
Apart from that, http://www.ietf.org/rfc/rfc3236.txt introduces
application/xhtml+xml, also a valid XML content type, for XHTML in
particular (of course, I bet that IE won't accept it so pragmatism wins
over RFC-compliance here and we have to stick with text/html). As for
other XML dialects, there are even content types that aren't text/* or
applicaton/* and still deal with XML, e.g. image/svg+xml for SVG
(http://www.w3.org/TR/2004/WD-SVG12-20041027/mimereg.html).

The point of all this is that text/xml just isn't enough. It's a good
fallback, but it's not enough, especially including serving HTML. From
that I conclude that the "should" in your sentence above is wrong.


And to which media type should ZPTs in XML mode default to?

Tonico

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] practical example of migrating from services to utilities

2005-09-01 Thread nagendra kumar

Title: practical example of migrating from services to utilities






Hello All,

    I have a method which is working well in zope3.0 but its not working well in Zope3.1 c2 version.

    I am new to zope3 framework.I think services have no support in zope3.1.what do i need to do to make it work.

    I think i have to use either adpaters or utilities for this task.

    Somebody please send me a cod snippet to make it work.


    I am putting my code snippet below


    from zope.app.publisher.browser import BrowserView

    from zope.app.exception.interfaces import UserError

    from zope.app.pluggableauth.interfaces import IPluggableAuthentication

    from zope.app.securitypolicy.interfaces import IPrincipalRoleManager

    _ = MessageIDFactory('mynewsite')


    from mynewsite.interfaces import ISignupPrincipalSource


    def _getPrincipalSource(self):

            # I am getting error at below place when signing up

            pluggableauth = zapi.getService(zapi.servicenames.Authentication,context=self.context)

            if not IPluggableAuthentication.providedBy(pluggableauth):

                raise LookupError, "Signup requires a pluggableauth instance."

            for principal_source in pluggableauth.values():

                if ISignupPrincipalSource.providedBy(principal_source):

                    return principal_source

            raise TypeError, "Signup requires a SignupPrincipalSource."

    Thanks in advance

Regards

-Nagendra Kumar



___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: XML header and TAL interpretor

Tonico Strasser wrote:
> Philipp von Weitershausen schrieb:
> 
>> Tonico Strasser wrote:
>>
>>> Philipp von Weitershausen schrieb:
>>>
>>>
 I'm not so sure that this is such a good thing. ZPT seems to enforce
 *guidelines* that not everyone might want to follow (e.g. if I want to
 output my XHTML as c14n or something similar). For me, ZPT's HTML mode
 just does too many things, most of which won't hurt to be the template
 author's responsibility. I definitely consider  vs.  one of
 them.
>>>
>>>
>>> You have different use cases, obviously. For me, HTML mode is a good
>>> thing including  to  conversion. (I don't like to write >> /> all the time, all our web pages are served as text/html for non-XHTML
>>> browsers like MSIE, and we follow the compatibility guidelines from the
>>> XHTML standard).
>>
>>
>>
>> That's good and I agree that there should be tools that aid you in
>> making your HTML work better with the guidelines. But if that means
>> introducing weird obstacles for ZPT authors, I don't think these tools
>> should be part of the ZPT renderer. If you don't want to write 
>> all the time, use a "guideline compliance maker" tool (maybe xmllint
>> will do) and feed your template to it... Templating XML is part of ZPT's
>> job; I question if it should do much more at this point.
> 
> But that's why ZTPs have HTML mode, no?

Yes. But rather than helping us, those features are more and more in our
way. And with XML and HTML modes being incompatible, I rather opt for
XML mode and sacrifice a small convenience that I could even bring back
by using additional tools.

>>> I agree that it should be possible to trigger XML mode without the
>>> prolog for use cases like yours.
>>
>> That won't help because HTML mode macros and XML mode macros aren't
>> compatible. I really would like to see XML be the default, including
>> Zope 3's skin macros.
> 
> Yes, would also like to see this.

Ah, good. It wasn't at all clear that you actually supported the
proposal :).

Philipp

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: XML header and TAL interpretor

Tonico Strasser wrote:
> Philipp von Weitershausen schrieb:
> 
>> Tonico Strasser wrote:
>>
>>> Philipp von Weitershausen schrieb:
>>>
>>>
 If we make XML the default mode, I don't see how it would impact IE
 very
 much.
>>>
>>>
>>> IE would try to dowload HTML pages not served as text/html. Pages in XML
>>> mode should be served as XML not text/html.
>>
>>
>>
>> I think that last sentence is a bit strong and IMO even plain wrong.
>> ZPT's mode of operation has nothing to do with how it's served in an
>> HTTP response. 
> 
> 
> I thougth this is part of the XML spec. No?
> 
> http://www.xml.com/pub/a/2004/07/21/dive.html
> http://www.ietf.org/rfc/rfc3023.txt

The RFC you cite here introduces five (!) new media types for XML, two
of which are text/xml and application/xml. So that's already ambiguous.
Apart from that, http://www.ietf.org/rfc/rfc3236.txt introduces
application/xhtml+xml, also a valid XML content type, for XHTML in
particular (of course, I bet that IE won't accept it so pragmatism wins
over RFC-compliance here and we have to stick with text/html). As for
other XML dialects, there are even content types that aren't text/* or
applicaton/* and still deal with XML, e.g. image/svg+xml for SVG
(http://www.w3.org/TR/2004/WD-SVG12-20041027/mimereg.html).

The point of all this is that text/xml just isn't enough. It's a good
fallback, but it's not enough, especially including serving HTML. From
that I conclude that the "should" in your sentence above is wrong.

Philipp
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: XML header and TAL interpretor

Philipp von Weitershausen schrieb:

Tonico Strasser wrote:

Philipp von Weitershausen schrieb:

But that's why ZTPs have HTML mode, no?

I agree that it should be possible to trigger XML mode without the
prolog for use cases like yours.

That won't help because HTML mode macros and XML mode macros aren't
compatible. I really would like to see XML be the default, including
Zope 3's skin macros.

Yes, would also like to see this.

Tonico

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: XML header and TAL interpretor


Philipp von Weitershausen schrieb:

Tonico Strasser wrote:


Philipp von Weitershausen schrieb:



If we make XML the default mode, I don't see how it would impact IE very
much.


IE would try to dowload HTML pages not served as text/html. Pages in XML
mode should be served as XML not text/html.



I think that last sentence is a bit strong and IMO even plain wrong.
ZPT's mode of operation has nothing to do with how it's served in an
HTTP response. 


I thougth this is part of the XML spec. No?

http://www.xml.com/pub/a/2004/07/21/dive.html
http://www.ietf.org/rfc/rfc3023.txt

Tonico

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: XML header and TAL interpretor

Tonico Strasser wrote:
> Philipp von Weitershausen schrieb:
> 
>> If we make XML the default mode, I don't see how it would impact IE very
>> much.
> 
> IE would try to dowload HTML pages not served as text/html. Pages in XML
> mode should be served as XML not text/html.

I think that last sentence is a bit strong and IMO even plain wrong.
ZPT's mode of operation has nothing to do with how it's served in an
HTTP response. There should be (and are) other means of determining and
setting the content type. Automagic guessing from the mode of operation
won't work when XML mode is the default, that's true. But I think that's
a good thing.

Philipp
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: XML header and TAL interpretor


Philipp von Weitershausen schrieb:


If we make XML the default mode, I don't see how it would impact IE very
much.


IE would try to dowload HTML pages not served as text/html. Pages in XML 
mode should be served as XML not text/html.


Tonico

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: XML header and TAL interpretor

Tonico Strasser wrote:
> Philipp von Weitershausen schrieb:
> 
>> I'm not so sure that this is such a good thing. ZPT seems to enforce
>> *guidelines* that not everyone might want to follow (e.g. if I want to
>> output my XHTML as c14n or something similar). For me, ZPT's HTML mode
>> just does too many things, most of which won't hurt to be the template
>> author's responsibility. I definitely consider  vs.  one of
>> them.
> 
> You have different use cases, obviously. For me, HTML mode is a good
> thing including  to  conversion. (I don't like to write  /> all the time, all our web pages are served as text/html for non-XHTML
> browsers like MSIE, and we follow the compatibility guidelines from the
> XHTML standard).

That's good and I agree that there should be tools that aid you in
making your HTML work better with the guidelines. But if that means
introducing weird obstacles for ZPT authors, I don't think these tools
should be part of the ZPT renderer. If you don't want to write 
all the time, use a "guideline compliance maker" tool (maybe xmllint
will do) and feed your template to it... Templating XML is part of ZPT's
job; I question if it should do much more at this point.

> I agree that it should be possible to trigger XML mode without the
> prolog for use cases like yours.

That won't help because HTML mode macros and XML mode macros aren't
compatible. I really would like to see XML be the default, including
Zope 3's skin macros.

Philipp
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: XML header and TAL interpretor


Philipp von Weitershausen schrieb:

I'm not so sure that this is such a good thing. ZPT seems to enforce
*guidelines* that not everyone might want to follow (e.g. if I want to
output my XHTML as c14n or something similar). For me, ZPT's HTML mode
just does too many things, most of which won't hurt to be the template
author's responsibility. I definitely consider  vs.  one of them.


You have different use cases, obviously. For me, HTML mode is a good 
thing including  to  conversion. (I don't like to write /> all the time, all our web pages are served as text/html for non-XHTML 
browsers like MSIE, and we follow the compatibility guidelines from the 
XHTML standard).


I agree that it should be possible to trigger XML mode without the 
prolog for use cases like yours.


Tonico

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Should major for-reaching changes be made for purposes of style?

On Wednesday 31 August 2005 17:05, Jim Fulton wrote:
> I'm interested in hearing what people think about this in general.
> Should we make far reaching code changes to enforce a consistent
> style?  Or should we update style when making other changes?
> I tend to do the later.

I think this depends on the case. For example, when we decided to switch to 
doctests, we did not simply rewrite all tests; and this is fine, because we 
did not have the resources. For a change like Martijn's I think a massive 
redoing was okay. Style is very high on my importance list. It gives new 
developers an easier lead in.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] TALES namespace names cannot contain '-'

On Thursday 01 September 2005 05:10, Steve Alexander wrote:
> I found that this didn't work, because only the characters [a-zA-Z0-9_]
> are allowed.  You can find the regex on line 27 of
> zope/tales/expressions.py.
>
>   namespace_re = re.compile('(\w+):(.+)')
>
>
> I propose to extend this to allow the '-' character too.

+1

> Any objections to this?

nope.

> Are there any other characters that should be included?

probably, but let's be conservative about it. We effectively could allow 
anything that is allowed in a regular URL path segment minux ":". 

> Do any specifications need changing?

I don't think so. If the directory the code is in has any TXT files you might 
want to read through them making sure that the characters are not mentioned 
anywhere.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: XML header and TAL interpretor

Derrick Hudson wrote:
> On Wed, Aug 31, 2005 at 03:54:45PM +0200, Philipp von Weitershausen wrote:
> | Julien Anguenot wrote:
> [...]
> 
> | > If you change the header like this then it can be succesfully included :
> | > 
> | > 
> | > http://www.w3.org/1999/xhtml";
> | >   xmlns:tal="http://xml.zope.org/namespaces/tal";
> | >   xmlns:metal="http://xml.zope.org/namespaces/metal";
> | >   xmlns:i18n="http://xml.zope.org/namespaces/i18n";
> | >   i18n:domain="zope">
> | > 
> | > 
> | > What kind of issue could we have changing the headers like this on all
> | > the standard macros since it's xhtml already ?
> | 
> | I'm not sure if this is a good idea. Because once Zope3's macros are XML
> | mode, all other templates using those macros need to be XML mode. That,
> | in turn, means that all templates need to carry the 
> | processing instruction because that's the only way XML mode is currently
> | triggered. Since that processing instruction is optional (as opposed to
> | namespace declarations which are mandatory), I wouldn't want to force it
> | on template authors.
> 
> Don't forget that IE will then have an insane tendency to render the
> pages wrong.  I don't recall all of the details, but it was something
> like if the document began with  IE would switch to "quirks
> mode" and do funny things with boxes, margins, and the overall layout.
> The details are in this list's archives (if they aren't it's in the
> zope@zope.org list archives).

I know about quirks mode and how it's provoked with .
Exactly because of that it has been impossible to use ZPT's XML mode to
render web pages -- because IE will choke on the  that is
necessary to put the ZPT machinery into XML in the first place... a
vicious circle so to speak.

If we make XML the default mode, I don't see how it would impact IE very
much. After all, the  processing instruction would then be
optional and could be left out for XHTML pages. It would finally be
possible to properly embed XForms, SVG etc. into XHTML though.

Philipp
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: XML header and TAL interpretor

Tonico Strasser wrote:
> Fred Drake schrieb:
> 
>> On 8/31/05, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote:
>>
>>> HTML4 mode exists because
>>
>>
>> ...
>>
>>> - it enforces some HTML document type (as mentioned before); no idea why
>>> it does that
>>
>> I'm just guessing you're referring to its understanding of the allowed
>> nesting structures.  This is done so that the partial well-formedness
>> it requires mixed with the careless infliction of pain commonly
>> performed by old-style HTML authors produces as few surprises as
>> possible.  The only well-formedness it directly enforces is for
>> elements that actually have TAL, METAL, and I18N attributes.  Whether
>> this was the right thing to do is debatable.
>>
>> Another reason for the HTML mode is that many of the HTML editors
>> deployed when we first developed TAL were not generating XHTML, and
>> weren't expected to do so in the immediate future.  We definately
>> wanted page templates to be editable in WYSIWYG-type editors.
> 
> And, as long pages are served as text/html they are treated as old-style
> HTML by browsers anyway[1].
> 
> XHTML pages served as text/html must follow the compatibility
> guidelines[2]. E.g. in ZPT HTML mode, elements like  will be
> converted to  automagically (with space before the slash). That is
> a good thing IMHO.

I'm not so sure that this is such a good thing. ZPT seems to enforce
*guidelines* that not everyone might want to follow (e.g. if I want to
output my XHTML as c14n or something similar). For me, ZPT's HTML mode
just does too many things, most of which won't hurt to be the template
author's responsibility. I definitely consider  vs.  one of them.

Philipp
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: XML header and TAL interpretor

Fred Drake wrote:
> On 8/31/05, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote:
> 
>>HTML4 mode exists because
> 
> ...
> 
>>- it enforces some HTML document type (as mentioned before); no idea why
>>it does that
> 
> 
> I'm just guessing you're referring to its understanding of the allowed
> nesting structures.

Indeed.

> This is done so that the partial well-formedness
> it requires mixed with the careless infliction of pain commonly
> performed by old-style HTML authors produces as few surprises as
> possible.  The only well-formedness it directly enforces is for
> elements that actually have TAL, METAL, and I18N attributes.  Whether
> this was the right thing to do is debatable.
> 
> Another reason for the HTML mode is that many of the HTML editors
> deployed when we first developed TAL were not generating XHTML, and
> weren't expected to do so in the immediate future.  We definately
> wanted page templates to be editable in WYSIWYG-type editors.

I'm not at all questioning your reasoning of inventing HTML mode in the
first place. I think it was definitely useful and a reasonable solution
at the time. Now it's just in our way, at least in Julien's, mine, and
other people's who have been bitten by the
XML-macros-not-compatible-with-HTML-macros feature.

Philipp
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)

2005-09-01 Thread Adam Groszer

Dear Gary,

Maybe not too late, I have here one more thing to look at:

It happened that the szerepek attribute of the object implementing the
ISzemely interface was left by default at a value "None". As I tried
to modify the object with a standard generated editform, the exception
below came. I think None should be considered the same as [].
If we agree on that I would maybe consider that even as a bug.


...
  Module zope.tales.tales, line 684, in setRepeat
expr = self.evaluate(expr)
  Module zope.tales.tales, line 698, in evaluate
return expression(self)
   - Y:\zope\svn_zope3\src\zope\app\form\browser\orderedSelectionList.pt
   - Line 166, Column 8
   - Expression: 
   - Names:
  {'args': (),
   'context': ,
   'default': ,
   'loop': {},
   'nothing': None,
   'options': {},
   'repeat': {},
   'request': http://127.0.0.1:8080/ap1/szemely/uno/@@edit.html>,
   'template': 
,
   'usage': ,
   'view': ,
   'views': }
  Module zope.tales.expressions, line 204, in __call__
return self._eval(econtext)
  Module zope.tales.expressions, line 198, in _eval
return ob()
  Module zope.app.form.browser.itemswidgets, line 585, in selected
for value in self.context.get(self.context.context):
TypeError: iteration over non-sequence

class ISzemely(Interface):
...
szerepek = List(
title=u"Hozzarendelt szerepek",
description=u"Hozzarendelt szerepek",
required=False,
value_type=Choice(vocabulary="szerep")
)
...

-- 
Best regards,
 Adammailto:[EMAIL PROTECTED]
--
Quote of the day:
Diplomacy is the art of saying "nice doggy" until you can find a rock.

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: XML header and TAL interpretor