[Zope-dev] Re: Comments on ZPatterns
At 03:10 PM 6/28/00 +0100, Chris Withers wrote: 1. Too much jargon... by far... Lots of complicated words that are meanlingless to the layman and don't help to convey the concepts. Yep, like "Acquisition" and "object publishing". :) Seriously, that is very much the level we're talking about here. ZPatterns is an evolution to Zope's revolution, in the area of web-based application development models. Zope says the answer is publishing objects in an environment supporting acquisition. The ZPatterns design approach is an attempt to answer to the question, "So what objects should I publish, and what are the appropriate uses of acquisition?" As with Zope itself, it is both a design approach *and* an implementation toolkit for the approach, which certainly doesn't help the confusion. :) Also, as in the early days of Zope, terminology evolves and changes as the developers of the concepts seek better ways to explain them to other people. As an example, "Specialist" was originally called "Interface" by Ty and I back around September or so. It evolved to "Implementation Provider" in the later part of the year, and "Implementor" by the time of our conference presentation. After using that name on the lists a while, and in developing the ZPatterns code, it became clear that the name still really sucked and we needed one that made more sense on initially encountering it. After considerable brainstorming, the term "Specialist" was born, and on the whole we're happy with it. Other terms are still in flux, and many I hope we can do away with by replacing them with simpler, more powerful ideas (such as replacing all of the different Trigger and Provider plugins with a simple declarative scripting syntax that lets you specify the aspect weaving for your objects). 2. Feature runaway. It seems every day something new (and more confusing) has been added to ZPatterns. I think ZPatterns will only work if it is kept as simple and functional as possible. My view (bearing in mind my limited understanding ;-) would be to concentrate on Containers, Container Groups and Plugins on the one front and Racks, Specialists and the various providers and agents on the other. Been there, done that, actually. There really hasn't been much change in ZPatterns from 0.3 to 0.4 in that regard. Most of the upheaval has been due to making it possible for the capabilities of "Rackmountables" to be used in non-rack settings. This forced some significant generalization of the model and some extension to the "theory" in the area of the internal event model (which was previously incomplete and too hardwired). Believe it or not, in 0.4 I have actually *removed* some previously existing data management plug-ins. The acquired attribute provider and acquired sheet provider classes were replaced with a generic "link to parent data plug-ins" class, for example. As Ty mentioned in his post on this subject, we will be trying to do away with other such features later, replacing them with general-purpose tools. Unfortunately, all this evolution makes ZPatterns a moving target for comprehension at the moment. In spite of this, my reading of the lists seems to indicate that there are a few people besides Ty and myself who are actually achieving results with the framework. I hope that they can help to provide more accessible how-to materials, because I'm still very focused on *finishing* ZPatterns to the level that my "paying job" requires. And it's likely going to be a few months before my "paying job" requires that I have introductory docs available for the tools (although I'd personally really like to have some available before then). ___ 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] More comments on ZPatterns
At 10:06 AM 7/3/00 -0500, Steve Spicklemire wrote:
Seriously, I'm trying to get it all figured out, and I thought maybe
if I attempted to do something 'real' with it I would at least learn
what I *don't* understand. Well.. I've learned a *lot*! (about what I
don't understand.. ) ;-) The source code is astonishingly simple
looking, but about one layer deeper that I can easily grok, apparently.
That's an unfortunate side-effect of applying Demeter's law... it's easy
to grasp (in an abstract way) local implementation aspects, but hard to
grasp how the actual *concrete* implementation works from looking at the
pieces. It's the "there's no *there* there" effect, as Ty dubbed it.
I also create a "TableInfo" ZClass, subclass of DataSkin, that
quantifies the kind of data the customers have to choose from, and
metadata about the data (headers, query parameters and suchlike).
I create a ZClass property sheet for the TableInfo ZClass.
Finally I create an instance of Specialist (tableManager) with a
(default) rack of TableInfo objects.
Now... some of the Tableinfo properties, and some of the View
properties are *really* in MySQL. I figured out, from the mail list
and the source code, that I can create a Generic attribute provider in
the rack that can get attributes from an SQL database for my DataSkin
descendents using the 'source expression' and 'target expression'
business.
Congratulations, you found the top secret documentation. :)
Source expression:
(GetTableInfo(tableInfoID=self.id) or [NOT_FOUND])[0]
Target expressions:
tableHeaders=RESULT.tableHeaders
footnote=RESULT.footnote
and when I ask one of my TableInfo instances for their footnote it
comes right out of MySQL! Cool. Now.. I can't seem to figure out how
to *change* the data in the database when the user 'edits' the
DataSkin which brings up the whole issue of changing stuff in
DataSkins.
Here's some more top-secret documentation... Use a GenericTrigger to
implement attribute changes. Set up your trigger to be activated on object
changes, and set the trigger expression to call an SQL method, e.g.:
UpdateTableInfo(object=self,CHANGED=CHANGED)
In the SQL method, code something like this:
UPDATE mytable
SET
dtml-if "CHANGED('attr1')"
attr1=dtml-var "object.attr1",
/dtml-if
...
WHERE primary_key='dtml-var "object.id" sql_quote'
with an "if" block for each attribute you might want to update.
Last part, and this is the trick that's not yet documented... set the "Set
Attrs" field to be a list of the attributes you want the trigger to handle
set/delete operations for. (You don't need to put anything in the
"Keeping" field unless you need a "before" value of an expression to use in
your SQL.)
___
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] ZPatterns: DropZone example
At 05:26 PM 6/28/00 +0100, Steve Alexander wrote: The suggested specialists in the Accounting framework are: Invoices Orders Customers Products What I'm finding is that these are just the White-box specialists. A clean design would seem to want all the specialists above, plus at least one Black-box specialist to do the "heavy lifting. Let's call it the "AccountingProcessor" specialist. Keep in mind that a Specialist doesn't just "store" a bunch of objects, it also provides *methods for dealing with sets of objects*. So an Invoices specialist could usefully contain a wide variety of reporting methods, for example. Similarly, the Customers specialist might have a method to post balances forward on all customer accounts whose statement cycle is in a certain date range. These are all "heavy lifting" from an accounting point of view, but perfectly valid to have in the white-box specialists. White-box doesn't mean that there's no implementation; it just means that the implementation is intended to be extensible or integratable by someone other than the framework's original developer. Now, if I had a third-party accounts package (something by Sage perhaps), I could make the AccountingProcessor specialist expose various functions to the four other White-box specialists. It would implement these by making equivalent calls on the underlying accounting package. I could also swap the heavy-lifting portion of my framework by swapping the black-box AccountingProcessor specialist for one that talks to some software by Quicken, or perhaps some software that is written in Python as a conventional Zope product. That's all quite true, but it would probably be simplest to do such a thing using AttributeProviders and SheetProviders in the white-box specialists. It does seem reasonable to have those providers talk to an AccountingProcessor object if you want to make your framework talk to different back-ends, but I think it is misleading and incorrect to call AccountingProcessor a specialist, as it's not an application-level service object, but a private implementation helper. Interestingly, you've just given me what may be a motivating example for using Shane Hathaway's DatabaseAPI in conjunction with ZPatterns, assuming of course that I've correctly understood his most recent explanation of the DatabaseAPI product. The same goes for the Resource Scheduling framework. We have some White-box specialists, ripe for customisation: Resources Reservations ResourceUsers And then for the heavy-lifting we have the black-box ResourceScheduler specialist. Again, this might be a Zope Python Product, or it might be an interface to some application written on top of Microsoft Exchange. Again, look to what these specialist would do besides look up objects. For example, utilization or load-balancing reports. Generating bills for usage. Generating calendars for individual resources. Checking for conflicts. Etc. Are specialists intended to be placed inside other specialists, as "contents"? You *can* do this, but I've not yet encountered a real-life situation where I *would* do this. (Mike has given some examples that suggest it might be useful under some circumstances, however.) So in this case, would the white-box specialists live inside the black-box specialist -- so they become the customisable aspects of the overall framework? Or would both black-box and white-box specialists live inside an uber-specialist? If anything, the black box should be inside the white. Otherwise, you are creating confusion between heaven and earth. :) Seriously, the white boxes are the parts you will reference in URL's most often, so why have /AccountingProcessor/Invoices/ when you can just have /Invoices/? If you have to share a black box among white boxes, acquire it. If your "root" gets too messy, then make an "Accounting" folder and put Invoices, AccountingProcessor, and the rest inside of it. ___ 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] ZPatterns Specialist Question
At 11:54 AM 7/3/00 +0100, Chris Withers wrote: Just a quickie: If, as the the ZPatterns Wiki states, 'Specialists are not classes', then why is there a 'Specialist' python class in the ZPatterns distribution? Specialists are instances of the class "Specialist". They are not themselves classes. The reason for emphasizing that point is that it is a common misconception of people beginning to use the ZPatterns design approach - they conflate or confuse specialists with the class of the things which they intend to use the specialist to gain access to. In other words, they assume that a specialist called "Customers" would always manipulate "Customer" instances, when in fact it might manipulate "SkyDiver" instances. Most of the point of having a specialist is to have a binding point which allows you to decouple your intended use of a thing, from the specific implementation of it. If one misses this point, one will be blind to a wide variety of ZPatterns' useful applications, and at the same time likely to ask why both Racks and Specialists are needed. They are both needed because the Specialist deals with a particular problem-domain aspect of a thing, and the Rack deals with implementation aspects. ___ 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] bug in zpatterns-0.4 ?
"Phillip J. Eby" wrote: Nope. The two levels of methods (get/retrieve and new/create) are there to seperate Rack-level concerns from implementation concerns. getItem() and newItem() handle maintenance of Rack-level invariants such as the retrieval cache, while retrieveItem() and createItem() deal with object-level invariants. If you called retrieveItem() instead of getItem(), the code would bypass the rack-level invariants managed by getItem(), which would mean in this case that the per-transaction cache would be bypassed. yes, this is a bit more clear to me now. Hm. Seems to me that you should just use two GAP's, one for each DB table, each using "self.id[0]" and "self.id[1]" respectively to determine their primary keys. (cough) why didn't I think about it??? Also, my racks are specialized to have a searchResults method, and a editItem method (until I can find the time to write a decent SQL Attribute setter provider) A reasonable approach. Although, in the case of SQL attribute setting, see my other e-mail from this evening about the use of Generic Triggers to do SQL attribute setting. btw, the genericattributeprovider has saved me a great deal of time. thanks very much! No problem. Did you ever try re-casting your CatalogAwareness replacement to use GenericTrigger instead of a specific Agent plug-in? I did not have the time to do so. I still stick to Zope-2.1.6 for now, and I was afraid of the issues with transaction commit order. and the motto is 'if it ain't break, don't fix it'. I have a contract to upgrade the product in august though. I will look at it at that time. regards, [EMAIL PROTECTED] ___ 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] site versions with zope
Hello, I'd like to modify a live site, instead of working on a mirror copy. Could someone explain me, step by step, how sessions work? Thanks Nathalie Bernier * Développeur web multiThématiques Centre Jean Monet Longlaville 54400 LONGWY http://multithematiques.com Chaînes thématiques sur câble et satellite * ___ 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] Help needed: why is this DTML not working in zope 2 ?
You could try moving stuff to the new dtml style for starters: dtml-var standard_html_header and the like. That might help, if not let us know.. cheers, Chris Gilles Lavaux wrote: Hello, I am a little bit disappointed not getting any echo from my previous question, so I report it. Maybe my dtml is wrong for zope2, but I would appreciate to have some explanation from more experienced peoples. If I can not find a solution, we will have to keep our zope1 production server, and it will be the end of the Zope story in my company :-( So my question was : I want to display the content of a site starting from a folder called 'Site' with a tree tag. I want also to render immediately inside the tree the documents with an ID=='PUBLIC_Doc'. In Zope 1.x I have a working dtml method like this: !--#var standard_html_header-- !--#tree Site branches_expr="objectValues()" sort=id skip_unauthorized-- b!--#var id--/b !--#if "_['id']=='PUBLIC_Doc'"-- ## !--#try-- !--#var "_[_['id']]"-- !--#except-- !--#var Except_Message-- !--#/try-- ## !--#/if-- !--#/tree-- !--#var standard_html_footer-- Unfortunatly for me , with zope 2.1.6 i get an error when I try to render the 'PUBLIC_Doc' document: . PUBLIC_Doc !# Error type:AttributeError Error Message: Error Message:__call__ Error TB:Traceback (innermost last): File "/usr/lib/python1.5/site-packages/DocumentTemplate/DT_Try.py", line 221, in render_try_except result = render_blocks(self.section, md) File "/usr/lib/python1.5/site-packages/DocumentTemplate/DT_Util.py", line 335, in eval return eval(code,globals,d) File "", line 0, in ? File "/usr/lib/python1.5/site-packages/DocumentTemplate/DT_Util.py", line 161, in careful_getitem v=mapping[key] File "/usr/share/zope/lib/python/OFS/DTMLMethod.py", line 146, in __call__ r=apply(HTML.__call__, (self, client, REQUEST), kw) File "/usr/lib/python1.5/site-packages/DocumentTemplate/DT_String.py", line 502, in __call__ try: return render_blocks(self._v_blocks, md) AttributeError: __call__ has someone a solution ?? Thanks, Gilles ___ 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 )
Re: [Zope-dev] Help needed: why is this DTML not working in zope 2 ?
Hello Lee !--#var PUBLIC_Doc-- doesn't change anything, same error. (you are right, I can use the name directly , but I have some other piece of code where I have to use the _[_['']] construction, so it has to work...) But I found something: In my 'PUBLIC_Doc' document I display image with a !--# var image_name-- tag, my problem disappear if I use !--#var "image_name"--, someone can explain this?? Thanks anyway for the replies Gilles -Original Message- From: LEE, Kwan Soo [EMAIL PROTECTED] To: Gilles Lavaux [EMAIL PROTECTED]; [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Tuesday, July 04, 2000 12:32 PM Subject: Re: [Zope-dev] Help needed: why is this DTML not working in zope 2 ? Not an answer, but a question. b!--#var id--/b !--#if "_['id']=='PUBLIC_Doc'"-- ## !--#try-- !--#var "_[_['id']]"-- !--#except-- You seems to "call" PUBLIC_Doc, then why don't you just !--#var PUBLIC_Doc-- instead of the !--#var "_[_['id']]"--? LEE Kwan Soo ___ 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 )
Re: [Zope-dev] Help needed: why is this DTML not working in zope 2 ?
Gilles Lavaux wrote: But I found something: In my 'PUBLIC_Doc' document I display image with a !--# var image_name-- tag, my problem disappear if I use !--#var "image_name"--, someone can explain this?? Are you sure the space after the # isn't your problem? I would STRONGLY recommend moving your code to the new syntax, especially if you are having problems. You should be aware that plans are afoot to remove the old syntax... cheers, Chris ___ 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] Fwd: [Zope-PTK] Area based roles?
Original Message
On 7/4/00, 12:45:29 PM, Monty Taylor [EMAIL PROTECTED] wrote
regarding [Zope-PTK] Area based roles?:
Hi all. I've got an idea of something I'm trying to implement, and I'm
wondering if the concept is of use to anyone else.
I've got an Intranet up in PTK. (What a shock, as I'm posting here. :) )
I'm slowly getting people to use it for internal collaboration, et al.
But the main things people are wanting to do are internal to their own
department, with some overlap. So you've got:
+PTKRoot
|
+-Members
| +-John
| +-Sue
|
+-Marketing
+-Technology
Say John is in Technology and Sue is in Marketing. What I want is for
John to have Contributor rights in the context of Technology, and Sue in
Marketing, i.e. John adds a News Item and Publishes it. It shows up in
Technology but not Marketing.
I thought about creating a Technolgy Item ("Release Notes") and a
Marketing one ("Press Release") and then just having a catalog search on
the meta-type of each in the appropriate folder's index_html and give
them all Contributor. But that strikes me as unclean. It would be nice to
have anyone be able to create a Press Release or Release Notes, but only
have them published in their department's context, and merely pending in
others.
Am I making any sense at all? Does anyone see either a need for doing
this or a way to do it? If it requires changes to PTK core, would anyone
be interested in those, or should I throw them in my pile of dirty little
secrets that no one should really know exist?
Thanks,
Monty
___
Zope-PTK maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-ptk
See http://www.zope.org/Products/PTK/Tracker for bug reports and feature
requests
___
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] Help needed: why is this DTML not working in zope 2 ?
Argh!!! no, I made a typo error : it was !--#var image_name--.the syntax was good. Ok, I will use the new syntax in my new sites. But for my old site, I will not modify my ~500 dtml methods, except if there is a way to automate the change. Gilles -Original Message- From: Chris Withers [EMAIL PROTECTED] To: Gilles Lavaux [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Tuesday, July 04, 2000 1:33 PM Subject: Re: [Zope-dev] Help needed: why is this DTML not working in zope 2 ? Gilles Lavaux wrote: But I found something: In my 'PUBLIC_Doc' document I display image with a !--# var image_name-- tag, my problem disappear if I use !--#var "image_name"--, someone can explain this?? Are you sure the space after the # isn't your problem? I would STRONGLY recommend moving your code to the new syntax, especially if you are having problems. You should be aware that plans are afoot to remove the old syntax... cheers, Chris ___ 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] Re: [Zope-PTK] Roles, Groups, Security and Group Membership
Original Message On 7/4/00, 1:22:04 PM, Chris Withers [EMAIL PROTECTED] wrote regarding [Zope-PTK] Roles, Groups, Security and Group Membership: Monty Taylor wrote: Am I making any sense at all? Does anyone see either a need for doing this or a way to do it? If it requires changes to PTK core, would anyone be interested in those, or should I throw them in my pile of dirty little secrets that no one should really know exist? You're making perfect sense and I think it's a Zope problem partly, and also a PTK problem. Good point. I think as ZEO becomes more prevelant and Zope wants to compete in the realm of big systems, group based interaction could serve to iron some things out. The Zope problem is that Zope security has no idea about Groups. As in Users/Members exist There may have roles They may also be members of Groups. Groups may also be members of Groups. Groups may also have roles associated with THEM. Other major security systems I can think of (LDAP, Unix, NT, Notes) all have this concept but Zope does not :( Should this part of the discussion be moved to zope-dev? Probably so. I've forwarded the original email there and I'm sending this one to zope-dev. Any comments from the zope-dev world? Monty ___ 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] ZEO Replication/Cache
I just installed an instance of ZEO Storage Server with a client on the same machine and a client on a different machine. So far, it seems to work reasonably well, with one exception. None of the changes I've made on one client seem to propagate to the other client unless I restart the other client. This can't be the intended modus operendi. Have I missed something obvious, or is the proactive notification from server to client not implemented yet? Monty ___ 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] Re: [Zope] site versions with zope
At 10:38 4-7-00 +0200, Nathalie Bernier wrote: Hello, I'd like to modify a live site, instead of working on a mirror copy. Could someone explain me, step by step, how sessions work? Hi, At http://www.zope.org/Documentation/Guides/ZCMG (Zope Content Manager's Guide) you'll find a section called 'Working with versions'. May be this is what you are looking for. Diny. DIVA Faculty of Veterinary Medicine The Netherlands http://www.vet.uu.nl ___ 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] ZCatalog lexicon bug is back?
Chris Withers writes: I seem to remember Michel being a little less than happy when he saw that code. Quite frankly, I still don't have much confidence in (Z)Catalog (still no docs for all the cool stuff, dodgy bugs and few responses when they're raised...) which is a shame since it's Zope full text searching mechanism... Chris PS: If that doesn't get a response, I give up ;-) I am very interested in ZCatalog. I promiss that I will look into it, when I come to 2.2. Currently, we are building a Zope 2.1.6 production site. So, I still stay focused with 2.1.6. My contributions to ZCatalog probably will not be ready for 2.2 final, but, if necessary, I will provide patches later. 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] Help needed: why is this DTML not working in zope 2 ?
Steve Alexander wrote:
Gilles Lavaux wrote:
Argh!!!
no, I made a typo error : it was !--#var image_name--.the syntax was good.
Ok, I will use the new syntax in my new sites. But for my old site, I will
not modify my ~500 dtml methods, except if there is a way to automate the
change.
You can write a pretty simple external method to walk your Zope object
heirarchy looking for DTML Methods and DTML documents, then altering the
syntax. Shouldn't take more than an hour to write and debug and test and
document, if you've written stuff in Python before.
I'm off to a meeting for a few hours, but harrass me later and I'll send
to the list a proof-of-concept external method to get you started.
An external method for automated change from old syntax to new syntax
follows.
* Use at your own risk
* No warranty implied or given
* Use on a copy of your main Zope site
* Back up data.fs three times before starting
* Not guarenteed not to spin your processor and never terminate
* Run on a copy of Zope in debug mode (-D) to see the print statements
* Barely tested, if at all
import re
def convert_dtml(self):
"""Convert DTML Methods and DTML Documents from old syntax to
new syntax.
Warning: recursive! Might just eat all your stack.
Does not work on subclasses of DTML Method and DTML Document.
Preserves normal comments, and handles instances of "--" in
quotes.
"""
print 'convert_dtml: id=%s' % self.title_and_id()
if hasattr(self, 'meta_type') and \
(self.meta_type == 'DTML Method' or \
self.meta_type == 'DTML Document'):
convert(self)
# should this be "isPrincipiaFolderish"?
if hasattr(self, 'isAnObjectManager') and self.isAnObjectManager:
for v in self.objectValues():
v.convert_dtml()
_convert_regex = re.compile('!--#(/?)(([^"-]+?|"[^"]*?"|-[^-])+?)--')
def convert(dtml_item):
print 'converting...'
title = dtml_item.title
# like document_src, but doesn't require RESPONSE
data = dtml_item.PrincipiaSearchSource()
print 'data'
print data
newdata = _convert_regex.sub('\g1dtml-\g2', data)
print 'newdata'
print newdata
print 'end'
dtml_item.manage_edit(newdata, title)
--
Steve Alexander
Software Engineer
Cat-Box limited
http://www.cat-box.net
___
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] Help needed: why is this DTML not working in zope 2 ?
Steve Alexander wrote:
An external method for automated change from old syntax to new syntax
follows.
* Use at your own risk
* No warranty implied or given
* Use on a copy of your main Zope site
* Back up data.fs three times before starting
* Not guarenteed not to spin your processor and never terminate
* Run on a copy of Zope in debug mode (-D) to see the print statements
* Barely tested, if at all
_convert_regex = re.compile('!--#(/?)(([^"-]+?|"[^"]*?"|-[^-])+?)--')
Actually, I missed something in the original regex, above. (Funny how I
noticed just after I pressed the 'send' button!)
It should read like this:
_convert_regex =
re.compile('''!--#(/?)(([^"-]+?|"[^"]*?"|'[^']*?'|-[^-])+?)--''')
The whole thing again -- same disclaimers apply, only more so :-)
import re
def convert_dtml(self):
"""Convert DTML Methods and DTML Documents from old syntax to
new syntax.
Warning: recursive!
This assumes that DTML Method and DTML Document haven't been
subclassed.
"""
print 'convert_dtml: id=%s' % self.title_and_id()
if hasattr(self, 'meta_type') and \
(self.meta_type == 'DTML Method' or \
self.meta_type == 'DTML Document'):
convert(self)
# should this be "isPrincipiaFolderish"?
if hasattr(self, 'isAnObjectManager') and self.isAnObjectManager:
for v in self.objectValues():
v.convert_dtml()
_convert_regex =
re.compile('''!--#(/?)(([^"-]+?|"[^"]*?"|'[^']*?'|-[^-])+?)--''')
def convert(dtml_item):
print 'converting...'
title = dtml_item.title
# like document_src, but doesn't require RESPONSE
data = dtml_item.PrincipiaSearchSource()
print 'data'
print data
newdata = _convert_regex.sub('\g1dtml-\g2', data)
print 'newdata'
print newdata
print 'end'
dtml_item.manage_edit(newdata, title)
--
Steve Alexander
Software Engineer
Cat-Box limited
http://www.cat-box.net
___
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] ZCatalog lexicon bug is back?
Dieter Maurer wrote: I am very interested in ZCatalog. I promiss that I will look into it, when I come to 2.2. Thanks, Documentation of the cool stuff which is already there, and making it work 100% reliably are the two main things... cheers, Chris ___ 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] ZPatterns: DropZone example
Thus spake Phillip J. Eby ([EMAIL PROTECTED]): That's all quite true, but it would probably be simplest to do such a thing using AttributeProviders and SheetProviders in the white-box specialists. It does seem reasonable to have those providers talk to an AccountingProcessor object if you want to make your framework talk to different back-ends, but I think it is misleading and incorrect to call AccountingProcessor a specialist, as it's not an application-level service object, but a private implementation helper. Does anybody out there have even the slightest clue about how to go about using AttributeProviders and SheetProviders? A select few terse hints on this subject would really help us (me) figure it out enough to start working on some howto's. Interestingly, you've just given me what may be a motivating example for using Shane Hathaway's DatabaseAPI in conjunction with ZPatterns, assuming of course that I've correctly understood his most recent explanation of the DatabaseAPI product. Am i wrong in thinking that DatabaseAPI is a completely separate solution to the same problem that ZPatters is suppose to address? Personally i have to give DatabaseAPI props for being quite easy to understand and use, while not sacrificing power. sRp -- Scott Parish http://srparish.net/ PGP signature
Re: [Zope-dev] ZPatterns: DropZone example
At 02:21 AM 7/5/00 +, Scott Parish wrote: Does anybody out there have even the slightest clue about how to go about using AttributeProviders and SheetProviders? A select few terse hints on this subject would really help us (me) figure it out enough to start working on some howto's. You might look at some of the recent posts which included an example of using GenericAttributeProviders to read from a MySQL database, and my reply explaining how to use a GenericTrigger to update that same database. Am i wrong in thinking that DatabaseAPI is a completely separate solution to the same problem that ZPatters is suppose to address? Personally i have to give DatabaseAPI props for being quite easy to understand and use, while not sacrificing power. Peter Coad's design approach (which ZPatterns is heavily based on/biased towards) emphasizes four major layers of classes in an application: 1) User Interface (GUI, forms, etc.) 2) Problem Domain (the actual application purpose) 3) Data Management (object persistence/lifecycle management) 4) System Interaction (interfaces w/hardware or other software) ZPatterns is focused on providing tools for transparent mappings between layers 2 and 3, while DatabaseAPI, as far as I can see (and I actually did play around with it today to get a feel for it), is focused on tools for building clean mappings between layers 3 and 4. In my mind, this makes them complementary tools, rather than competitors in any real sense. Indeed, looking at DatabaseAPI has shown me that there are some features I'd planned for ZPatterns (or already started) that I can scrap because DatabaseAPI has them and can easily interoperate. (Personally, I'd like to see a version of DatabaseAPI using PlugIns to structure its user interface, which I think could easily make it even cleaner and easier to use than it already is. It might then also be possible to reuse some of its plug-ins for functionality in areas of ZPatterns. But I digress.) So where do DatabaseAPI and ZPatterns overlap? DatabaseConnector has some functional overlap with Specialist. If you ignore the attribute, sheet, and trigger providing aspects of ZPatterns (and also look only at the raw functionality), the primary difference between a Specialist and a DatabaseConnector is that DatabaseConnectors will probably have methods to delete objects or change their data, which is a no-no for a Specialist because it's an encapsulation breach. Beyond this, there's a significant difference in intent between a Specialist and a DatabaseConnector (IMHO). A Specialist serves as a broker to access objects which fill a certain role in a framework, while a DatabaseConnector represents an object which manipulates "records" which are of "record types" and have "fields". Specialists use Racks to explicitly distinguish between problem-domain and data-domain concerns; you can probably do this with nested DatabaseConnectors but you'll have to do some additional work to support it. ZPatterns could definitely benefit from some ideas found in DatabaseAPI, primarily in the aspect of documenting API's and supporting better design contracts. For example, it would be nice for a Specialist to be able to define the API expected from its Racks, and a for an application framework to somehow define the API expected from the Specialists it will interact with. One could of course use the existing DatabaseAPI product to do these things, but the integration would be less than smooth, since you'd have to make the Specialist ask the Racks for their DatabaseConnectors, or else have a Rack class that delegated to a DatabaseConnector, or something like that. Anyway, I'm going to have to give these possibilities some more thought. ___ 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 )
