September 2000 - Zope-Dev

some suggestion..
by cs＠comlounge.net 28 Sep '00

28 Sep '00

Hi! While trying to code some python Product I had the need for extending manage_delObjects in some Folderlike object. I simply want to call the the ObjectManager's version of it and then do my own stuff afterwards (like deleting some other dependant objects). Unfortunately when calling manage_delObjects() one cannot decide if some error occured or everything went ok as in both cases I get back some string (be it some html formatted error message or the manage_main dialog). So what about splitting these methods in two, e.g. one _delObjects() and one manage_delObjects(). The first one would the the actual work like testing for error conditions and deleting the objects and the other one would be the one called by the management interface. manage_delObjects() would then call _delObjects() and checks for errors afterwards generating some error message or the next dialog. The errors could then be passed via exceptions or similar methods from _delObjects() to manage_delObjects(). This would make subclassing a lot easier and would be at least a start in separating layout from logic. Just an idea :) cheers, Christian PS: Maybe it would even make XMLRPC more usable as there I also get back only html formatted error messages instead of something making more sense for a script (like an error code or something). -- COM.lounge http://comlounge.net/ communication & design cs(a)comlounge.net

1 0

XHTML Templates comments from the peanut gallery
by Spicklemire, Jerry 28 Sep '00

28 Sep '00

>> Paul Everitt wrote: >> o Allow those presentation tools to work by having well-formed >> markup (e.g. no separation into header and footer) > to which Chris Withers replied: > Hmmm... I wonder how refactoring, which _header and _footer were really > useful for, will happen now... The most obvious problem was that _header + _footer idiom was presented in a way that resulted in tags being opened in _header, and cosed in _footer. I personally adopted this as a "Good Example" of how to use Zope, and had created quite a mess for myself before a post on one of the lists pointed out how genuinley horrible this is, from a well-formedness point of view. Duh! Still, it's just not that big a trick to factor out the HEAD tag as a monolith, and insert references to other pieces parts inside the HTML tag that used to be included in _header, but now appears as a "hard coded" element in the "presentation" document. On the surface it may look like you wind up with things more scattered about, but as far as factoring, it's manageable. Even in the worst case, my _headers tended to be made up of references to other elements that had been factored out anyhow. Same applies to _footer, and other items. So, there is a change in mind set, but not on the scale of a tectonic shift. If we can get here: >> Zope should move to an architecture with clear separation of >> presentation, data, and logic, with clear concepts in Zope for these >> tiers and audiences. it will certainly be worth any adaptation that need to occur. However, I am a bit puzzled regarding: >> 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". Folks really do want to use Dreamweaver et. al. to layout Web "pages", that's verifiable. The proposal to meet this need is to "let the designer see what they expect, but swap in a Zopification at run time". That may be enough to fulfill the requirement, but it looks pretty pale from this end. There is a very narrow band of "graphic stuff" that won't need to be thoroughly Zopified ("cast into code") in the process of adapting a designer's work. Most of the stuff that makes a Web site useable, such as menus, navigation bars, etc. must be entirely transformed into lists (tables) and scripts (DTML, Python methods, whatever) on the way to maintainability nirvana. As for real Web Applications, the range is even thinner. The illusion of "round trip editing" may be enforcable this way, and there may in fact be a long range plan to convert to a real implementation, based on DOM, XSLT. If that's sufficient to get past the "let me do it my way" objections of temperamental "Artists", so be it. >> 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. This is easy enough to provide for, but the proposal seems to imply that a "hard copy" of each "asset" will be inserted in the designed "page", but a Zopification of that asset will appear in the served "page". Of course that's quite feasible with Zope, change an "asset", all instances will be composed, at serve time, to display the updated "asset". Then, all the designers have to do is go back, and hand edit every "dummy" instance that's just there to keep them contented, because those "hard copies" aren't going to be updated, since they are not accessible by Zope. What has been gained here? >> Site Designers will create XHTML Template objects that control This sounds great, but are these the same folks who can't live without their Dreamweaver? Now they're going to design XHTML Templates? My guess is that the designer will create an HTML "page", and a Zope jockey will tuck some references inside some tags that point to other goodies that were concocted far from the gaze of the "designer", and essentially override the original. Hopefully the designer won't notice those new little gotchas hiding in the tags, and will leave them where they are. Can you say "element level locking"? >> 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. Except for the "dummy assets" which will only be an "artists conception" of the rendered "resource", if I'm getting this right. >> 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. Will it be up to the designer then, to see that "blocks" are well formed? That shouldn't be too much to ask. So Zope will recognize the "block" objects, update them when they are changed, and make them available to the designer for reference in other "pages"? So now the designer has mastered the concept of something resembling a "Serve Side Include"? And is this all going on in Dreamweaver, or GoLive, or wherever the designer lives? The concepts sound fabulous and amazing, but as you can see, there are points for clarification. I truly hope this can be done, but unless the editor environments simultaneously develop some remarkable new abilities to interpret a DOM, and interact with a live server instead of by writing directly to local copies of HTML files, it sounds pretty tough. Always Zopeful, Jerry S.

1 0

Namespace trouble
by Martin Grönemeyer 28 Sep '00

28 Sep '00

Hello everyone, if've had little namespace problems with this code-snipped (dtml-method): <dtml-with REQUEST> <dtml-in "[1,2,3,4,5,6,7,8]"> <dtml-call "REQUEST.set('row_index',_['sequence-index'])"> <dtml-var "REQUEST.get('row_index')"> <dtml-var row_index> </dtml-in> </dtml-with> This produces an output like this: 0,0,0,0,0,0,... The zero is the first index set by REQUEST.set... The running index isn't reflected into the current namespace. Why not ? It know it depends on <dtml-with REQUEST>, but it didn't find an answer. Thanks for any comment, martin

1 0

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