September 2000 - Zope-Dev

Re: [Zope-dev] HiperDOM & xmlc
by Shane Hathaway 18 Sep '00

18 Sep '00

pje(a)telecommunity.com wrote: > Suppose that you could add to any element an hdom:asset="nameOrPath" > attribute. When saving a template containing such elements, the content of > the named document is compared against the tagged block in the template > being saved, and against the previous version of the template. If the > content has not been changed since the last version of the template, but > the asset itself is different, the named portion is silently replaced with > the new version of the asset. If the content *has* been changed, the > author is given the option of updating the named object with the changed > contents, undoing the change, attempting to merge changes, etc. If an > asset is named in a template being saved, but no such object exists, it is > automatically created as a peer of the template (and of course it can be > moved higher in the tree for acquisition without breaking the reference). > And last, but not least, if one is creating a new template, and the named > element is empty, it is replaced with the referenced asset. (Actually, in > practice you'd do almost all of this not by copying XML fragments but by > using DOM objects that were symlink-ish.) Great minds think alike. This is exactly what Jim came up with when we were presenting this idea. In fact, I like "asset" better than "component". IMHO the "asset" tag should always be generated by the server, not by a designer, so that it can contain the full physical path to the target object. > The tricky bit is managing UI handling for what happens when they save > their page. WebDAV and FTP are all very well and good, but unfortunately, > they don't have any convenient way to pop up a dialog box and let you > prompt the user to replace/update things. You'd have to have this do some > sort of workflow notification, or a way for the designer to go in and > review what things might need to be updated. Right. When a designer saves the page back to the server, it might contain pieces from 10 different places. My initial reaction is to say that the only assets the server should accept are the assets located within the target object. Shane

1 0

Re: [Zope-dev] I feel your Wiki Pain ;-)
by Simon Michael 18 Sep '00

18 Sep '00

Chris Withers <chrisw(a)nipltd.com> writes: > I wonder what Simon Michael is up to nowdays? I have been visiting family.. I'll be back in the US next week. Great thread here. I also feel this pain, grovelling around between wiki, mailing list, newsgroup, message board, etc. I wonder if we should expose all messages, edits and annotations in some RSS/RDF-like format, for easier syncing/monitoring/indexing of the different forums and to faciliate alternate UIs. -Simon

1 0

Can ZPatterns Plugins be used separately?
by Kevin Howe 18 Sep '00

18 Sep '00

Hi, I'm wondering if it is possible to use ZPattern Plugins in a non-ZPatterns Product? Allowance for Plugins would be a very useful feature in many applications. kh

2 2

HiperDOM & xmlc
by Spicklemire, Jerry 17 Sep '00

17 Sep '00

