[Zope3-dev] Re: RFC: The browser:page compromise
[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 like: package browser For other request types like FTPRequest, XMLRPC or JSON etc we use: package ftp xmlrpc json Perhaps this is to technical and will confuse people which don't know the base concepts of request type interfaces. But since no tehchnical peple have no chance to develope with z3 I think this naming is OK. 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 :) How is a browser defined in Zope 3 and how are these names related to it? [...] All of this directive are based on the IBrowserRequest. Other requests like FTPRequest don't have a menu layer etc. How is a BrowserRequest different from a HTTPRequest? 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: RFC: The browser:page compromise
[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 or browser should contain he ever will be able to understand what he has to do in ZCML? (I guess this is really not a naming problem) I once tried to understand how the default skin works -- after that I gave up the idea of creating a new ZMI skin myself. (Especially the MacroMagic was difficult to understand, but I want to try again someday). I like Philipps proposal because it tries to remove some of that magic that makes it often difficult to understand (or to accept) the concept. Do yo have a simpler naming and/or module/package structure concept in mind? If so, is this not only a part of a project or application like a CMS etc? Do you think UI Developers should work out of the box with a Zope3 instance? Not at the moment. A browser request offers a API for collecting browser (client) releated informations like charset settings. This is done via the interface IUserPreferredCharsets. Interesting, does it also offer an API for preferred language and preferred media? A browser request also deals with form data and collects the given form input into a FieldStorage object. The most important part here is that a browser request knows how to handle file upload. Interesting. The browser request is based on the http request which does the base stuff like cookie handling etc. Thanks for explanation. 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: RFC: The browser:page compromise
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 absolutely incomprehensible of what's going on behind the scenes. The name browser for a namespace sux IMHO ;) How is a browser defined in Zope 3 and how are these names related to it? addMenuItem addform containerViews defaultSkin defaultView editform form i18n-resource icon layer menu menuItem menuItems page pages resource resourceDirectory schemadisplay skin subMenuItem subeditform tool view viewlet viewletManager What is a page? Is a dynamic stylesheet or a dynamic javascript or an Atom feed a page? Does a page provide a mime_type? Should a page do content negotiation? Create a new clean namespace and call it user_interface (or ui)! :) 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: Namespaces considered harmful [Was: tal:define=... considered harmful?]
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 context in the Zope sense. And by Django policy, templates don't even get to see the request. The namespace Zope PTs call options becomes the sole, top-level namespace in Django PTs. This very effectively keeps me from pulling-in anything not provided by the view in the first place. Everything -- even functions I want to call in, say, conditions -- has to be added by the view. The result is clean and fast templates. This sounds like best practice to me. [2] http://zope.org/Members/shh/DjangoPageTemplates/1.0.2/readme.txt I would even go a step further and leave the macro mapping to the view and write html metal:use-macro=macros/master/ instead of html metal:use-macro=templates/myapp/main/macros/master/ . Thus making the template more generic. 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: Last chance to comment on Simplify skinning
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, you need to know about the so called layers. Maybe this sounds a bit NAIVE, but would it be possible to make it like in CMF? The CMF approach is very limiting. The fact that a layer equals a physical location (a folder) led to every CMF-based product coming up with its own layer -- because there is no way to put stuff into existing layers, not even the default layer. Layers as they are in Zope 3 have stopped this senseless layer proliferation. I find Zope 3's approach much simpler and much easier to explain than the CMF's approach. In Zope 3 (especially with my proposed changes in place), a layer is simply a label (read: marker interface) on the request. When we now look up pages and resources (e.g. images), we take the request into account and therefore inevitably that label. We will only find pages and resources associated (read: registered) for this label. Good news is that any page or resource can be associated for this label, we just have to remember to do that in their ZCML directive. See, now I even explained this to a template programmer, though I don't think he'd care. Maybe I mean something different. I just want a folder in which I can drop all the files I want to customize (I love to customize), without registering something. Is this a layer? You're right, I don't care :) 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: tal:define=... considered harmful?
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 expects the name 'list'. 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: tal:define=... considered harmful?
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 could look like: li metal:use-macro=macros/li_repeat metal:with-params=items1 / li metal:use-macro=macros/li_repeat metal:with-params=items2 / Ok, thanks for the explanation. This looks better of course. If this were possible I could live without tal:define. Looking forward to see explicit ZPTs soon :) 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: tal:define=... considered harmful?
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 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: tal:define=... considered harmful?
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 the error in the macro rather than in an expanded main template. This should be possible if we have explicit macro parameters. In fact, this would not only solve the two biggest problems with macros, it would make the macros functions, which is much better. If we don't want to break backwards compatibility, calling them functions would be a good idea. That's a non-goal for me: macros are *not* functions, and aren't supposed to be called: the point of them is that they operate in the context of the caller. In addition to the loss of functionality (slots, as you note), calls are much more expensive than macros. Hi Tres, I'm interested in your opinion about parameters for macros. Do you think this is explicit enough?: ul tal:define=list main_navigation li metal:use-macro=macros/li_repeat/ /ul Or do you think explicit parameters would make things clearer?: ul li metal:use-macro=macros/li_repeat metal:with-params=list main_navigation/ /ul 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: Zope 3 web root
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: Let's add some ZCML directives that define how to interpret filenames in the web root by their extension. The .zodb file would specify what kind of storage to open, where to find it, and what object to load from it. In a sense, the web root would mount the object database. 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: Refresh / Change-Buttons
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: http://www.useit.com/alertbox/2416.html http://www.joeclark.org/book/sashay/serialization/Chapter12.html#h5-1380 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: How does the rotterdam skin work?
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 click together, but some additional insights would be nice. The tutorials i found about skins just told me to create a template.pt and a dialog_macros.pt and so on. But not why. And when either one is used. I think i understand some parts of that now and if there is no such thing like a explanation of this logics i would try to blame myself by writing down my findings so far. Btw. I think doc/skins/README.txt is a little bit out of date. I think the Rotterdam skin is doomed. I'd rather create my own skin than try to expand it. Tonico Hi! the problem is not in the skin itself, but in the model used to create skins. Filesystem-based skins that depend on ZPT macros are doomed by definition, unless they are designed to cover most of the site layouts you'll find on the internet (for instance the Plone skin is quite generic). But maintaining such a generic skin (HTML + CSS) is a lot of work. Yes, and the ZMI-design is also broken IMHO. Actions below tabs is not intuitive, the navtree does not feel good etc. I find the classic ZMI much better in this respect. I guess I'm confusing the ZMI with a Skin definition :) Memo: Management Interface != Skin = Skin != Management Interface Also there is a problem with the target audience: ZPT programmers are not always good graphic designers and UI/ graphic designers are not always good at ZPT / python. I agree. 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: .xpt extension for explicit xml processing
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 agents are very rare, Netscape 4 comes into my mind. (If you want to make Netscape 4 burn just put a br/ somewhere in the source). Why does HTML mode help? It converts foo/ to foo /. This behaviour is described in appendix C of the XHTML specs. This appendix summarizes design guidelines for authors who wish their XHTML documents to render on existing HTML user agents. http://www.w3.org/TR/xhtml1/#guidelines MSIE is known to handle XHTML pretty well althought it doesn't use a XML parser. IE can deal with br/ but it can't deal with script/. You have to write script/script for IE. Here a quote from an artikle at Wikipedia: Rather, XHTML 1.0 was intentionally designed to be usable by HTML 4.0 user agents, like Internet Explorer, if certain document authoring guidelines for backward compatibility were followed. http://en.wikipedia.org/wiki/Criticisms_of_Internet_Explorer#XHTML From this information I come to the conclusion that it would be best to simply follow the compatibility guidlines in appendix C. HTML mode helps me to do this by inserting a space before the closing slash. Just my two cents. 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: zope3 website report?
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 with a WYSIWYG editor after the migration. I hope that there will be an option to choose structured text too. More infos in the README: http://svn.zope.org/zope3org/trunk/src/wikification/README.txt?view=markup 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: zope3 website report?
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 elements: header - Zope 3 logo - username | login | log out - search box columns first column - breadcrumbs - the content area - some actions for edit, print, history, subsbscribe, ... - a by-line - a comment section second column - a simple navtree footer - ... http://svn.zope.org/zope3org/trunk/src/wikification/browser/main_template.pt?view=markup Has an analysis been done what the goals are of this new site? Don't know. I guess no. 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: ZPT Macros
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: http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/SimplifyMac roRegistration Can you tell me what you think? The ZCML directive is invisible on the Wiki, this I copied from the HTML source: browser:macros for=* name=standard_macros macros=page aliases=view:page dialog:page(only if we need to support the mapping) permission=zope.View template=template.pt layer=tiks.skins.basic.basic / I Like that. I think it would be very useful to be able to configure macros and access them in Python, at least for my use cases. Regarding: html metal:use-macro=macros:standard_macros/my_macro 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. 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: ZPT Macros
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 concepts. We only can provide a TALES namescape like macros:... otherwise we have to use a own page template implementation where uses a macro namespace as a constructor argument. But then we can't use the browser:page and all this directives for the registration out of the box. I prefere a macro namspace for TAL. Otherwise we have to implement different new ZCML registration directives where are using a custom page template implementation. Ok, I don't really understand what this all means. I have trivial use cases and don't understand why everything has to be so complicated. 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: RFC: Publication Post-Processing
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 adding missing page components. Hi, as a UI designer I would like to have a page Object (not the context object) that I can adapt to IPublicationResult. I would like contracts for HTML pages, e.g something like: class IHTMLPage(zope.interface.Interface): Provides information for a generic HTML Page title = '' description = '' class IZMIPage(IHTMLPage): Provides information for a basic ZMI page scripts = [] # ordererd List of IZMIScriptFiles styles = [] # ordered List of IZMIStylesheetFiles class_names = IZMICSSNames # class names mapping with standard keys id_names = IZMIIdNames # id names mapping with standard keys actions = [] # IZMIActions views = [] # IZMIViews # ... anything needed by a IZMIPageRenderer class IHTMLPageRenderer(IPublicationResult): def render(obj, request, html_page): Renders a HTML page class IZMIPageRenderer(IHTMLPageRenderer) def render(obj, request, zmi_page): Renders a ZMI page A renderer should be able to use any template language to do its job, e.g. ZPT, DTML, PHP, XSLT ... IMHO. Disclaimer: I guess the code above is garbage, this is just for discussion, I'm still learning the basics :) 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: RFC: Rename principal to participant
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, especially outside IT vocubulary, which means chances are good to find appropriate native translations for it. (Note that the point of finding translations for technical terms is not only for the sake of a translated Zope 3 UI. It's more about how people understand technical terms. I think most Zope 3 developers aren't native English speakers and they do not necessarily think in English. So, good words that have good native translations help the understanding process on their end. That is not only important for _learning_ a concept, but also for _explaining_ it. As a book author, I know what I'm talking about... :)) Hope to hear some comments, Here the obligatory dumb question: why is it not called user? 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
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 with the wrong MIME type --- You did not use the term useless so I might have overinterpreted what you wrote, sorry for that. I want to point out that if XML mode is the *default* mode for page templates in Zope 3, everything that does not override the mime type will be served as XML. (That's the current behaviour, it might change in the future?). At least we would need to be able to trigger HTML mode. 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. See above. I'm not saying that pages in XML mode are useless. 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. Not mistakes, but there is a huge difference IMHO: Pages are parsed as XML not as HTML http://mail.zope.org/pipermail/zope3-dev/2005-September/015554.html 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. :) 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: Difference in ZPT modes
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 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
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 br/ will be converted to br / automagically (with space before the slash). That is a good thing IMHO. [1] Serving XHTML 1.0 http://www.w3.org/International/articles/serving-xhtml/ [2] HTML Compatibility Guidelines http://www.w3.org/TR/xhtml1/#guidelines 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: 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
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
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 br/ vs. br / one of them. You have different use cases, obviously. For me, HTML mode is a good thing including br/ to br / conversion. (I don't like to write br / 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 br / 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? 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: 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 br/ to br / or you don't. Same with script .../script vs. script ... / 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: 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 br/ will be converted to br / automagically (with space before the slash). That is a good thing IMHO. [1] Serving XHTML 1.0 http://www.w3.org/International/articles/serving-xhtml/ [2] HTML Compatibility Guidelines http://www.w3.org/TR/xhtml1/#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=1091626816count=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] [DRAFT] local portlets and perspectives
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.
Pipe-able, hmm. I think, *if* we could do define-slot and fill-slot
stuff in Python code that would be very nice. We would have a page
object that can pipe page components together.
A simple example with boxes (sorry, Zope 2 script, don't kill me):
##
page = context.Page(template=container.ZPT_A)
# aggregate macro-defs from other page template
page.macros.update(container.ZPT_B.macros)
# create list of Box instances (not rendered HTML)
b1 = container.box_a('demo', 'Demo', condition=some_condition)
# box 2 takes b1 as input
b2 = container.box_b('foo', 'Foo', some_arg=b1)
left_boxes = [b1, b2]
# make boxes available in PTs as 'lboxes'
page.lboxes = left_boxes
# now we have aggregated all informations
# ready to render
# calls pt_render of ZPT_A with extra context
return page.render()
##
ZPT_A:
page
body metal:use-macro=macros/body/
/page
ZPT_B:
body metal:define-macro=body
!-- render boxes here --
box metal:use-macro=macros/box_repeat/
/body
box_repeat macro:
div class=box
metal:define-macro=box_repeat
tal:repeat=box lboxes
tal:attributes=id box/id
h1 class=box-header
tal:content=box/title/
div class=box-body
metal:use-macro=box/macros/body|default/
/div
Just for your inspiration.
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: [Z3lab] Re: [DRAFT] local portlets and perspectives
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, the more
ready HTML the data is the less reusable it will be.
Pipe-able, hmm. I think, *if* we could do define-slot and fill-slot
stuff in Python code that would be very nice. We would have a page
object that can pipe page components together.
yes, this is what cpsskins does:
- the define-slot is just a cpsskins:slot with a name identifier
('left', 'right', 'main' ...) which means that can be used on several pages.
- the fill-slot part has been the subject of the discussion the past
week in the perspective thread.
Currently the plan is to support the perspective way of filling slots
(1 perspective = 1 set of portlets) and the local folder way of
filling a slot, i.e. traversing the site starting from the site root to
the current folder, gathering all the portlets stored in each folder on
the path and displaying them into the slot that they belong to.
here is how the renderer works:
http://www.z3lab.org/sections/front-page/white-papers/draft-renderer/downloadFile/attachedFile/renderer-architecture.png
starting from the top node in the theme tree:
A) is the node a leaf?
= YES: then render the node according to B)
= NO: get the list of child nodes in the correct order, for every
node go to A)
B) for every filter associated to the node:
- is the filter is the first in the chain?
= YES: then get the data from the leaf (getDisplayData())
= NO: use the output of the previous filter in the chain and feed
it into the current filter
- if the filter is the last in the filter chain for that node, feed
the filtered data into the next renderer.
In this way, believe it or not, you can by changing a few lines in a
zcml file render a theme editor with all the AJAX stuff
http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/configuration/engines/editor/configure.zcml
or an HTML page ready to be displayed on a web page:
http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/configuration/engines/default/configure.zcml
90% of all the components are reused, simply they are wired together
differently.
A simple example with boxes (sorry, Zope 2 script, don't kill me):
[...] snip example
yes, this is the ZPT way of doing it :-)
Yes, I find ZPT is very suited for this stuff becuase it has that slot
thing. That wouldn't be possible with e.g. DMTL I think. Do CPSSkins
support other template languages than ZPT?
Tonico
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
