[Zope-dev] HiperDom-0.4.0-DC released
Hi all, I created a special release of HiperDom 0.4.0 (versioned as 0.4.0-DC), with fixes and additional features. This release is ment for experimentation with new features added by Digital Creations, and we'd appreciate feedback on these. The README attached to this email lists all differences. You can download the release from: http://www.zope.org/Members/mj/HiperDom Note that all fixes to HiperDom problems have been checked into the HiperDom CVS tree, a future release of HiperDom will include these fixes. -- Martijn Pieters | Software Engineer mailto:[EMAIL PROTECTED] | Digital Creations http://www.digicool.com/ | Creators of Zope http://www.zope.org/ - This is the Digital Creations' release of HiperDom 0.4.0. Differences with the Hiperlogica release are listed below. This release depends on Zope 2.2.5 for correct XHTML output of base and image tags. This release is ment for experimentation with new features added by Digital Creations. HiperDom is a new template system for Zope, based on XML and DOM. It depends on the PyXML library, version 0.6 or newer. Consult the HelpSys for info on using HiperDom Templates. The "official" HiperDom homepage is at http://www.zope.org/Members/lalo/HiperDom where you will also find the HiperDom Wiki (the "official" place for discussion, bug reporting and embrionary documentation). Discussion about the development of HiperDom takes place on the "HiperDom Wiki":http://dev.zope.org/Wikis/DevSite/Projects/HiperDom. Differences with the Hiperlogica 0.4.0 release: - The calling interface has been refactored; HiperDom templates now behave exactly like DTML Documents. This fixes the trailing slash problem in base tags inserted into XHTML documents. - Inclusion of non-callable objects (like Image objects) has been fixed. - Names can now also be paths, so you can include references to objects normally not in the acquisition path. Example:: - XHTML output of empty elements will include an extra space before the slash to ensure compatibility with older browsers. - A new directive, 'call', allows calling of objects without including their return values. This is especially suitable for methods that manipulate the RESPONSE headers or have other side-effects. - A new directive, 'include', allows inclusion of other HiperDom templates into the DOM at render time. - The DataObject object is not included in this release. - Some non-relevant files have not been included (exemplo_pt.html and HiperDom.latte). Issues with this release can be listed on the "ImplementationIssues page":http://dev.zope.org/Wikis/DevSite/Projects/HiperDom/ImplementationIssues. Feedback is greatly appreciated!
[Zope-dev] PythonScripts
I looked at ZopeCVS's PythonScripts. I mostly like it -- with the following exceptions: * Namespace binding It does not yet work, apparently: In DTML, I have: in PythonScript "pyscript": return _['a'] and I get: "KeyError: a" * Try it It is very nice, that such a "try it" exists! However, as I am in Python, I would like to use Python expressions as argument values. Currently, the values are treated as strings. Default argument values are displayed as part of the argument name. If the values in the "try it" tab were Python expressions, the default values should be used to preset the value fields. * Preventing creation of large sequences Apparently, you try hard to prevent the creation of large sequences. For a malicious user, it is however quite easy to counter you measures: either with a "while" loop or with a nested sequence repetition. To make it safe, you would probably need to limit the total complexity of all objects (together) that are created in the script (or other scripts called by this one). Alternatively, you could document that various security issues remain, if PythonScripts are made editable through the web. * Import control I know that I can control what modules (and names) can be imported in PythonScripts by providing an __access_to_unprotected_subobjects__ definition *in the* module. However, this is a global control affecting all PythonScripts in an installation. I see the demand for more localized control, e.g. that a script not editable through the web should import modules that are not safe for use by anonymous users. 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] DTML Documents == DTML Methods that are anchored?
You should look through the mailing lists there is generous amounts of answers to this. For me the two sit philosophically linked in the acquisition model. Acquisition is partially about actions working in environments, with the environment decribing the quality of the result. You can think of a DTMLMethod as an action, who itself has no substrate, i.e. properties, and DTMLDocuments as substrate, i.e. it contains properties etc, for example background colour, types of animals, whatever. One can then throw a method around into different environments, i.e. call it on documents, and one will get a result that is dependent on that environment(document). It is also nice that environments can acquire from their surrounding too, so you should think of acquisition in DTMLDocuments as been for more and more global properties as one moves out, eg: a company logo. Whereas acquisition for a method is to actually acquire an environment to work in. Well that's the way I view it, and it helps. Matt On Sat, 30 Dec 2000, The Doctor What wrote: > What are the differences between DTML Documents and Methods > internally? I was just thinking about the problems every new user > (and experienced users, every so often) have regarding DTML > Documents vs DTML Methods. > > Aren't they really the same except that Documents are anchored (ie, > don't allow aquisition from the caller, but only from the location > of the Document)? > > If that is true, couldn't they be simplified as a (example name) > DTML Object that had an "anchor" flag? > > Just a thought. > > Ciao! > > -- > So Buddha walks into a pizza parlor and says: "Hey, make me one with everything." > > The Doctor What: Need I say more?http://docwhat.gerf.org/ > [EMAIL PROTECTED] KF6VNC > > ___ > 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] DTML Documents == DTML Methods that are anchored?
What are the differences between DTML Documents and Methods internally? I was just thinking about the problems every new user (and experienced users, every so often) have regarding DTML Documents vs DTML Methods. Aren't they really the same except that Documents are anchored (ie, don't allow aquisition from the caller, but only from the location of the Document)? If that is true, couldn't they be simplified as a (example name) DTML Object that had an "anchor" flag? Just a thought. Ciao! -- So Buddha walks into a pizza parlor and says: "Hey, make me one with everything." The Doctor What: Need I say more?http://docwhat.gerf.org/ [EMAIL PROTECTED] KF6VNC ___ 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 )