Hi Zope Gurus, After looking over all the HiperDOM / xmlc stuff I think I'm starting to "get it". I'll just summarize the things that ring especially true for me, with some comments Re. letting HTML "Page" Designers use familiar tools: "Note that XMLC depends on legal HTML/XML markup that will not interfere with other uses of the tags. HTML browsers are required to ignore tags and attributes that they do not understand or use." http://staff.plugged.net.au/dwood/xmlc/dynamic.html#sample_html So, xmlc seems to be an alternative solution to the original motivation behind embedding DTML within HTML Comment / Server Side Include style tags. The convention exists, so that's a way Zope can fit in to Zope-unaware HTML environments. "But using external fragments ("includes") is not a natural idea for web designers. One of the main points of this fuss is to allow them to create the templates in something like Dreamweaver." http://lists.zope.org/pipermail/zope-dev/2000-September/006899.html However, it's hard to imagine that Web "Designers" can survive the XML wave without becoming comfortable with inclusions. Doesn't the current version of Dreamweaver have "folding" capability to "collapse" inclusions, such as Javascript, and even entire tables, so only a pair of tags is displayed on the screen? No doubt this feature will quickly become a "must have" item, as fans of folding editors can attest. The verbosity of XML demands some solution, and the usability of "folding" is well proven. At that point the real question is, "If xmlc and DTML can both be easily included, collapsed, etc., what sort of power and flexibility might be lost with an xmlc-ish convention?" Re. changing Bad Habits "The current "header/footer" fragments are not optimal wrt. modularization, as tightly coupled stuff ("footer" must close everything that "header" opened) is separated into different objects." http://lists.zope.org/pipermail/zope-dev/2000-September/006907.html Certainly breaking well-formedness by placing HTML, HEAD, BODY, etc. in standard_html_header, and closing HTML, HEAD, BODY, in standard_html_footer was a dead end. But it's not at all difficult to package up as inclusions all the other pieces-parts, while keeping HEAD, BODY, etc. within a monolithic "wrapper". No doubt a multitude of other common DTML sins can likewise be mended with diligent well-formedness. "Of course you can already use "includes" which are valid XML, such as a single row or cell of a table (for example, the navbar of a complex site)." http://lists.zope.org/pipermail/zope-dev/2000-September/006899.html The perceived "problem" with this approach is that the Designer sees "nothing" where these items will be inserted. Actually, in edit mode they can see a dtml-var tag. Yes, this can be confusing for Designers, but use of inclusions is not really new, nor isolated to Zope. Anticpating "the inclusion thing" will remain a persistent problem is based on the assumption that Designers won't "learn to love" inclusions, which seems unlikely. Re. kludging Zope to do "what they want" Ideally, Zope's native ftp server can deliver DTML inclusions, which DreamWeaver, et. al. can "cache" for display purposes. Can Zope's native ftp server be taught to recognize such requests, and respond with a reasonable (rendered) facsimile, even if some resources are not currently available? That should keep visually oriented folks happy, since they'll be able to see a mock-up, at least. If that's possible, the little gotcha of Dreamweaver wanting to write back after updating might be handled politely too? Meeting this need one way or another is the whole point of the "round trip", edit vs. rendered discussion. So much for speculation about how a hypothetical SuperZope might learn to recognize requests from an editing tool, as opposed to some other ftp client. I know, ftp is not a smart protocol . . . Re. anti-inclusions, HTML "dummies" "It is much better to have a module that contains both the page prolog and epilog and a placeholder for the actual content, maybe filled in with sample text that later is replaced by the content, i.e. a page template. It is good that you are forced to use well formed XML in your modules." http://lists.zope.org/pipermail/zope-dev/2000-September/006907.html How is the "place-holder HTML that will never be rendered" solution any more appropriate? Perhaps simply because it's possible, as opposed to the mythical ftp beast above? It seems less so to me, at first glance. If we're seriously concerned over Designer reactions to inclusions, what will they say when we tell, them, "Just put anything there, for now, the system will handle it?" If they can get used to "subtractions", what's the real problem with "inclusions"? Aren't collapsed tags Good Enough as placeholders? It's a "visual" thing? Of course, I don't have a clear notion of how the xmlc model will change the way methods are invoked, and the innate capacities of Zope to deliver flexible solutions in this context. I'm eagerly awaiting a few lucid example demonstrating that Zope+xmlc is not only cleaner, and better future proofed, but actually more powerful and flexible than ever. That would be an offer I couldn't refuse! Thanks for all the Goodies, Jerry S.

1 0

ZPatterns bug: Link to parent providers - includes patch
by Steve Alexander 17 Sep '00

17 Sep '00

ZPatterns 0-4-2a2 The attribute excludePIs of LinkToParentProviders can be one of three types: It starts off as an empty tuple. When you choose to exclude one or more providers from the parent, it becomes a list. If you choose to exclude no providers from the parent, it becomes a string. When it is a string, the because it has been changed from the default state, but there are no exclusions, the second line of the method _getProviders fails, as it is trying to evaluate string in string. (Providers.py, line 299.) An easy solution is to change the line from this: return filter(lambda x,exclude=self.excludePIs: x.id not in exclude, r) to this: return filter(lambda x,exclude=list(self.excludePIs): x.id not in exclude, r) For a negligible bit of extra efficiency in the case where the link to parent providers' properties haven't been altered, change line 295, from this: excludePIs=() to this: excludePIs=[] This seems like more of a Zope implementation fault: surely a multiple selection property should always be set to a list, even when empty? Patch attached. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net *** Providers.py.orig --- Providers.py *************** *** 292,302 **** meta_type='Link to parent Data Plug-ins' __plugin_kind__ = 'Data Plug-in' ! excludePIs=() def _getProviders(self): r=getattr(self.aq_inner.aq_parent.aq_parent,'__allProviders__',()) ! return filter(lambda x,exclude=self.excludePIs: x.id not in exclude, r) def parentPIids(self): r=getattr(self.aq_inner.aq_parent.aq_parent,'__allProviders__',()) --- 292,303 ---- meta_type='Link to parent Data Plug-ins' __plugin_kind__ = 'Data Plug-in' ! excludePIs=[] def _getProviders(self): r=getattr(self.aq_inner.aq_parent.aq_parent,'__allProviders__',()) ! return filter(lambda x,exclude=list(self.excludePIs): ! x.id not in exclude, r) def parentPIids(self): r=getattr(self.aq_inner.aq_parent.aq_parent,'__allProviders__',())

