- Zope-Dev - Zope lists

Re: [Zope-dev] XHTML Templates comments from the peanut gallery
by Dieter Maurer 29 Sep '00

29 Sep '00

Chris Withers writes: > > 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. > > ....I'd like to add to this: > components used to make up 'page's should not be URL-visible. Why should > they be? > (would this raise issues with XML-RPC?) Because, you want to access them for management purposes (e.g. change them). > > Site Designers will create XHTML Template objects that control > > Where can I find out more about XHTML? --> http://www.w3c.org Dieter

2 1

RE: [Zope-dev] I feel your Wiki Pain ;-)
by Toby Dickenson 29 Sep '00

29 Sep '00

> | 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

6 17

Re: [Zope-dev] I feel your Wiki Pain ;-)
by Karl Anderson 29 Sep '00

29 Sep '00

Martijn Faassen <faassen(a)vet.uu.nl> writes: > I think you could integrate both mailinglists and wikis. On the one > hand, often we'd like to preserve a good posting in a mailing list as > a wiki page. So we make a separate wiki(a)zope.org address that's subscribed > to the mailing list, that keeps listening to the list and sees things > like this in postings: > > Wiki:StructuredTextWiki:FooBarPage > > This is a bunch of text that should be added to FooBarPage. > > Wiki:end Check out the MonkeyFist blog at <http://monkeyfist.com/DailyChurn/> - it's generated by scanning their IRC channel. -- Karl Anderson karl(a)digicool.com

1 0

ZCatalog with UTF-8 Chinese
by Sin Hang Kin 29 Sep '00

29 Sep '00

Dear Developer: Trying to short-cut UNTEXTINDEX to handle UTF-8 Chinese, I need some help. After reading some code of query, I think the regular expression operations which in parse, quotes and parse2 were not safe for utf8 string. So, I decide to emulate what they do. However, I do not understand what getlexicon is doing and I would like to learn what q should looks like before it is passed to evaluate. I do not understand that vocabulary seems to store like integer, is getlexicon a step to look up the string to convert them to integer? I am getting lost. Could some experienced developer help me out of these? Rgs, Kent Sin --------------------------------- kentsin.weblogs.com kentsin.imeme.net def query(self, s, default_operator = Or, ws = (string.whitespace,)): """ This is called by TextIndexes. A 'query term' which is a string 's' is passed in, along with an index object. s is parsed, then the wildcards are parsed, then something is parsed again, then the whole thing is 'evaluated' """ # First replace any occurences of " and not " with " andnot " s = ts_regex.gsub('[%s]+and[%s]*not[%s]+' % (ws * 3), ' andnot ', s) # do some parsing q = parse(s) ## here, we give lexicons a chance to transform the query. ## For example, substitute wildcards, or translate words into ## various languages. q = self.getLexicon(self._lexicon).query_hook(q) # do some more parsing q = parse2(q, default_operator) ## evalute the final 'expression' return self.evaluate(q)

2 1

RE: XHTML Templates comments from the peanut gallery
by Jay, Dylan 28 Sep '00

28 Sep '00

> 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. This all seems like a good idea but its hard its not very concrete. I proposed something very similar about a year ago. http://lists.zope.org/pipermail/zope-dev/1999-September/001624.html It was an extension to DTML that enabled the use of documents that were rendered html and dtml source combined. This gives you round trip wysiwyg editing without "doing away" with the whole DTML scripting thing. A designer might make a mockup, the coder would then zopify it by putting in iterations etc in DTML as they normally would. The designer could then view the document in "design-mode" that would render the DTML but keep special tags in place around the rendered content that contained the code. Whent the designer saved back this version there would be a spcial "design-mode" compiler that would work out all the DTML objects etc the relevent bits of content (and code) belonged to. Content relating to any object that the designer doesn't have permission to edit or the content was dynamic like from a database, just gets discarded. This solution seems to achieve most of your aims for XHTML but without some of the weird architecture changes. Dylan Jay Avaya Communication.

1 0

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

28 Sep '00

> >Chris Withers writes: > > 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. > > ....I'd like to add to this: > components used to make up 'page's should not be URL-visible. Why should > they be? > (would this raise issues with XML-RPC?) > whereupon Dieter Maurer responded: > Because, you want to access them for management purposes (e.g. > change them). and, conceptually at least, this should facilitate displaying the hypothetical "block" resources as "include virtual" sorts of beasties, on the inside of some next generation hyper-editing environment. Zopefully, Jerry S.

1 0

zope2.2.2 - ZopeTime not available to users defined in acl_users below the root? the root?
by ross 28 Sep '00

28 Sep '00

Here's a problem which bit me today. I'd delegated someone to manage a Yihaw directory. zope 2.2.2 source running on a sun. make a folder at the root (eg /foo) with an acl_user folder there define a new user in the foo acl_user folder (eg foobar) with manager/owner rights add a dtml method to view ZopeTime (eg <dtml-var ZopeTime> ) view it and see the current time. It's owned by a real manager and it works as expected. Now, close your browser down and authenticate as foobar and try to view the page. You'll get: Zope Error Zope has encountered an error while publishing this resource. Error Type: KeyError Error Value: ZopeTime Traceback (innermost last): File /udd/rerla/zope222/lib/python/ZPublisher/Publish.py, line 222, in publish_module File /udd/rerla/zope222/lib/python/ZPublisher/Publish.py, line 187, in publish File /udd/rerla/zope222/lib/python/Zope/__init__.py, line 221, in zpublisher_exception_hook (Object: Traversable) File /udd/rerla/zope222/lib/python/ZPublisher/Publish.py, line 171, in publish File /udd/rerla/zope222/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: test) File /udd/rerla/zope222/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: test) File /udd/rerla/zope222/lib/python/OFS/DTMLMethod.py, line 172, in __call__ (Object: test) File /udd/rerla/zope222/lib/python/DocumentTemplate/DT_String.py, line 528, in __call__ (Object: test) KeyError: (see above) Note, it's not unauthorised - it's just not in the namespace. ZopeAttributionButton is defined in the same Application.py but it works fine. I even tried adding ZopeTime__roles__=None to no avail. What gives???

2 1

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