[EMAIL PROTECTED] schrieb:
The name browser for a namespace sux IMHO ;)
The idea of a namspace called browser is the following:
We use the namespace browser for *presentations* (the earlier
name for pages) which depends on the IBrowserRequest.
This is also reflected in the package structure
[EMAIL PROTECTED] schrieb:
Hi Tonico
At some point it will be necessary to make the framework
understandable for normal UI designers or we'll stick with
ugly user interfaces forever :)
I think it's pretty clear right now. Do you really think if
soembody don't understand what a folder json
Philipp von Weitershausen schrieb:
I also think it makes it hard to understand. In response to this
proposal, several people have asked me By the way, what's the
difference between browser:page / and browser:view / anyhoo? That
alone has proven my point that the current system makes it
Stefan H. Holek wrote:
My take is that it's not the TAL features (tal:define, python:,
whatever) that invite misuse, but the available namespaces.
I have ported ZPT to Django [1][2] and found the experience surprisingly
refreshing. Django naturally does not have anything like container or
Philipp von Weitershausen wrote:
In CMF things are very easy to understand, because a layer is simply a
folder. I can explain that in five minutes to a template programmer.
Why does the template programmer need to know about layers?
Because in CMF, if you want to customize or create a skin,
Hi Jean-Marc!
I agree that a view should not be able to modify the data model. But I
think tal:define is a must have :)
For example: I need tal:define to define names for generic macros:
ul tal:define=list main_navigation
li metal:use-macro=macros/li_repeat/
/ul
The 'li_repeat' macro
Jean-Marc Orliaguet wrote:
tal:define is used here to pass parameters to the macro. In ZPT this
is done implicitly, which is why macros specify a list a variables that
must be defined.
In other language this is done explictly. (cf. XSLT xsl:with-param ...)
If it was done explicitly in ZPT it
Benji York wrote:
Jean-Marc Orliaguet wrote:
[snip description of cross-template communication]
that's an anti-pattern
Agreed.
Although you told me that's an anti-pattern, I'll have to use it until I
find a better pattern. I can't live without the benefit of reusing macros.
Tonico
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lennart Regebro wrote:
On 2/13/06, Tonico Strasser [EMAIL PROTECTED] wrote:
Looking forward to see explicit ZPTs soon :)
Me too. I'd also like the macros to be called rather than expanded, so
that any error messages report
Chris Withers wrote:
A big -1 from me.
This is yet more complexity and more stuff that Zope shouldn't try to
do. If you want to serve flat files, use Apache.
From my understanding this is not only about serving flat files.
OTOH I think that it may be possible to make Apache to do this:
Christian Theune wrote:
Hi,
is there a chance we can get rid of the Refresh button on the standard
forms? Every now and then, I hit the wrong one. And I do not see a clear
need for the refresh.
+1 on getting rid of the refresh button.
What others say about reset (refresh?) buttons:
Jean-Marc Orliaguet schrieb:
Tonico Strasser wrote:
Michael Jansen schrieb:
Hi
Is there anywhere an explanation how the rotterdam skin works. Some
insight's to how an when which parts are selected?
How to use and expand it?
I think i'm making progress in understanding how the parts
http://dev.zope.org/Zope3/BetterXMLSupportForPageTemplates
One comment on the section Questioning HTML mode in this document:
HTML mode is still useful for user agents that use a SGML parser instead
of a XML parser and would break if they had to deal with real XML code.
I know, such user
Martijn Faassen schrieb:
Hi there,
I'm very curious to see what work was done on a Zope 3 website at the
Neckar sprint. Can someone send a report to the list?
The plan has been to migrate all the Wiki pages from zope.org to zope3.org.
The new thing is, that Wikipages should be editable
Martijn Faassen schrieb:
...
Has work been done on a reasonably slick layout for the website as well
or is this still planned?
Don't know about plans. After a short discussion on the sprint we have
agreed on starting with a very simple layout. It's not finished yet, it
should contain those
Roger Ineichen schrieb:
Hi together
I like to simplify the macro registration.
The target is to get rid of the mapping in a custom class
where we use right now (StandardMacros) and offer a directive
for register macros in ZCML.
See the proposal at:
Roger Ineichen schrieb:
I'm not sure I want another prefix in ZPT. I would prefer to
provide (or
push?) a custom namespace to the template and then use
standard_macros/my_macro or simply macros/my_macro.
I know what you mean, but like we discuss at the sprint that are
two different
Jim Fulton schrieb:
At:
http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/PublicationPostProcessing
I've put doesn some thoughs for discussion on making the publication APIs
more explicit and for supporting post processing tasks like adding
standard look and feel or
Philipp von Weitershausen schrieb:
...
So, I would like to give principal a better name. How about
participant? After all, a principal _participates_ in an interaction
through a participation (e.g. an HTTP request). Participant should also
be pretty easy to translate: it's a common word,
Andreas Reuleaux schrieb:
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
Chris Withers schrieb:
For me, the fact that ZPT uses a field called content_type to control
the mode is bogus :-(
That content_type value is also used to set the content-type in the
response by default.
Tonico
___
Zope3-dev mailing list
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
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
___
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
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
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
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
Hi!
Jean-Marc Orliaguet schrieb:
Anyway, pagelets or portlets whatever they called and no matter what
data they produce (structured data or raw HTML) must be pipe-able
through the rendering engine, i.e. they must return some data, the more
ready HTML the data is the less reusable it will be.
Jean-Marc Orliaguet schrieb:
Tonico Strasser wrote:
Hi!
Jean-Marc Orliaguet schrieb:
Anyway, pagelets or portlets whatever they called and no matter what
data they produce (structured data or raw HTML) must be pipe-able
through the rendering engine, i.e. they must return some data
29 matches
Mail list logo
