Zope-Dev March 2002

zope-dev@zope.dev

113 participants
122 discussions

Proposed Web Services standards for Content Management
by Richard Volpato 24 Mar '02

24 Mar '02

Hi, I came across the following from Interwoven regarding the exposing of the components of content management systems as web services. http://www.interwoven.com/company/standards/content-services/ It is an entirely language neutral formulation. Seems to me to offer (in its 50 pages) a framework that Zope 3 could with greater ease than most CMSs be made compliant or at least capable of sustaining. Maybe someone can offer an opinion about this? Thanks in anticipation. Richard Volpato

2 1

ActiveState Python Distributions
by Eric Roby 23 Mar '02

23 Mar '02

I am in the process of setting up a group of Zope servers (some ZEO and some not) using the INSTANCE_HOME technique. I am currently running a Zope 2.4.4b1 and Zope 2.5 (pointing to) on the latest ActiveState Python distribution release. They are ONLY development sites right now. The cluster I am about to setup will be production. Since ActiveStates release lags a bit from the Python release, will I get into trouble setting up a central (ActiveState) Python Interpreter from which to drive my Zope cluster. All will be 2.5+ with the exception of a Zope instance running 2.4.4 (for OracleDA compatability). Any thoughts... Thanks in advance Eric

2 1

Re: [Zope-dev] manage frame change
by Anthony Baxter 23 Mar '02

23 Mar '02

>>> seb bacon wrote > anyone object to changing the text at in the top ZMI frame to "Logged in > as <user> on <machine>?" Or is there a better place to put that info? > I find it useful when I've got several windows open to different servers. What does "<machine>" mean? The host running the ZEO server? The host running the ZEO client? What about those of us who run multiple ZEO clients on the same machine (multi-cpu, test instances, whatever)... Anthony -- Anthony Baxter <anthony(a)interlink.com.au> It's never to late to have a happy childhood.

7 9

[Zope] Problem with adding importable modules
by David Thibault 21 Mar '02

21 Mar '02