1 0

Re: Re: [Zope-dev] ZPatterns based CD example. Halfway there! Need help
by James Johnson 17 Sep '00

17 Sep '00

another person had this problem earlier. It may have been because they used quotes like <dtml-var "foo">. It should be <dtml-var foo>. I get the same keyerror on foo?. I actually had ended up with the code you just gave from previous post. There must be a problem if others have had keyerrors. My understanding is that by placing the skinscript in the specialist would be a blackbox thing and placing it in the specialists rack with the other providers would be a whitebox thing. So seeing that the index_html is a method of the Class folder is should "see" the artist property. So I need to call the specialist and do a propertyMap() or something on it first? What could cause a keyerror? Seems to me that myPPS has no keys because its empty. I'm using win98,winNT4, win2000, redhat 6.2, zope 2.2.1, ZPatterns 4.2.2Alpha or the latest. I to work all of the platforms. For the most part it's going to to be the win98 platform I'm developing on. I can't wait to pump out my first ZPattern product. Get your Free E-mail at http://tacoma.zzn.com ____________________________________________________________ Get your own Web-Based E-mail Service at http://www.zzn.com

2 1

Re: [Zope-dev] HiperDOM & xmlc
by Dieter Maurer 17 Sep '00

17 Sep '00

Shane Hathaway writes: > lalo(a)hackandroll.org wrote: > > 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. > > I agree this is a problem, and speaking from experience, changing all > templates is not an acceptable compromise. For www.zope.org that would > mean including the standard template in nearly every page, everywhere, > because the pages on www.zope.org are nearly all "templates" > themselves. We would lose one of the primary benefits of Zope. > > Another unacceptable compromise is including a variant of > standard_html_header and _footer on every page (as is done now). One > reason is because it is not possible to write > standard_html_header/_footer using well-formed XML. The header begins > the "html" tag, while the footer ends it. In fact, most sites these > days put the beginning of a table in _header and the end of the table in > _footer. Objects containing non-well-formed XML aren't compatible with > a DOM-based solution. > > This has been one of the points of discussion here at DC. The only > reasonable solution we've come up with is automatically wrapping the > results of the rendering in an acquired object with a fixed name such as > standard_page_template. > > The other solution that I have tried to wrestle with is introducing some > kind of multiple view system with automatic selection of the default > view. But in reality, the standard_page_template solution would make > the multiple view system possible as well. > > So what does everyone think? Is standard_page_template the right thing > to do? Is there a better way? Help! I did not (yet) look at HiperDOM and xmlc. Nor am I familiar with dreamweaver and friends. Thus, maybe, I should not speak up. If one is really interested in a separation of content and presentation (which I feel is good), then the "standard_html_*" were wrong in the first place. It forces the content author to prepare for presentation. The "page_template" proposal is much better in this respect, as it is external to the content. Of cause, there should be a way to select between different page templates and not be bound to a fixed template (already mentioned by a previous responder). The other question deals with template modularity. If a single modification should influence several templates, then this is best addressed by building the templates out of modules. The modification of a module then affects all templates that use it. Modularization would be possible if e.g. XSLT is used for presentation. I do not know, whether Dreamweaver has a modularization concept. I hope so. The current "header/footer" fragments are not optimal wrt. modularization, as tightly coupled stuff ("footer" must close everything that "header" opened) is separated into different objects. It is much better to have a module that contains both the page prolog and epilog and a placeholder for the actual content, maybe filled in with sample text that later is replaced by the content, i.e. a page template. It is good that you are forced to use well formed XML in your modules. Dieter

1 0

Misc. comments on the Zope book
by Ross Boylan 17 Sep '00

17 Sep '00

I have a feeling that covering programming/scripting in any satisfactory way is another book-length volume; it might be better to omit it. However, the book on programming is the one I'd like to see! At the moment, programming Zope seems like voodoo. Should this book cover installation issues? Since you bring up CSS, it would be good to discuss how to detect browser type and adjust accordingly. I routinely see even relatively recent versions of Netscape get disoriented by style sheets. Some discussion of the issues in getting the right kind of URL to hand to the client would also be good. In particular, suppose you have nested folders A:B:C:D:E where E is the innermost folder. A defines a cascading style sheet and D redefines it. The naive implementation looks to the browser as if each folder has its own CSS, forcing it to be refetched for each one. But if you're clever, you reference a URL which is either A/myCSS or A/B/C/D/myCSS. Since this is a beginner book, more discussion of interacting with Zope, and its interaction with other tools, would be good. What about Apache? Dreamweaver? Emacs with ftp? etc. Good luck!

