Re: [Zope-dev] ODBC Error
There _was_ a patch available (can't find it now, search the maillist archives) Rik ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Advice on DTMLDocument
Andy McKay wrote:
Hi there,
Well a while ago I came across a bug that I couldnt cut and paste and
object. A few people helped me out on that, thanks. Ive had a week of
squishing bugs and finally got to this one. The reason why? I was
subclassing DTMLDocument but using my own __init__ (similar to one where I
dont subclass from DTMLDocument), where I didnt fiddle with __name__. The
result was when absolute_url() was called I was getting:
http://fork:8080/code/test/ElementWithAttributes !
In your __init__ method, try putting this line in:
YourClassName.inheritedAttribute('__init__')(self, id)
This is assuming that you have the argument "id" in your __init__ method.
I've no idea whether it will solve your problem, as I haven't tried to
reproduce it.
--
Steve Alexander
Software Engineer
Cat-Box limited
http://www.cat-box.net
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Discussion Story Building Mediums
Ken Manheimer wrote: Convenient for what? If you've ever tried to support a community through a mailling list, you'll quickly notice that questions, and their corresponding answers, repeat. A lot. The problem is that while maillists are great for keeping people up-to-date on the business of the community, and for disseminating dialogue, they are not so good for building structures - for organizing content so related pieces of a story are appropriately connected. The counter that this is that Wikis, in my experience (and maybe mine only ;-), are not a good medium for discussions. There's no threading, ntoficiation or subscription, for starters... Wikis, as they stand, are not bad for organizing stories. ..agreed, but a lot of Wikis are not being used for this. It's a difficult problem. You need a decent medium for discussion, like a mailing list, which needs to automatically (and that seems _very_ hard to me) extract the necessary 'story' bits and store them in a decent story-building medium... We all sorely miss change notifications and ownership attribution, a preview button, etc - but they're better, even as they currently stand, for building longstanding artifacts than are mailling lists. And hopefully, in not too long, we'll be able to improve them, or provide something else, to do the job right. Well, the WikiDot idea is starting to crop up in my brain a bit more now ;-) And since that'd be a Swishdot skin, it'd work with the PTK, and everyone's happy and focussed on what they want to be :-) cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] I feel your Wiki Pain ;-)
| 1. No threading. On several occasions I have made comments in a Wiki | that were subsequently ignored - I guess because they got lost in the and from the WikiNG proposal: For more elaborate editorial and commentary annotations, i can see layered documents, using mixin objects that provide a tailored view on other or contained objects. The mixin would be a layer by which annotations are associated with text passages in the rendered subject document, like "the crit system":http://crit.org does for arbitrary web pages. Overall, document authors could use a particular annotation structure according to their needs. Eg, discussion objects for points which can be discussed, or brief editorial passages to give feedback, and author checkmarks for when they've satisfied or refute the suggestions, etc. Annotation is a spiffy kind of threading. I dont actually have anything against Wikis in general; I have used on very successfully for what I would describe as "document refinement", and a better annotation scheme will enhance that use of Wikis. The passage you quoted uses terms like "subject document", and at the moment I dont see that as the best model for a *debate* | 2. No personal replies. On several occasions I would have liked to From WikiNG: - Attribution of changes for tracking With attribution, you can identify and could respond directly to the author of a particular passage. It's useful for more, of course. Cool, I missed that one. | 3. No update notification. The one time I was update to | 4. Hard to keep track of many Wikis: Each wiki has its own 'whats The ability to subscribe for notification (above) and/or to track what you personally have seen, and not, is intended for this kind of thing. It would keep me happy if the notification includes a link to the new content (rather than a link to the page that contains new content). Even better, the email notification could *include* the new content. | 6. Too easy to miss the creation of a Wiki. On several occasions My plans for notification subscriptions would be hierarchical, and enable you to subscribe to events like creations of new wikis within a hierarchy - so if you subscribe at the top of the wiki space, you find out about any new wikis, while if you subscribe within the developer's part of the space, you learn about new developers wikis. Etc. (This was not covered in the WikiNG proposal - i was trying to avoid including too many details, and failed miserably anyway...-) Im happy. | 9. I never get the structured text quoting of python source right | first time. The only quoting you need to know is example:: The two colons after the word "example" indicate that this contained block is all quoted. Ill remember that. Your proposed new attribution scheme would help too. As i said in my last reply (but after you posted this, so you couldn't have taken it into account), mailling lists as they stand don't work for establishing growing structures. But Wikis don't (for me, today) work for loosely structured commentry. Quoting from http://dev.zope.org/Fishbowl/Introduction.html In some cases a mailing list will be setup for substantive, large-scale projects. Otherwise existing mailing lists can be leveraged (for now, use zope-dev for this). Perhaps I should rephrase my objection. The *real* problem is that this isnt happening - discussion is stored in Wiki pages like http://dev.zope.org/Wikis/DevSite/Proposals/XxxxDiscussion ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] HiperDOM xmlc
I'm surprised that no one responded to this. (Or maybe people did and our continual email server problems have lost it.) I'd like to congratulate Hiperlogica, because they have (ding ding ding) the _right answer_! :^) Seriously, we at Digital Creations have been quietly formulating a proposal on this since Amos put up the template proposal in dev.zope.org. I floated some trial balloons at EuroZope and it's clear there's some consensus. Our "XHTML Templates Proposal" is at: http://dev.zope.org/Wikis/DevSite/Proposals/XHTMLTemplatesProposal Since Wiki is having a tough time on the list here lately, I'll post the text in a message in just a second. To summarize, we at DC at least think that Hiperglocia is on to the right thing and we'd like to indicate support for that direction. --Paul [EMAIL PROTECTED] wrote: We (I and Hiperlogica, a company I consult with) have been developing a template renderer with similar intent to xmlc (be based on XML/DOM, allow the template to be previewed and edited using tools not aware of the format, such as xHTML editors, and enforce presentation/logic separation). As the project is somewhat on hold while we have more pressing issues, I decided to share the current (rather kludgy) prototype with the community. It is at http://www.zope.org/Members/lalo/HiperDOM/ On Mon, Sep 11, 2000 at 02:06:08PM +, Jason Spisak wrote: Zope Devers, THis is going to seem strange coming from someone who hasn't been on the list in a long time, but I was at the Linux Expo in San Jose, and sat in on a Web app talk. Lutris was in charge of the panel, and they talked about xmlc. I went to their booth and asked about it. I think it could be the best way to get hard-core python people to jump on zope's band-wagon, and stop the dtml frowning. If you who are in the know about zope have time, please read a quick bit on what it is. http://xmlc.enhydra.org Especially the tutorial: http://staff.plugged.net.au/dwood/xmlc/index.html Is there any obvious reason why Zope wouldn't benefit tremendously from this design and programming separation and pure python boost? []s, |alo + -- Hack and Roll ( http://www.hackandroll.org ) News for, uh, whatever it is that we are. http://zope.gf.com.br/lalo mailto:[EMAIL PROTECTED] pgp key: http://zope.gf.com.br/lalo/pessoal/pgp Brazil of Darkness (RPG)--- http://zope.gf.com.br/BroDar ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] DISCUSS: XHTML Templates proposal
Howdy folks. As advertised in my last email, below is our Fishbowl Proposal on a new template architecture. Some notes: 1) This mostly replaces DTML. As mentioned, the goal isn't necessarily to get DTML removed from Zope. Rather, most of the audience will see it little or none of the time. 2) This proposal has gotten more internal DC scrutiny from a requirements perspective than anything we've done. The proposal has been rewritten four times. 3) The original version of this forced the connection between reinventing the data tier (documents) and the presentation tier (templates/pages/stylesheets). We eventually found the way to decouple the connection, but we still need to write a documents proposal. 4) What this really, really needs right now is extensive user documentation with screenshots written *before* the software. This is where we got stuck. Docs are the fastest way to confront the myriad of usage details. 5) Our proposal is a little more ambitious than HiperDOM (we have a concept of "components" that are hinted to but not explained). But for now, HiperDOM is a good basis for exploring XHTML Templates. 6) I'm still not convinced template is the right word. Unfortunately I'm less convinced at any alternatives. Whatever is chosen, it must feel "normal" to the vast majority of the audience. Cheers! --Paul XHTML Template Architecture Zope should increase usability and promote separation of tiers by moving to a presentation and data architecture. Site Designers will author and round-trip presentation objects in familiar tools. Combined with the Document Architecture, this proposal establishes the fundamental content and presentation architecture for Zope. Note on status The great folks at Hiperglocia have already produced something quite similar to what is discussed here. Their Zope product is called "HiperDOM", http://www.zope.org/Members/lalo/HiperDOM/. Note On Jargon The choice of term for the presentation object has been contentious. Right now the list of choices include: template, view, page, or stylesheet. This proposal doesn't make the decision on the jargon. Rather, the tier is usually refered to as the presentation. When a choice has to be made, such as the Architecture section, Template is used as the temporary choice. Problem Zope currently has a model of DTML Documents and DTML Methods as the basic data and presentation tiers. However, this model is confusing, doesn't promote separation of tiers, and doesn't work with popular web design/authoring tools. For the presentation tier, Site Designers are faced with an idiom in which well-formed HTML is split between two "files" (standard_html_header and standard_html_footer). Also, the presentation mockups are "taken away" by programmers who insert a bunch of alien tags that don't present anything on the screen of the web design tool. Worse, DTML is fundamentally impossible to edit directly by classic tools due to the "source vs. rendered" issue. That is, when a Site Designer wants to edit a piece of DTML, they will get the *rendered* version of the DTML for editing, where all the DTML tags are expanded into HTML. In summary, there is a tremendous usability issue, both conceptual and in practice. There are additional problems: o DTML is considered a "proprietary" language o Data needs to have different presentations used under different conditions o Consulting practices need a way for customers to start seeing screen results immediately without having the programmer "steal" the templates by converting them to something alien Goals The goals of the Presentation Architecture are: o Clear separation of presentation, data, and logic with clear concepts in Zope for these tiers and audiences o Increase usability by allowing round trip presentation with common tools and familiar concepts o Allow those presentation tools to work by having well-formed markup (e.g. no separation into header and footer) o Supplant "proprietary" markup language (DTML) in presentation tier by leveraging standards (XHTML) (Note: "eliminate" isn't the target as it might not be feasible in 100% of the cases) o Match the appropriate level of capability currently in DTML usage o Simple presentation reuse within reach of standard tools Solution Zope should move to an architecture with clear separation of presentation, data, and logic, with clear concepts in Zope for these tiers and audiences. The presentation tier will get a tremendous usability increase by allowing round trip presentation with common tools. This also ensures that Site Designers finish with the same stuff they started with, meaning the programmers don't come in and cast their work into "code". The architecture should make sure those presentation tools are effective by having well-formed markup (e.g. no
[Zope-dev] AUTHENTICATED_USER.has_role !!
Hello all,
Please read the following code:
**
dtml-if "AUTHENTICATED_USER.has_role('Vorstand')"
dtml-with vorstand
hello
dtml-in neuanmeldungen_sql start=query_start
dtml-if sequence-start
pa href="vorstand/freigeben_html"Neue MitgliedsantrÃĪge sind
eingegangen!/a/p
/dtml-if
/dtml-in
dtml-in newNews_sql start=query_start
dtml-if sequence-start
pa href="vorstand/newNewsAuthoForm_html" New News are waiting for your
authorisation!/a/p
/dtml-if
/dtml-in
pa href="vorstand/bankdaten_report"Bankdaten abfragen./a/p
pa href="vorstand/mass_email_form" Send Mass Email to all
Members/a/p
hr size="1" /
/dtml-with
/dtml-if
**
The above code use to worked very OK with Zope version: Zope 2.1.6 (binary
release, python 1.5.2, linux2-x86). But now when I have upgraded to Zope
version: Zope 2.2.1 (binary release, python 1.5.2, linux2-x86), I dont find
"dtml-if "AUTHENTICATED_USER.has_role('Vorstand')"" working the way it use
to!!
Please help me with the reason for it and the way i can solve my purpose may
be in the other way.
Looking forward to hear from u as soon as possible,
Maulin Doshi
Germany
_
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Share information about yourself, create your own public profile at
http://profiles.msn.com.
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] DISCUSS: XHTML Templates proposal
On Fri, 15 Sep 2000 08:28:40 -0400, Paul Everitt [EMAIL PROTECTED] wrote: Note On Jargon The choice of term for the presentation object has been contentious. Right now the list of choices include: template, view, page, or stylesheet. This proposal doesn't make the decision on the jargon. Rather, the tier is usually refered to as the presentation. When a choice has to be made, such as the Architecture section, Template is used as the temporary choice. so-obvious-you-might-not-have-thought-of-it.. 'Presenter' Toby Dickenson [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] ZOracleDA not working with 2.2.1?
Hi *, after upgrading to latest Zope we are having problems with the ZOracleDA product. The first SQLMethod **after** a call to an external method using DCOracle to update the db, fails with an error saying that the connection is closed. (connection can't be re-opened, the only way out is to restart zope, sigh.) anybody experienced the same problem? is ZOracleDA non-compatible with Zope 2.2.1? ciao and tahnk you very much (as always), federico -- Federico Di Gregorio MIXAD LIVE System Programmer [EMAIL PROTECTED] Debian GNU/Linux Developer Italian Press Contact[EMAIL PROTECTED] A short story: I want you. I love you. I'll miss you. -- Me ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Discussion Story Building Mediums
*This message was transferred with a trial version of CommuniGate(tm) Pro* On Fri, 15 Sep 2000, Chris Withers wrote: Ken Manheimer wrote: Convenient for what? If you've ever tried to support a community through a mailling list, you'll quickly notice that questions, and their corresponding answers, repeat. A lot. The problem is that while maillists are great for keeping people up-to-date on the business of the community, and for disseminating dialogue, they are not so good for building structures - for organizing content so related pieces of a story are appropriately connected. The counter that this is that Wikis, in my experience (and maybe mine only ;-), are not a good medium for discussions. There's no threading, notfication or subscription, for starters... Clearly, i agree that the absence of those things in the wiki is a problem - i state that directly in the "problems to be addressed" section! *The* thing to understand here is that we're currently in a position where neither wikis nor maillists, in themselves, provide what we need. We need to do *something* in the meanwhile, if only to bootstrap the process so we can get to the point where we have that integration. (You'd have to ask brian and the dev folk, but i think the reason we're going with wiki is because otherwise all this talk gets **lost** - noone has the time to do the transcribing, etc. At least with wikis you can preserve your thoughts and then email interested parties!) My proposal is all about getting there - i yearn to get the time to do some of what's necessary - at least ZClass-ification so i can do the notification stuff in a clean way, because we're suffering without notification - and i'm hoping there will be a window in not too long. I think this discussion is evidence of the need, not of flaws in the proposal! Wikis, as they stand, are not bad for organizing stories. ..agreed, but a lot of Wikis are not being used for this. It's a difficult problem. You need a decent medium for discussion, like a mailing list, which needs to automatically (and that seems _very_ hard to me) extract the necessary 'story' bits and store them in a decent story-building medium... Yes - it seems _much_ easier to me to have people annotate the existing wiki (restricted, perhaps, to only adding text, not changing existing text - that's easy to implement, though we'll have to go to some effort to make it user friendly). From the WikiNG proposal: For discussion, i can see two applications of a wiki document option that allows commentators (non-authors) to only add text, not change existing text. (Zope would diff the new revision and reject it if it contains changes to existing text.) Simplest application would be accepting changes only at the end - weblog style. Next simplest would be one that allows insertions anywhere, for comments next to subject lines. (Zope could offer readers knobs for controlling visibility of annotations.) The document authors could have the privilege of editing any text, to consolidate and refine. Both applications would be useful for different kinds of discussions. Wouldn't that be cool - with notifications to interested parties, perhaps including diffs that showed the annotations, and a bit of context? (A further alluring step would be to allow notification subscription options for getting the entire changed document, and enable the email recipients to add their annotations in standard email-citation style, and send them back to zope, for it to incorporate the edits. But that would take some authentication provisions, as well as better email integration...) We all sorely miss change notifications and ownership attribution, a preview button, etc - but they're better, even as they currently stand, for building longstanding artifacts than are mailling lists. And hopefully, in not too long, we'll be able to improve them, or provide something else, to do the job right. Well, the WikiDot idea is starting to crop up in my brain a bit more now ;-) And since that'd be a Swishdot skin, it'd work with the PTK, and everyone's happy and focussed on what they want to be :-) Well, this is, tangentially, a particularly interesting point for me. I've been challenged with how to fit the WikiNG proposal into the PTK - since the PTK is a prime digital creations content management focus, management doesn't want to dilute resource assignments with other (eg, WikiNG) content-management-oriented efforts. So i have to figure out how it would fit in that frame work - maybe this suggests a way. I'm having trouble fitting my mind around it, though. Sigh. Ken [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists -
RE: [Zope-dev] I feel your Wiki Pain ;-)
*This message was transferred with a trial version of CommuniGate(tm) Pro* [I'm running out of time here, so pardon the brief responses. Make no mistake, though - i'm glad to be having this discussion! It's good to be getting this input, seeing suggestions for other ways to look at this discussion problem...] On Fri, 15 Sep 2000, Toby Dickenson wrote: I dont actually have anything against Wikis in general; I have used on very successfully for what I would describe as "document refinement", and a better annotation scheme will enhance that use of Wikis. The passage you quoted uses terms like "subject document", and at the moment I dont see that as the best model for a *debate* Do you feel that weblogs are bad models for debates? I think they're pretty good least-common-denominators. I would probably prefer the kind of annotation-based thing i described in my last message (and began to sketch in the WikiNG proposal) for collaborative generation of documents, but i can see the place for weblogs, just as i can see a place for network chats. With adequate integration of email (for notification and response), i see them as better than just email... The ability to subscribe for notification (above) and/or to track what you personally have seen, and not, is intended for this kind of thing. It would keep me happy if the notification includes a link to the new content (rather than a link to the page that contains new content). Even better, the email notification could *include* the new content. Different options for different purposes - but we need at least notification! But Wikis don't (for me, today) work for loosely structured commentry. Quoting from http://dev.zope.org/Fishbowl/Introduction.html In some cases a mailing list will be setup for substantive, large-scale projects. Otherwise existing mailing lists can be leveraged (for now, use zope-dev for this). Perhaps I should rephrase my objection. The *real* problem is that this isnt happening - discussion is stored in Wiki pages like http://dev.zope.org/Wikis/DevSite/Proposals/XxxxDiscussion I think we all agree this is a problem. We seem to have found a short term solution - though i'll tell you that with time constraints, i won't immediately have time to incorporate the points raised in the documents. Ken [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZOracleDA not working with 2.2.1?
[EMAIL PROTECTED] wrote: Hi *, after upgrading to latest Zope we are having problems with the ZOracleDA product. The first SQLMethod **after** a call to an external method using DCOracle to update the db, fails with an error saying that the connection is closed. (connection can't be re-opened, the only way out is to restart zope, sigh.) anybody experienced the same problem? is ZOracleDA non-compatible with Zope 2.2.1? ciao and tahnk you very much (as always), federico -- Federico Di Gregorio MIXAD LIVE System Programmer [EMAIL PROTECTED] Debian GNU/Linux Developer Italian Press Contact[EMAIL PROTECTED] A short story: I want you. I love you. I'll miss you. -- Me Please try using DCOracle 1.3b1 to see if that fixes things; there are some bugs with connection handling in versions of DCOracle where if the connection dies it will not recover. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] HiperDOM xmlc
On Fri, Sep 15, 2000 at 08:21:21AM -0400, Paul Everitt wrote: I'm surprised that no one responded to this. (Or maybe people did and our continual email server problems have lost it.) Me too. I'd like to congratulate Hiperlogica, because they have (ding ding ding) the _right answer_! :^) Thank you :-) We feel good about this answer too. Seriously, we at Digital Creations have been quietly formulating a proposal on this since Amos put up the template proposal in dev.zope.org. I floated some trial balloons at EuroZope and it's clear there's some consensus. Glad to know that. Our "XHTML Templates Proposal" is at: http://dev.zope.org/Wikis/DevSite/Proposals/XHTMLTemplatesProposal It is not linked on the Proposals FrontPage... -- Anyway, at least for HiperDOM I feel comfortable with the word "template" because that's what it is about. The two primary motivations for the design are: * You can create the layout with any XML-compliant editor; if the template is xHTML, you can use a XHTML-compliant WYSIWYG tool. Or, thanks to the modern XML technology, you can use a WYSIWYG HTML tool and pass it trough a SGML-XML filter to get xHTML. Using specialized webdesigners with Zope project has been one of the biggest pains in Zope development; we have to take the sometimes ugly code generated by the tools they use, usually clean it up, then insert the DTML tags in it. Making changes to the design is a nightmare. * The template looks like the rendered page; if you don't want to fire up Zope, or if the application logic is not yet finished, you can preview the layout by simply loading the template in a browser. These goals are similar, but not identical to the ones in the proposal. Still, some parts of the proposal felt like extracted rigth out of my mind :-) I don't feel good about calling the layers "document" and "view" or "presentation" and "data" because the "view" is not strictly presentation code; invariant (static) parts shared by all pages rendered with that template can be in the template. As much as we all like to talk about "Web Applications", this is not exactly like "normal" application design, where you can draw a clear line between presentation and data (or model/view). -- The only thing I _don't_ feel good about this kind of template is that, in practice, we will probably lose the benefits of things like dtml-var standard_html_header - meaning, when you want to change the header of your site, you'll have to edit all your templates. Of course a site where this is a problem still _can_ use "includes" like standard_html_header, but I believe most won't. []s, |alo + -- Hack and Roll ( http://www.hackandroll.org ) News for, uh, whatever it is that we are. http://zope.gf.com.br/lalo mailto:[EMAIL PROTECTED] pgp key: http://zope.gf.com.br/lalo/pessoal/pgp Brazil of Darkness (RPG)--- http://zope.gf.com.br/BroDar ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] aq_.* names reserved?
Steve Alexander writes: I'm hacking around with some external methods called aq_containment and aq_context. I just found out that I can't call them from DTML. I can call them from the URL line of a browser just fine. If I rename them to a_containment and a_context, they work from DTML. I guess there's something in Acquisistion.c that reserves all aq_.* names. The code is in "AccessControl.ZopeSecurityPolicy.validate". It allows access to "aq_explicit" and "aq_parent" only. I am a bit astonished that URL traversal is possible. Probably, this was not intended. Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] DISCUSS: XHTML Templates proposal
[EMAIL PROTECTED] wrote: IMHO, view, page, and stylesheet don't make the grade due to conflicts/confusion with unrelated technologies (e.g. MVC, "server pages", CSS, etc.). On the other hand, reading the "What is styles?" material at: http://www.w3.org/Style/ ...makes me think that the goals of the people using these things (site designers) are the same as the goals of the audience described for stylesheets. That is, these are things that control the presentation. --Paul ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