Hello all, I originally sent this one just to the zope(a)zope.org list, but I just saw a bug report similar to this about 2.5.b2 on the Zope collector at http://collector.zope.org/Zope/77, so I figured I'd also submit it to you. I'm running 2.5.0-src (see traceback below). I have a problem regarding allowing the import of extra modules. I've found various examples (like the "Allowing Import of Modules" in the Zope online help) and a mailing list item entitled "Import Libraries into Python Script" (http://lists.zope.org/pipermail/zope-dev/2001-February/009531.html), but these aren't helping me. I'm still getting this error. I'm trying to use the Reportlab toolkit from within a Zope script (NOT an external method). I DON'T want to just import the whole Reportlab toolkit, because within that toolkit there are sys and os sections with what appear to contain very dangerous items. Therefore, I'm following more along the lines of the help in the Zope online help. I created a folder called MyScriptModules in $ZOPE/lib/python/Products/. The __init__.py file therein looks like this: -------------contents of __init__.py------------------------------------- from Products.PythonScripts.Utility import allow_module, allow_class from AccessControl import ModuleSecurityInfo, ClassSecurityInfo from Globals import InitializeClass from reportlab import platypus from reportlab.lib import colors, enums, pagesizes, styles, units from reportlab.pdfgen.canvas import Canvas allow_class(Canvas) allow_class(platypus) allow_class(colors) allow_class(enums) allow_class(pagesizes) allow_class(styles) allow_class(units) ModuleSecurityInfo('reportlab').declarePublic('platypus') ModuleSecurityInfo('reportlab.lib').declarePublic('colors','enums','pagesize s',' styles','units') ModuleSecurityInfo('reportlab.pdfgen.canvas').declarePublic('Canvas') -------------end __init__.py contents--------------------------------- I only wanted to import the bare essentials of my current program and some other classes that looked harmless but useful (like colors, enums, etc). I first started with ReportLab by creating a shell-based python script, which ran perfectly and created my PDF file. Now I'm porting it to Zope and I'm getting errors. Here's a curtailed example of the script. This short example creates the same error I'm getting in the full version of the script: ------------begin sample problem script----------------------------- #_______DO ALL THE IMPORTS__________________________________________________ from reportlab import platypus from reportlab.lib import styles, units, pagesizes from reportlab.pdfgen.canvas import Canvas import string #_______END IMPORTS SECTION_________________________________________________ #_______SET UP GLOBAL VARIABLES_____________________________________________ PAGE_WIDTH = pagesizes.letter[0] PAGE_HEIGHT = pagesizes.letter[1] txt_styles = styles.getSampleStyleSheet() styleTITLE = txt_styles['Heading1'] #_______END GLOBAL VARIABLES________________________________________________ return "I didn't crash" -----------------------end sample problem script--------------------------- When I try to test it Zope tries to make me log in again, I do so, and it asks me to log in repeatedly. If I finally click "Cancel", it gives me this: ------------------begin error condition experienced--------------------------- Zope Error Zope has encountered an error while publishing this resource. Error Type: Unauthorized Error Value: You are not allowed to access Heading1 in this context (cut out "Troubleshooting Suggestions") Traceback (innermost last): File /usr/local/Zope-2.5.0-src/lib/python/ZPublisher/Publish.py, line 150, in publish_module File /usr/local/Zope-2.5.0-src/lib/python/ZPublisher/Publish.py, line 114, in publish File /usr/local/Zope-2.5.0-src/lib/python/Zope/__init__.py, line 158, in zpublisher_exception_hook (Object: feedback) File /usr/local/Zope-2.5.0-src/lib/python/ZPublisher/Publish.py, line 98, in publish File /usr/local/Zope-2.5.0-src/lib/python/ZPublisher/mapply.py, line 88, in mapply (Object: test.py) File /usr/local/Zope-2.5.0-src/lib/python/ZPublisher/Publish.py, line 39, in call_object (Object: test.py) File /usr/local/Zope-2.5.0-src/lib/python/Shared/DC/Scripts/Bindings.py, line 252, in __call__ (Object: test.py) File /usr/local/Zope-2.5.0-src/lib/python/Shared/DC/Scripts/Bindings.py, line 283, in _bindAndExec (Object: test.py) File /usr/local/Zope-2.5.0-src/lib/python/Products/PythonScripts/PythonScript.py, line 291, in _exec (Object: test.py) (Info: ({'script': <PythonScript instance at 8ed0008>, 'context': <Folder instance at 8ecd2d0>, 'container': <Folder instance at 8ecd2d0>, 'traverse_subpath': []}, (), {}, None)) File Script (Python), line 17, in test.py File /usr/local/Zope-2.5.0-src/lib/python/AccessControl/ZopeGuards.py, line 94, in guarded_getitem Unauthorized: (see above) ------------------end error condition experienced----------------------------- It never returns the phrase "I didn't crash." However, if I comment out the line "styleTITLE = txt_styles['Heading1']" it does complete successfully. That means that the "pagesizes" stuff did import properly, because the PAGE_HEIGHT and PAGE_WIDTH get calculated properly (I can even return those successfully). Sorry for the long email, but I wanted to give a complete description of what I'm up against here. I suspect there's some problem in my __init__.py that's preventing me from accessing subobjects of what I've imported, but I'm not sure how to resolve it. Thanks, Dave _______________________________________________ Zope maillist - Zope(a)zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )

1 0

Next steps on Zope 2.6 plan
by Brian Lloyd 21 Mar '02

21 Mar '02

