- Zope-Dev - Zope lists

A few Questions
by Keith Larson 28 Sep '00

28 Sep '00

Hello I just joined so sorry if you have answered these before or if it the right place to ask but : I have a 4 new sites in Zope that is mirrored on two servers and load balanced. A third server is for qa and editing in Zope. Now , is there a way to have a python script go into Zope and delete all the acl users and pack the database ? ( for when a script copies the Data.fs into the live environment) Also is it possible to have the management only run via :8080 and be an error is tried via http://foobar.com/manage The apache is built via pcgi and redirects. I would like to be able to have apache serve out Zope on one nic and kill the port 8080 and the other serve all ports . If you have any ideas please email and I will get more in depth as far as I can anyways. Keith Larson Web Developer klarson(a)spatial.com

1 0

DISCUSS: XHTML Templates proposal
by Paul Everitt 28 Sep '00

28 Sep '00

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 separation into header and footer). Zope should supplant "proprietary" markup language (DTML) in presentation tier by leveraging standards (XHTML). It might not be possible to 100% remove DTML in 100% of the cases, but it should be a rarity instead of the rule. The new presentation architecture should match the appropriate level of capability currently in DTML usage. For instance, common idioms like browse-by-batch should be possible. The new presentation architecture should leverage this new XHTML approach, XSLT, and perhaps DTML. Site Designers want simple reuse of content within reach of standard tools. For instance, the Site Designer wants a standard copyright "asset" on the bottom of every page. The presentation architecture should not know about the details of the data tier or the logic tier. Rather, the presentation architecture will just provide a view onto the model expressed in the object system, where the model uses standard APIs. A **page** is the result of applying presentation to data in the object system. A page is a particular result of a URL when viewed under certain conditions. Ultimately, data such as documents will be matched to a presentation according to implicit and explicit rules. The simple case will be simple (invisible); the complex, custom cases will be straightforward. In the initial rev of the architecture, only one presentation will be implicit for a resource. Other presentations of that resource will require explicit traversal to obtain them. Architecture The Presentation Architecture initiative will deprecate the presentation aspects of DTML Document and DTML Method objects. Instead, a new kind of object, code-named Template, will be used. Templates have two varieties: XHTML Templates for Site Designers that use HTML layout tools, and XSLT Templates for XML programmers requiring high-end processing control. Site Designers will create XHTML Template objects that control look-and-feel across numerous content resources in a site. The Template object will allow multiple formats. XSLT will be used for high-end presentation oriented towards XML programmers. DTML might be retained as a template format for certain presentation tasks. However, the focus of the new Template architecture will be a new format based on XHTML. This XHTML Template will be focused on giving Site Designers round trip presentation authoring using the dominant tools such as Dreamweaver. XHTML Templates will be complete, well-formed HTML that look like a resource will look when the XHTML Template is applied to it. There will be no "source vs. rendered" issue. In this Presentation Architecture, Site Designers can start mocking up a Zope site by editing real HTML and graphics in Zope from the very beginning. There will be nothing Zope-ish in what they are doing. As the mockups turn into live content, certain regions of the XHTML Template will be "connected" to the live content. This is done by indicating the object data that will be inserted when the XHTML Template is applied to content. However, there will still be sample content in the XHTML Template that lets the presentation task continue. This sample content gets discarded when the XHTML Template is applied to a piece of content such as a Document; the connected regions in the Document replace the sample content in the XHTML Template. These connectors will exhibit themselves by simply adding Zope attributes to existing, valid HTML tags. These attributes will follow the XHTML extension facilities of namespaces and will be silently preserved by authoring tools. The attributes indicate that this region of the XHTML Template will be replaced by content from the Document being viewed and from other content in the object system. The connectors will allow different "modes" that provide the alternation and conditional facilities present in DTML. These modes are just simple attributes to extend the semantics of existing XHTML tags. The XHTML Template architecture will facilitate re-use by allowing blocks in the XHTML Template to be named as a (component/library/asset) block. As the Site Designer authors and updates the block of XHTML, Zope saves the named block as a separate object in Zope. This named object can then be used in other XHTML Templates. Internally, XHTML Templates will use the standard XML parser in Zope instead of maintaining a separate parser. It is possible that the XHTML Template will be broken into a DOM and stored in the ZODB as separate database objects for different nodes. Scope Defining the document architecture has been moved to a separate proposal. XHTML Templates will be focused on the presentation needs and skill level of Site Designers. Highly complex presentation tasks that blur into programming tasks will be left to the domain of XSLT Templates. Thus, the XHTML presentation format is scoped by focusing on usability for the Site Designer, non-programmer audience. XSLT Templates will be aimed at XML professionals and at highly-complex presentation layout needs. The XHTML Template will not do transforms. If a Site Designer needs to enforce any rules on markup in content, some other step will have to be taken to ensure the Site Designer is handed acceptible, "stripped" content. DTML has permitted the rendering on non-markup such as SMTP messages. The XHTML Template does not try to satisfy this job. Other objects, such as DTML Methods or Python Methods, would have to handle this chore. Clarifying the "DTML namespace" confusion felt by authors is not in the scope of this proposal. While providing and documenting integration with a few important tools will be done, this project won't integrate every tool. Later projects will deal with the rules that allow implicit binding of presentations to resources. Risks *Role of DTML*. What is the role, if any, of DTML in the future? *Replacing magic with magic*. If too much magical stuff happens (e.g. how data gets implicitly bound in different ways to presentation, the component idea creating new stuff in the background) for people to handle, we're just replacing the confusing old magic with the confusing new magic. Deliverables The first deliverable will be rich user documentation. This will supplement use cases. The second deliverable will be a documented API and explanatory text to go along with the API. The third deliverable will be an alpha-quality implementation on a branch.