1 0

Comments on security, ch 5 and related issues
by Ross Boylan 17 Sep '00

17 Sep '00

I think it's great you're working on the documentation; Zope really needs it. The comments below started from Ch 5 of the draft Zope Book, but I think wander into some general issues about the security design, rather than your presentation. It is surprising that users can't change their own password in the default security setup. Or can they, because they "own" themselves? I couldn't quite tell from your description. It would be good to be explicit either way. 1. "Local Managers" I can't understand why you highlight this pattern. It seems useless in real life. In your example, sales managers have no access (as regular employees) to the rest of the site. I can't imagine a real organization which would work that way. Typically you would expect all employees to have certain access rights, and then certain people to manage the content in certain areas. If you can define the same acl_user at two different levels, with different permissions, you need to say that. If you can't, I would just omit this pattern. I think the idea of discussing actual security usage patterns is great, even if I didn't like this specific example. 2. "Trojan Horse attacks" another area I would omit. You do say it's partial protection. However, it's complicated to explain and the payoff is minimal. If someone reads the section quickly and thinks they are safe from such attacks, the section will have done a disservice. The problem is that anyone who can write a page can put a URL or some other item in which runs off to another site (or to the client browser) and does something naughty. The protection is only against executing stuff on the Zope server itself. If you leave the discussion in, try resequencing it. You discuss Trojans in the introductory section of "Ownership and Executable Content" and then seem to drop it, only to have the payoff under "Roles of Executable Objects". It might be worth highlighting the novel feature of this security protection: it is subtractive. In general, Zope seems to add permissions (and other acquirable things) to objects. If you have multiple roles, the permissions add. Proxy roles add. But ownership takes away permissions. 3. Auditing Once things get fairly involved, it would be desirable to have a way of auditing permissions on the site, in the simple sense of printing out all the information needed to tell the security status of objects. Someone is not going to visit each object and check it's permissions. Probably this is a feature the system needs, but if there's a way to do it it would be good to comment on it. I know this is one of the reasons you say to keep it simple. 4. Interference with other systems. The Zope security policy is a lot like permissions in a file system. In fact, Windows 2000 even has acquired security settings (I think called inherited). Windows NT has had the concept of the owner role for awhile. But the Zope security policy is not the same as those other systems, so it will be very easy for people to think it is and get confused. It would be good to warn about this explicitly, perhaps providing a discussion or table of the differences and similarities. 5. I was very curious how security is reflected in objects, in the database, and in the operation of python methods. If you go into programming, it would be good to have something on this. The fact (?) that python code itself does no security checks (if it's in a product) seems worth highlighting. My understanding is that python methods do have some restrictions. Also worth noting. 6. Some comments on the security design. a) The mail example for local roles is a bit worrisome. The method needs one specific permission, but because you have local roles, not local permissions, it gets the manager role, and thus a whole lot of permissions. On its face this is harmless, but handing out more permissions than necessary smells like a potential security hazard. How about having local permissions? b) The additive approach to security is still more of a problem, because it sounds rather easy to give something or someone too much authority, while thinking you have not (as your example about acquiring a permission which had been turned off showed). It also seems likely this differs from the behavior of the seemingly similar systems I mentioned in point 4. c) If my premise in point 1 is correct (local managers not viable for most organizations) it would be good to make it viable. The alternative of adding a bunch of permissions and roles to reflect different organizational units seems likely to become unweildy rather quickly. 7. It would be good to add a discussion of overall site security, particularly the fact that the standard over the web password challenge is fundamentally insecure. That is, the username/password are not themselves sent over a secure connection. Though the password is scrambled, it is done so by a known algorithm. I think the algorithm is invertible, or at least easy to crack. Furthermore, the scrambled password itself would suffice to become that person. To me, this means there's little point in putting a lot of effort into making things secure, because they won't be. And it also implies that actually managing over the web is particularly dangerous, since someone could get manager account access this way.

1 0

Easy grammatical mistakes to avoid
by Ross Boylan 17 Sep '00

17 Sep '00

In the draft Zope book, as well as numerous other places on the Zope site (including particularly documentation by Product authors), "it's" appears as the possessive, as in "Python Methods script and extend Zope in it's native object-oriented language..." "It's" = It is "Its" = belonging to it So the sentence should read "... extend Zope in its native object-oriented language ..."

1 0