Hi all, As talked about last week, I've updated the proposed features document for Zope 2.6: http://dev.zope.org/Wikis/DevSite/Projects/Zope2.6/ProposedFeatures ...to cut out those proposals without volunteers. Now comes the hard part :^) There are quite a few proposals there. The current list is still a "laundry list" - it reflects every idea that someone had and volunteered for without any consideration of whether the proposals are good / bad / indifferent. Now we need to do a "quality chop" to turn the laundry list into an actual project plan consisting of only things that: 1 Have volunteers committed to producing the code AND associated documentation 2 Are generally agreed to be good ideas, for some definition of "generally" and "good" :) 3 Can realistically be completed (code and docs) by the May 1 target we are setting for 2.6 alpha 1. Getting from laundry list to project plan is made a bit harder this time around because this is the first really community-driven release, and we don't have any real process in place for getting there :( I think that we have #1 above under control, and #3 does not bother me that much, but #2 is a tough cookie. Right now, the laundry list includes some "competing" proposals (things that solve the same or similar problems in different ways), as well as some "better XXX" proposals that "compete" with things already in the core and some pretty big "overhaul XXX" proposals with wide ranging non-trivial impacts on documentation, packaging and other non-software concerns. Somehow we need to get to resolution on these things. I know that realistically we'll be winging it for 2.6 (there's no way that we could get any sort of well-thought-out generally agreed upon process in place in time). But while we're winging it, I'd like for us to be starting to think about these things and putting pieces in place as we're able. One suggestion Casey had was to start to codify a set of rules that features have to abide by to be considered for inclusion. Some examples here would be: - A feature that is a "better X than X" (where X is a feature or component already in Zope), has a much higher bar to jump over since it will almost never be worth the user confusion and extra documenation burden to add another component that does almost (but not quite!) the same thing as an existing builtin component. For example, if you have a "better Folder" implementation, the right approach is to add your betterness to the current builtin Folder, because Zope is not going to ship with two kinds of Folder (with the associated two sets of docs, etc.) without a very, very good reason *. * Exhibit A for multiple similar objects causing confusion: DTML Document and DTML Method. - A feature release should never contain more than one blow-it- up-and-redo-it type project (such as radical changes to key parts of packaging or infrastructure). For example, it would probably be a bad idea to totally redo the ZODB, packaging and installation and the security system all in one release (unless it is a major release like Zope2 -> Zope3). The aggregate impact in terms of obsoleting existing knowledge and documentation is too great to do many of these at once. It takes time for users and developers to catch up after something major is refactored, and we need to keep this in mind. - Features or components added to the Zope core should address a clear and generally agreed-upon need. Otherwise, accumulation of components over time will become a significant support burden for the zope maintainers. - Features that affect the security system face a higher analysis, design and documentation burden :^) I'm sure there are many other good guidelines, but you get the idea. Having a set of ground rules that everyone agrees on will make it easier to keep focused on arguing edge cases (instead of every detail) when it's time to define a release. Thoughts? I'll volunteer to maintain the guidelines document on dev.zope.org if folks can send their guideline suggestions. Brian Lloyd brian(a)zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com

3 3

PageTemplate Internet Explorer error
by Terry Kerr 21 Mar '02

21 Mar '02

Hi, I have the latest PageTemplates, ZTUtils, and TAL installed on Zope 2.4.3 with python 2.1.1 on Linux. Whenever I try to create or edit a PageTemplate using IE5.5 or IE6 on windows I get the following error. It works fine however when I use Netscape or Mozilla on windows or linux. I have seen some other emails about this error, but none seemed to suggest that the problem was ever solved. Is somebody working on this, or has somebody found a solution? terry kerr Site Error An error was encountered while publishing this resource. Error Type: Undefined Error Value: "manage_page_header" not found in "here/manage_page_header" ---------------------------------------------------------------------------- ---- Troubleshooting Suggestions The URL may be incorrect. The parameters passed to this resource may be incorrect. A resource that this resource relies on may be encountering an error. For more detailed information about the error, please refer to the HTML source for this page. If the error persists please contact the site maintainer. Thank you for your patience. Traceback (innermost last): File /home/zope/Zope/lib/python/ZPublisher/Publish.py, line 223, in publish_module File /home/zope/Zope/lib/python/ZPublisher/Publish.py, line 187, in publish File /home/zope/Zope/lib/python/Zope/__init__.py, line 226, in zpublisher_exception_hook File /home/zope/Zope/lib/python/ZPublisher/Publish.py, line 171, in publish File /home/zope/Zope/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: ptAdd) File /home/zope/Zope/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: ptAdd) File /home/zope/Zope/lib/python/Shared/DC/Scripts/Bindings.py, line 324, in __call__ (Object: ptAdd) File /home/zope/Zope/lib/python/Shared/DC/Scripts/Bindings.py, line 354, in _bindAndExec (Object: ptAdd) File /home/zope/Zope/lib/python/Products/PageTemplates/PageTemplateFile.py, line 163, in _exec (Object: ptAdd) File /home/zope/Zope/lib/python/Products/PageTemplates/PageTemplate.py, line 156, in pt_render (Object: ptAdd) (Info: {'container': <__FactoryDispatcher__ instance at 90c56d8>, 'here': <__FactoryDispatcher__ instance at 90c56d8>, 'modules': <Products.PageTemplates.ZRPythonExpr._SecureModuleImporter instance at 0x95dabdc>, 'nothing': None, 'options': {'args': ()}, 'request': <h3>form</h3><table></table><h3>cookies</h3><table></table><h3>other</h3><ta ble><tr valign="top" align="left"><th>AUTHENTICATION_PATH</th><td>''</td></tr><tr valign="top" align="left"><th>URL3</th><td>'http://orgazmo.adroit:8080'</td></tr><tr valign="top" align="left"><th>URL0</th><td>'http://orgazmo.adroit:8080/manage_addProduct/ PageTemplates/ptAdd'</td></tr><tr valign="top" align="left"><th>URL1</th><td>'http://orgazmo.adroit:8080/manage_addProduct/ PageTemplates'</td></tr><tr valign="top" align="left"><th>BASE3</th><td>'http://orgazmo.adroit:8080/manage_addProduct /PageTemplates'</td></tr><tr valign="top" align="left"><th>URL2</th><td>'http://orgazmo.adroit:8080/manage_addProduct' </td></tr><tr valign="top" align="left"><th>BASE1</th><td>'http://orgazmo.adroit:8080'</td></tr><tr valign="top" align="left"><th>traverse_subpath</th><td>[]</td></tr><tr valign="top" align="left"><th>SERVER_URL</th><td>'http://orgazmo.adroit:8080'</td></tr><t r valign="top" align="left"><th>PUBLISHED</th><td><PageTemplateFile instance at 91b4888></td></tr><tr valign="top" align="left"><th>URL</th><td>'http://orgazmo.adroit:8080/manage_addProduct/P ageTemplates/ptAdd'</td></tr><tr valign="top" align="left"><th>AUTHENTICATED_USER</th><td>Anonymous User</td></tr><tr valign="top" align="left"><th>BASE2</th><td>'http://orgazmo.adroit:8080/manage_addProduct '</td></tr><tr valign="top" align="left"><th>TraversalRequestNameStack</th><td>[]</td></tr><tr valign="top" align="left"><th>BASE0</th><td>'http://orgazmo.adroit:8080'</td></tr><tr valign="top" align="left"><th>BASE4</th><td>'http://orgazmo.adroit:8080/manage_addProduct /PageTemplates/ptAdd'</td></tr><tr valign="top" align="left"><th>URL0</th><td>http://orgazmo.adroit:8080/manage_addProduct/P ageTemplates/ptAdd</td></tr><tr valign="top" align="left"><th>URL1</th><td>http://orgazmo.adroit:8080/manage_addProduct/P ageTemplates</td></tr><tr valign="top" align="left"><th>URL2</th><td>http://orgazmo.adroit:8080/manage_addProduct</ td></tr><tr valign="top" align="left"><th>URL3</th><td>http://orgazmo.adroit:8080</td></tr><tr valign="top" align="left"><th>BASE0</th><td>http://orgazmo.adroit:8080</td></tr><tr valign="top" align="left"><th>BASE1</th><td>http://orgazmo.adroit:8080</td></tr><tr valign="top" align="left"><th>BASE2</th><td>http://orgazmo.adroit:8080/manage_addProduct< /td></tr><tr valign="top" align="left"><th>BASE3</th><td>http://orgazmo.adroit:8080/manage_addProduct/ PageTemplates</td></tr><tr valign="top" align="left"><th>BASE4</th><td>http://orgazmo.adroit:8080/manage_addProduct/ PageTemplates/ptAdd</td></tr></table><h3>environ</h3><table><tr valign="top" align="left"><th>HTTP_ACCEPT_ENCODING</th><td>'gzip, deflate'</td></tr><tr valign="top" align="left"><th>channel.creation_time</th><td>1016684537</td></tr><tr valign="top" align="left"><th>SERVER_PROTOCOL</th><td>'HTTP/1.1'</td></tr><tr valign="top" align="left"><th>SERVER_PORT</th><td>'8080'</td></tr><tr valign="top" align="left"><th>PATH_INFO</th><td>'/manage_addProduct/PageTemplates/ptAdd'< /td></tr><tr valign="top" align="left"><th>HTTP_HOST</th><td>'orgazmo.adroit:8080'</td></tr><tr valign="top" align="left"><th>REQUEST_METHOD</th><td>'GET'</td></tr><tr valign="top" align="left"><th>PATH_TRANSLATED</th><td>'/manage_addProduct/PageTemplates/p tAdd'</td></tr><tr valign="top" align="left"><th>SCRIPT_NAME</th><td>''</td></tr><tr valign="top" align="left"><th>SERVER_SOFTWARE</th><td>'Zope/(Zope 2.4.1 (source release, python 2.1, linux2), python 2.1.1, linux2) ZServer/1.1b1'</td></tr><tr valign="top" align="left"><th>HTTP_ACCEPT_LANGUAGE</th><td>'en- au'</td></tr><tr valign="top" align="left"><th>HTTP_ACCEPT</th><td>'image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*'</td></tr><tr valign="top" align="left"><th>REMOTE_ADDR</th><td>'10.0.0.22'</td></tr><tr valign="top" align="left"><th>SERVER_NAME</th><td>'orgazmo.adroit'</td></tr><tr valign="top" align="left"><th>GATEWAY_INTERFACE</th><td>'CGI/1.1'</td></tr><tr valign="top" align="left"><th>HTTP_USER_AGENT</th><td>'Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)'</td></tr><tr valign="top" align="left"><th>CONNECTION_TYPE</th><td>'Keep-Alive'</td></tr></table>, 'root': <Application instance at 8ddcc90>, 'template': <PageTemplateFile instance at 91b4888>, 'traverse_subpath': [], 'user': Anonymous User}) File /home/zope/Zope/lib/python/TAL/TALInterpreter.py, line 229, in __call__ File /home/zope/Zope/lib/python/TAL/TALInterpreter.py, line 262, in interpret File /home/zope/Zope/lib/python/TAL/TALInterpreter.py, line 503, in do_insertStructure_tal File /home/zope/Zope/lib/python/Products/PageTemplates/TALES.py, line 297, in evaluate Undefined: (see above)

1 0

Structured text issues (again?)
by jlagarde＠bigfoot.com 21 Mar '02

21 Mar '02

How extensively is STX actually used? I've been looking at it myself recently, and the whole system seem rather simplistic to me in how it parses the text. I'm talking specifically of the STX version currently standard in Zope 2.5 (and 2.4 I think), which I believe is STXNG; I haven't gone back to look at how the previous version worked. I have looked at some of the past mailing list posts on this topic, and although it is clear that things have been improved a lot, I am surprised that not more was done so far. I explain the problems I see next, followed by a proposed algorithm change and some rough code to make things "better". I'm doing this now for two reasons: First, if I'm missing something important wrt the reasons things are as they are, I'm obviously interested to know before I spend any more time on this. Second, maybe these proposed changes are actually a step in the right direction, or might help someone else do what they need, so I'm providing the code of what I've done so far, as is, in case it can be of help (I am unlikely to have the time to come up with a polished set of changes myself any time soon). Or I guess what I'm saying is (wink wink nudge nudge): If someone else feels like picking up on this and finishing it up so I don't have to, feel free ;-) The biggest problem I see is that the various text types are given somewhat arbitrary preference from the order in which they appear in the text_types list. Given that the patterns in text_types are looked at in order, with the first match breaking the raw string in half, then any other structure that would have spanned a larger part of the string but is lower in the text_types list is effectively ignored. For example, since doc_strong is currently listed before doc_emphasize, "*emphasized **strong** emphasized*" does enclose "strong" in <strong> tags, but completely ignores the single *'s because they do not form a matching pair (because the parsing of **strong** breaks the rest in two separate strings "*emphasized " and " emphasized*"). Following the same reasoning, I assumed that **strong *emphasized* strong** would work better, but it did not! This time, it's because the regexp for doc_strong is rather simplistic, as it does not allow ANY '*' within (strongem_punc), whereas it should only care to not allow the specific pattern '**' inside. In this case, wouldn't the easiest solution be to simply use the non-greedy matching? i.e replace: r'\*\*([%s%s%s\s]+?)\*\*' % (letters, digits, strongem_punc) with: r'\*\*(.*?)\*\*' or actually better: r'(?!\*\*\*)\*\*(?<!\*\*\*)(.*?)(?!\*\*\*)\*\*(?<!\*\*\*)' I think the last pattern is best because it will not recognize the middle **** as anything in "**this: **** does not matter**", as I think should normally be expected. BTW, I make no claim that the regexp above is either the most elegant or the most efficient; this is the first one I came up with that did what I wanted ;-) Now, back to the problem with the ordered nature of text_types (the reason "*emphasized **strong** emphasized*" does not work as expected). Besides the extra computing required, any reason why the structures with the largest span shouldn't be recognized first, regardless of the order of text_types? I.E. what I propose is to go through all the text_types, collecting the matching patterns, and only once this is done choose the one with the largest span. Then proceed recursively with the enclosed text until no pattern matches. This permits to succeed in quoting structured text patterns: "'**not bold**'", and bolding quoted text: "** some text '<this is quoted>' **". With the current implementation, none of those work, i.e. "'**not bold**'" ends up being bolded and not quoted, and "** some text '<this is quoted>' **" is a total mess because the text in <> is interpreted as SGML instead of being quoted as requested. The changes I have made so far (all in DocumentClass.py): The simplest are the few regexp changes I have made for doc_strong, doc_emphasize, and doc_literal (actually doc_literal probably doesn't matter (I used the pattern proposed by someone else on this list to make the quoting more obvious), but the changes to doc_strong and doc_emphasize are required to make my other changes work). doc_strong becomes: r'(?!\*\*\*)\*\*(?<!\*\*\*)(.*?)(?!\*\*\*)\*\*(?<!\*\*\*)' doc_emphasize becomes: r'(?!\*\*)\*(?<!\*\*)(.*?)(?!\*\*)\*(?<!\*\*)' and doc_literal becomes: r"(\W+|^)``([%s%s%s\s]+)''([%s]+|$)" % (letters, digits, literal_punc, phrase_delimiters) The big changes are to the parse and color_text methods. Parse now only returns the first match found of a type rather than all of them, and it returns the start and end indices of the match so that the span size can be computed in color_text: def parse(self, raw_string, text_type, type=type, st=type(''), lt=type([])): """ Parse accepts a raw_string, an expr to test the raw_string, and the raw_string's subparagraphs. Parse will continue to search through raw_string until all instances of expr in raw_string are found. NOT!!! If no instances of expr are found, raw_string is returned. Otherwise a list of substrings and A SINGLE instance is returned """ tmp = [] # the list to be returned if raw_string is split append=tmp.append if type(text_type) is st: text_type=getattr(self, text_type) start = end = 0 # because I'm returning those now while 1: t = text_type(raw_string) if not t: break #an instance of expr was found t, start, end = t if start: append(raw_string[0:start]) tt=type(t) if tt is st: # if we get a string back (when would this happen?), add it to text to be parsed raw_string = t+raw_string[end:len(raw_string)] # should I break or not here? If I break, same as removing the while else: if tt is lt: # is we get a list, append it's elements tmp[len(tmp):]=t else: # normal case, an object append(t) #Do not keep processing once a match found! raw_string = raw_string[end:len(raw_string)] break if not tmp: return (raw_string,0,0) # nothing found if raw_string: append(raw_string) elif len(tmp)==1: return (tmp[0],start,end) return (tmp,start,end) In color_text, instead of looping over the text_types only once, I loop over all of them for every recursive pass. For any pass, I select the match (no matter what type) with the largest span, and recurse on its content. I think that the code could be made a lot more efficient (as long as they are not overlapping, I should be able to collect more than one match in a single pass, among other things), but I just wanted to see if the result of the parsing would give the results I wanted for now, and it seems it does (but I repeat, I haven't tested extensively so far). def color_text(self, str, types=None): """Search the paragraph for each special structure """ if types is None: types=self.text_types if type(str) is StringType: max = 0 parsed = 0 for text_type in types: res, start, end = self.parse(str,text_type) if res != str: parsed = 1 # keep the option with the largest span only if end-start >= max: finalres = res max = end-start if parsed and type(finalres) is ListType: # *** this may cause other problems ** return self.color_text(finalres) else: return finalres # end recursion elif type(str) is ListType: res = [] for sub in str: subres = self.color_text(sub) if type(subres) is not ListType: subres = [subres] res += subres return res else: res = map(self.color_text,str.getColorizableTexts()) # To avoid stuff like StructuredTextSGML(StructuredTextSGML('<I>')) if len(res) == 0 or type(res[0]) != type(str) or \ res[0].getColorizableTexts() != str.getColorizableTexts(): str.setColorizableTexts(res) return str So there you have it. I find that the results produced by this code make a lot more sense than what is produced by the current implementation. I guess one problem with structured text may be that there are differences of opinion as to what the actual rules and output should be (e.g. should list items be singly spaced or double spaced), but I really don't see who could argue that a preference in the order of markup like emphasis, strong, and underline makes any sense. Or am I missing something? Cheers, Jean

3 2

Flush memory from product
by de ZORZI Frederic 20 Mar '02

20 Mar '02

Hello zopers, I'm writing a product with a relational database mapping. When I launch loading procedures, the product creates ~ 50000 instances. I regulary do a get_transaction().commit(), but memory still increase constantly (more than 300 megs for python processes) How can I flush memory ? Tested with : gnu/linux debian potato, zope 2.3.3 gnu/linux debian woody, zope 2.5.0

1 1

RE: Object links/references
by Brian Lloyd 20 Mar '02

20 Mar '02

> You told us that you will be refining Zope 2.6 plan. > ProposedFeatures table contains an " Implement links > (object references)" entry by Mario Valente. I've created > SoftLink proposal in ProposalsWiki . These works appear > related. We (Mario and me) discussed and decided that > we can dedicate some efforts to make it working (Mario > has working code already). The plan is to release Patch-like > product for Zope 2.3, 2.4 and 2.5 to get feedback. And to > incorporate functionality into Zope 2.6 without patching > functionality. > > Please give us your recommendations / feedback / instructions for us, To be honest, I'm a little worried about the approach. Links can be very, very hard to get right (which is why they are not in the core now), especially with regard to security issues. Creating an object that "impersonates" another object is tough, because there a potentially unknown number of contracts that the impersonator must fulfill. This usually leads to problems :( For the SoftLink proposal in particular, the main problem you note in the proposal is that you want to avoid 404's when people go to a resource that has been moved. It seems to me that the best way to address that problem is to have a "RedirectObject" that you could add with the name of the object that was moved. It would _not_ try to impersonate the moved object, but when you went to "view" the object, you would be automatically redirected to the new location. That would avoid a lot of the problems of the link approach, with little overhead. Note that I'm not saying that object links are not a valid requirement, but it sounds like the problem you want to solve is definitely different than Mario's. In many ways, the "correct" required behavior of a link depends on what you expect to be able to do with it (the problem you are trying to solve). I can easily imagine that "right" behavior of a link if your main goal is to avoid 404s will _not_ be right if you are using the link in other ways. For example, if you went to a URL that had been moved, what is the right "context" that it should render itself in? I highly suspect that the right context is the place that it was moved to, rather than the context where the link lives (redirect semantics). That is basically the opposite of another possible usage of a link, where you would want to use the link to "virtually include" an object into a different context. I submit that trying to do both is too complex and probably too insecure as well (as managers of security would have to evaluate N possible security scenarios, most of which are not readily visible to them at the time they are setting up security). I think that the "RedirectObject" approach could sidestep all of these issues and provide an incremental step while still solving your problem. Brian Lloyd brian(a)zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com

2 1

ZMI: IE6 TextArea width bug: fix on tap for 2.6?
by Jeff Kowalczyk 20 Mar '02

20 Mar '02

I was wondering if there was any consensus on how best to fix or compensate for the unfortunate behaviour of IE6 with regards to the width calculation of textarea boxes. For anyone who hasn't seen it, the full-width texareas that are everywhere in the ZMI suddenly started pushing the width out in IE6, causing the horizontal scrollbar to become active, and generally making ZMI editing life miserable. Would it be possible to include in 2.6 (or 2.5.1, even better) a user preference, sitewide configuration setting, or other means of suppressing a few pixels/percent of that default width? I'm loathe to apply a massive search-replace to put "95%" in my local ZMI source, and IE6 must be a common enough platform for Zope users to warrant a workaround. I wouldn't hold my breath that MS would fix IE or anything sensible like that. It would be a shame to slow the whole thing down with browser detection logic for this one bug, unless that opened up the door for some of the Javascript/DHTML editors as a per-user preference for editing certain metatypes.

3 2

← Newer
1
2
3
4
5
6
7
...
13
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Zope-Dev March 2002