5 5

MySQL : help !
by jdiebold＠imexpert.com 28 Sep '00

28 Sep '00

I need the binarie file named _msql does anybody got it (for any Linux)? Because I can't build this file : I've got too many errors .... Thanks in advance Jérôme DIEBOLD

2 1

ZClass + ZSQLmethods bug in 2.2.2?
by Alexander Schonfeld 28 Sep '00

28 Sep '00

Hi, I've seen lots of ZSQLmethods patches and such and tried a few of them under 2.1.6, but thought upgrading to 2.2.2 would fix this problem. It didn't. Basically: 1. Create a ZClass 2. Inside create a DTML method and ZSQLmethod 3. from the dtml method call the ZSQLmethod 4. do a <dtml-with "myClassInstanceObj"> <dtml-var myMethod> </dtml-with> 5. get a Unauthorized error no matter what the access privileges are set to This is with the "MySQLda". Is there a newer MySQLda somewhere that fixes this? Or some patch (that works with 2.2.2???)?! Running 2.2.2 from source... now with less hair... Sincerely, Alex. ================================ Zope Error Zope has encountered an error while publishing this resource. Unauthorized You are not authorized to access sqlGetValue. Traceback (innermost last): File /Zope-2.2.2/lib/python/ZPublisher/Publish.py, line 222, in publish_module File /Zope-2.2.2/lib/python/ZPublisher/Publish.py, line 187, in publish File /Zope-2.2.2/lib/python/ZPublisher/Publish.py, line 171, in publish File /Zope-2.2.2/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: testmeth) File /Zope-2.2.2/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: testmeth) File /Zope-2.2.2/lib/python/OFS/DTMLMethod.py, line 172, in __call__ (Object: testmeth) File /Zope-2.2.2/lib/python/DocumentTemplate/DT_String.py, line 528, in __call__ (Object: testmeth) File /Zope-2.2.2/lib/python/DocumentTemplate/DT_With.py, line 146, in render (Object: testcrp) File /Zope-2.2.2/lib/python/OFS/DTMLMethod.py, line 168, in __call__ (Object: craptest) File /Zope-2.2.2/lib/python/DocumentTemplate/DT_String.py, line 528, in __call__ (Object: craptest) File /Zope-2.2.2/lib/python/DocumentTemplate/DT_In.py, line 633, in renderwob (Object: sqlGetValue(tableId='Artist',columnId='Name',keyId='3f69016017c39d5da0a1d60d0a98dbed55d46414')) File /Zope-2.2.2/lib/python/DocumentTemplate/DT_Util.py, line 331, in eval (Object: sqlGetValue(tableId='Artist',columnId='Name',keyId='3f69016017c39d5da0a1d60d0a98dbed55d46414')) (Info: sqlGetValue) File /Zope-2.2.2/lib/python/OFS/DTMLMethod.py, line 194, in validate (Object: testmeth) File /Zope-2.2.2/lib/python/AccessControl/SecurityManager.py, line 139, in validate File /Zope-2.2.2/lib/python/AccessControl/ZopeSecurityPolicy.py, line 209, in validate Unauthorized: (see above) 1010011010101001101010100110101010011010 0 Digital Garage　デジタル車庫　:) 1 Alexander Schonfeld 0 alex(a)garage.co.jp - pear - 03-5454-7219 1 http://www.zope.ne.jp/ http://www.garage.co.jp

1 0

ZModules - A loaded gun
by Kapil Thangavelu 28 Sep '00

28 Sep '00

i wrote up an interface to allow for module registration in the dtml namespace, _ its got major caveats, but it might be useful for some. at the moments its just a stop gap till the new python methods come along. at the moment if just allows for people to write more code in dtml:( or ttw python methods. it might be useful to allow ttw developers access to some modules without allowing them use of XXXpython_methods since the configuration file that defines the imported modules resides on the FS. an example use <dtml-let y="_.poplib.POP3('mail.earthlink.net')"> <dtml-var "y.welcome"> <dtml-var "y.user('kthangavelu')"> <dtml-var "y.pass_('ipc9@longbeach')"> <dtml-var "y.stat()"> </dtml-let> and the response +OK EarthLink POP server (version: EL_3_10 ) at pop04.earthlink.net. <21615.970119687(a)pop04.earthlink.net> +OK Password required for kthangavelu. +OK kthangavelu has 0 messages (0 octets). (0, 0) personally i thinks it better to just pass the module off to a python method and let it do the work. real coding in dtml is heinous, maybe even a crime against humanity. how it works. it reads a module configuration from the FS. fmt is currently module_name: class_name, class_name it tries to import the module and than place the module in the namespace dict. - usual python discovery rules apply (python_path, curdir) it sets the magic key __allow__access_to_unprotected_subobjects=1 on all imported modules. it allows you to define classes in modules those you want to interact with. defining those classes allows you to interact meaningfully with instances otherwise zope's security policy will bump you because the container doesn't define proper permissions or the magic key. caveats: it hasn't had much testing, i did it as proof of concept and because i had an itch. you can't accces any attributes of any object that doesn't define __allow__access_to_unprotected_subobjects=1 an example where this is a pain, are getting filehandles back from libraries, like urllib.urlopen (note. urllib is not ts). BE VERY VERY WARY OF THREAD SAFETY ISSUES it might be very much like holding a loaded gun to your server;) possible improvements: allow for nested modules & classes ? if people think this is useful enough, i'll package it up as a product. installation. create a directory in your products folder (mines called ZModules) drop in the attached file. write a configuration file restart zope sample config file. poplib:POP3 mimetypes Cheers Kapil # DISTRIBUTED UNDER THE ZPL # Author kthangavelu(a)earthlink.net # made for zope, www.zope.org import App import App.Common import Globals import os from DocumentTemplate import DT_Util from DocumentTemplate.DT_Util import d from string import strip,split,replace config_path=os.path.join(App.Common.package_home(globals()), 'zmodules.config') fh = open(config_path) modules_list=fh.readlines() #print 'read config file' counter = 0 for module in modules_list: module = strip(module) module = replace(module, '\012', '') if len(module) <= 1: continue module_config = split(module, ':') if len(module_config) > 1: classes = split(module_config[1], ',') else : classes = [] module = strip(module_config[0]) module_name = module[:] try: exec('import %s'%(module)) except: continue loaded_mod = eval(module) s_classes = classes[:] for class_name in classes: class_name=strip(class_name) if len(class_name) == 0: continue try: getattr(loaded_mod, class_name).__allow_access_to_unprotected_subobjects__=1 except: s_classes.pop(s.index(s_classes)) d[module_name] = loaded_mod loaded_mod.__allow_access_to_unprotected_subobjects__=1 print 'success: loaded module %s and classes %s'%(module_name, s_classes)

1 0

structure text
by nw_moriarty us 27 Sep '00

27 Sep '00

I asked, some time ago, why the StructuredText.py did not work with the example provided in the triple quotes but my email has been patchy. Did anybody reply as to why the :: does not work all the time? Nigel ------------------------------------------------------------ --== Sent via Deja.com http://www.deja.com/ ==-- Before you buy.

1 0

bouncing e-mail
by Tom Deprez 27 Sep '00

27 Sep '00

Hi, Has somebody noticed some problems with my e-mail? It looks like my account was turned of at zope-dev. Since I didn't do it, it must be an automatic thing. So my q'n had someone of you problems with my e-mail? Tom.

1 0

Zope Error message
by Andy McKay 27 Sep '00

27 Sep '00

So now I need to change it so most normal errors (such as 404) are handled by standard_error_message. So I went to HTTPResponse.py and found this: def _error_html(self,title,body): # XXX could this try to use standard_error_message somehow? I gather someone smarter than me has tried this before. Before waste a day going down this path, does anyone have any advice? -- Andy McKay, Developer. ActiveState.

2 1

Proposal: Local ZClasses
by Jay, Dylan 27 Sep '00

27 Sep '00

Problem: Encapsulation for plugable brains and other purposes are too hard. ZClasses are a global kind of thing that requires going into a separate area of the site which you have to have permission to use. Also I find that I evolve my solutions. I will produce something in folders that works for what I want and then try and generalize it into ZClasses later. However if my solution in the folders itself wants to use classes then the only choice I have is external methods or ZClasses. Solution: Local ZClasses: A ZClass that can be created in any folder and is available with the acquisition path. It can then be used for pluggable brains with sql methods also where the Class can be reached in the acquisition path. e.g. I have a few fancy display methods that I use for display results of a sql query for getting phone contact info e.g. create a vCard for each entry. I create a ZClass with a property sheet matching those returned by the sql method. I create my display methods within this ZClass. I associate the sql method with the ZClass. I call the query with dtml-in. Within the loop I have access to the ZClasses methods. Second solution: Prototype objects: A folder is an object with methods etc. A ZClass is not much different except that it has a constructor and a list of the properties that are always there. With a bit of syntax we could make a local folder into a local ZClass. We just need a method that says, using this folder as a prototype, create me a new object. e.g. <dtml-call "REQUEST.set('myobj',_.new(users_class, name='Dylan'))">. This would effectively make a new non persistent object that inherits from the prototype folder I guess. This could be done with plugable brains as well by just specifying the folder as if it was a class and then new objects would created for each row. If you enable the ability to make these prototype objects persistent then you get the side effect that you can create symbolic links. You can access a whole other acquisition path using inheritance. In fact you could have a property of a folder which is its inheritance objects which you could change over its life time. In fact any object could have this property could affect an objects behavior without moving the object or modifying its underlying classes. Also it would mean overload any kind of object. Just create a folder that inherits from an object or class and add methods. Personally I think the second solution has a lot of merit. What do others think?

1 0

New Proposal: PersistentBlob
by John D. Heintz 26 Sep '00

26 Sep '00

Hi all, Yesterday I put up a new proposal on the http://dev.zope.org site that documents my vision of PersistentBlob. The main idea is the be able to mark blocks of strings (text or binary) content for storage in a file system as individual files. (Or blobs in a relation table.) The two motivations for this are keeping a ZODB FileStorage small and exposing blocks of string content to external processes (i.e. full-text indexing). Thanks for taking a look. John -- John D. Heintz DataChannel, Inc. Senior Engineer 512-633-1198 jheintz(a)isogen.com

1 0