Re: [Zope3-dev] branched Zope 2.9
--On 12. November 2005 22:08:38 -0500 Chris McDonough <[EMAIL PROTECTED]> wrote: FYI (this is mostly for the benefit of the Five folks), I've created a Zope 2.9 branch from the trunk as of about 10 minutes ago. This branch is frozen for feature work; it may need some changing of externals to reflect what we want the initial version of Zope 3 that we want 2.9 to ship with. I don't know what that version is, so this is a note to say that if these externals changes get made on the Zope 2 trunk, please also make them on the 2.9 branch. I would have created the 2.9 branch in case the current trunk would be ready to branch. At least one week ago there were unresolved issues (with zpkg I think) that deferred the 2.9 release (scheduled for last Monday). So in general what is the current state of the remaining work to get 2.9b1 out to the people? Andreas pgpdCmBJ7gtTt.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] branched Zope 2.9
FYI (this is mostly for the benefit of the Five folks), I've created a Zope 2.9 branch from the trunk as of about 10 minutes ago. This branch is frozen for feature work; it may need some changing of externals to reflect what we want the initial version of Zope 3 that we want 2.9 to ship with. I don't know what that version is, so this is a note to say that if these externals changes get made on the Zope 2 trunk, please also make them on the 2.9 branch. - C ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] (zope/app/cache/ram.py) class Storage's cleanup problem.
Thanks Stephan,
Here is the test:(test_ramcache.py)
class TestStorage(TestCase):
def test_getEntry(self):
--snipped--
def test_getEntry_do_cleanup(self):
from zope.app.cache.ram import Storage
s = Storage(cleanupInterval=300, maxAge=300)
object = 'object'
key = ('view', (), ('answer', 42))
value = 'yes'
s.setEntry(object, key, value)
s._data[object][key][1] = time() - 400
s.lastCleanup = time() - 400
try:
s.getEntry(object, key)
except KeyError:
pass
else:
raise "cleanup not called"
def test_setEntry(self): --snipped--
On 11/12/05, Stephan Richter <[EMAIL PROTECTED]> wrote:
On Tuesday 01 November 2005 05:10, Simon Hang wrote:> Dear all,>> I'm happen to find out call Storage only do cleanup when new Entry comes> and do nothing when entries get from storage. So entries will be next
> expired if there are only read activities.I agree with your analysis and solution. If you provide a test for the fix,I'll check it in. If you cannot write a test, please add least add an issueto the issue collector.
Regards,Stephan--Stephan RichterCBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Changing zope.app.rdb to better support sqlos
On Sat, Nov 12, 2005 at 06:53:23AM -0500, Stephan Richter wrote: > On Monday 07 November 2005 10:18, Brian Sutherland wrote: > > > Please don't check this in yet, I want to review the problem before you > > > do, because I think specific interfaces are just nuts unless we have a > > > very good reason. > > > > Sure;) > > > > The guts of the issue are how to know what type of SQL the connection > > accepts so that sqlos can choose the right adapter for it. An interface > > seemed best. > > After thinking about it on and off for the last week, I agree now. The > simplest, easiest and most effective solution are specific interfaces. *sigh* Yeah, I just found zope.schema.interfaces and now understand your sigh. -- Brian Sutherland Metropolis - "it's the first movie with a robot. And she's a woman. And she's EVIL!!" ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Yet Another Relations (aka Reference) Engine...
Helmut Merz wrote: > >OK - then I'm not talking about references, though we still mean >different things when talking about 'relation': > >Mine goes like this: A relation object R providing >ITriadicRelation and connecting A, B and C involves three >references: > >R with A >R with B >R with C > >In addition the relation object has a sort of type, the >'relationship' (corresponding to a 'predicate') that may be >specified by the relation's class or - a special case - a >string. > >Maybe there is a better word for this kind of 'relation'? > >Helmut > > I don't know. I think you have to start from a definition that is not dependent on zope in general and understand what the concepts mean outside the computer world. This was not invented here. The "relations" used in software are more than just relations since they also assert something, and a relation by itself asserts nothing, it is just an abstraction that connect several things or aspects of things. So "relations" here are rather "propositions". for instance: "A blue box" involves a relation between the "box" and the quality "blue", but to represent the relation, you would to assert a proposition: "The box is blue" The proposition can be analysed. It has a predicate and a subject (or subjects if taken individually), the subject is an ordered tuple and the predicate is what is left of the proposition when the subjects have been removed (it is what is "predicated", or asserted of the subjects of the proposition) for instance in the proposition: "The box is blue" the predicate "__ is blue" predicates "blueness" of the box but a predicate is not the same thing as a relation /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] RFC: CustomWidgetFactory and widgets having different __init__ signature
As I'm digging through zope.app.form.browser to fix the CustomWidgetFactory collector issue, I found the following: IWidget has no __init__ defined class Widget(object): def __init__(self, context, request): class ItemsWidgetBase(TranslationHook, SimpleInputWidget): def __init__(self, field, vocabulary, request): class ItemsEditWidgetBase(SingleDataHelper, ItemsWidgetBase): def __init__(self, field, vocabulary, request): class ObjectWidget(BrowserWidget, InputWidget): def __init__(self, context, request, factory, **kw): class SequenceWidget(BrowserWidget, InputWidget): def __init__(self, context, field, request, subwidget=None): class SequenceDisplayWidget(DisplayWidget): def __init__(self, context, field, request, subwidget=None): class SourceDisplayWidget(zope.app.form.Widget): def __init__(self, field, source, request): class SourceInputWidget(zope.app.form.InputWidget): def __init__(self, field, source, request): class SourceSelectWidget(zope.app.form.browser.SelectWidget): def __init__(self, field, source, request): CustomWidgetFactory fails on these different signatures. This affects the ZCML . Simple widgets will work, widgets with different signatures of course not. class CustomWidgetFactory(object): implements(IViewFactory) def __call__(self, context, request): class CustomSequenceWidgetFactory(object): implements(IViewFactory) def __call__(self, context, field, request): In fact, CustomSequenceWidgetFactory violates the IViewFactory interface with the different __call__ signature. That causes setUpWidget to fail. I'm wondering if this worked for anyone anytime. Now I'm stuck a little bit. How does a good solution look like? My half-baked solution was up to today for Itemswidgets (which caused the error for me) to mark it with a different interface and look for that in CustomWidgetFactory and pass different arguments. Now I'm not so sure that this is the right one. -- Best regards, Adam mailto:[EMAIL PROTECTED] -- Quote of the day: Every person should have a special cemetery lot in which to bury the faults of friends and loved ones. - Anonymous ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Yet Another Relations (aka Reference) Engine...
Am Samstag, 12. November 2005 20:00 schrieb Jean-Marc Orliaguet: > Helmut Merz wrote: > >Am Samstag, 12. November 2005 18:00 schrieb Jean-Marc Orliaguet: > >>My > >>impression is that you are thinking of a reference engine > >>rather than a relation engine > > > >Maybe I just don't see the difference... (There is one, of > >course, but I doubt it is really of relevance in a practical > >context. ) > > > >Helmut > > A relation contains several references: > > a relation between A, B and C involves 7 references: > > A with itself > B with itself > C with itself > A with B > B with C > C with A > A with B with C > > But a set of references don't make explicit relations, unless > the application know how to interpret the references. OK - then I'm not talking about references, though we still mean different things when talking about 'relation': Mine goes like this: A relation object R providing ITriadicRelation and connecting A, B and C involves three references: R with A R with B R with C In addition the relation object has a sort of type, the 'relationship' (corresponding to a 'predicate') that may be specified by the relation's class or - a special case - a string. Maybe there is a better word for this kind of 'relation'? Helmut ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Yet Another Relations (aka Reference) Engine...
Helmut Merz wrote: >Am Samstag, 12. November 2005 18:00 schrieb Jean-Marc Orliaguet: > > > >>My >>impression is that you are thinking of a reference engine >>rather than a relation engine >> >> > >Maybe I just don't see the difference... (There is one, of >course, but I doubt it is really of relevance in a practical >context. ) > >Helmut > > A relation contains several references: a relation between A, B and C involves 7 references: A with itself B with itself C with itself A with B B with C C with A A with B with C But a set of references don't make explicit relations, unless the application know how to interpret the references. /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: SVN: Zope/trunk/lib/python/ use a specific revision of the Zope 3 trunk for now until we have some sort of tag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: > On Friday 11 November 2005 12:15, Tres Seaver wrote: > >>Philipp von Weitershausen wrote: >> >>>Log message for revision 40048: >>> use a specific revision of the Zope 3 trunk for now until we have some >>>sort of tag available (e.g. a Zope 3.2 beta tag). >> >>We should have cut a Zope3-3.2 beta tag on the day of the feature >>freeze, so that release / stabilization activities could proceed without >>leaving the trunk frozen. In fact, I thought we had committed to do >>first beta for 2.9 and 3.2 on 1 November. Even if we don't branch at >>those points, we should be tagging the freeze point any any intermediate >>"OK, fixed that, now try again" points. > > > Yeah, but the bug day was a big flop for both Zope 2 and Zope 3, so Andreas > and I (and even with Jim's approval) decided not to release. I also will not > cut a branch until more bugs have been fixed, so that I lower the bar for bug > fixers and force people to work on bugs not features. I don't understand avoiding making a beta because of known bugs -- "beta" is not the same as "release candidate," and doesn't imply that there are no known issues. I believe that leaving the trunk frozen for a substantial length of time has a "chilling effect" on the health of the project, which *contributes* to the length of the beta period, rather than shortening it. The poster child for my argument is the 3.1 release cycle, which lasted for 9 months! > BTW, I think that Philipp did the right thing. Depending on a specific > revision is fine, though pointing to the trunk right now would work too, > since it is feature frozen. Depending on numeric revision IDs obscures intent: if we aren't going to make a release branch, and tags from it, then we need at least to be creating "alpha"-ish tags from the trunk, and having dependents use those tags. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDdjxJ+gerLs4ltQ4RAhRqAJ4+5OobRv4YLKrLtMSgwnRnAklxlACglTaC E8AxPKU+/xyxUl7m/MZe0A0= =QQxl -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Yet Another Relations (aka Reference) Engine...
Am Samstag, 12. November 2005 18:00 schrieb Jean-Marc Orliaguet: > The good thing about IntIds is that it leaves the objects > untouched, the bad thing is that it creates a hard coupling > between the integer id that is used to *refer* to the object > and the key that is used to *represent* the object in the > relation. These are really two different aspects. > > In cpsskins when objects are set in relation, it is the > application's responsibility to tell the engine how objects > will be identified in the relation, i.e. with a unique id > (IntIds), or with a URI or a with a name (that may be share > between several objects) ... The relation engine then stores > this key as well as an internal reference to the object. > > so for each object put in relation we have: > - a key (used by the application to query the engine) > - a reference to the object (used internally by the relation > engine to get the object) > > the application only "sees" the keys until the objects get > dereferenced. > > But no 1:1 mapping between the key and the object is imposed > by any external IntIds utility. Which make it possible to ask > the engine: "give me all the portlets associated to the 'left' > slot" even though the 'left' slot is materialized in more than > one instance. Hm, I'm not sure I understand - so it's not the object (more precisely: its unique id) that's indexed but some value provided by the object - so this is indeed some sort of an attribute that's indexed. This I would prefer to solve using relation objects that explicitly handle additional attributes (provided by the objects that are connected by the relation) that may be indexed *in addition* to the unique ids. Or let's see this way: The keys (unique ids in the standard implementation) are retrieved by an adapter to the relation class (providing IIndexableRelation) so this adapter could provide something else if necessary. > In your implementation only objects that are identified > uniquely can be put in relation, and it doesn't seem to be a > design choice other than a limitation imposed by the catalog. Yes, it is a limitation of the default implementation but I'm still not sure it is bad, and it can be overcome easily. > http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches > /j mo -perspectives/storage/relations.py > >>> > >>>I read this, and it indeed gave me the impression that it > >>>might be a not so bad idea to use a catalog ;-) > >> > >>well, you haven't written the catalog indexes yet :-) > > > >I needn't because I just use the FieldIndex from zope.index. > > I understand, but the idea is to index relations, not simply > the references between in the objects put in relation. ACK > My > impression is that you are thinking of a reference engine > rather than a relation engine Maybe I just don't see the difference... (There is one, of course, but I doubt it is really of relevance in a practical context. ) Helmut ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re[4]: [Zope3-dev] ServerControlForm.html / Restart, Shutdown does not work
Hello Stephan, done that, it's issue No 485 Saturday, November 12, 2005, 12:54:21 PM, you wrote: SR> On Friday 04 November 2005 11:50, Adam Groszer wrote: >> I think I have something for tomorrow's bug day. It is not working >> again. I have the current trunk and brand new instance. SR> Could you add it to the issue collector please? SR> Thanks! SR> Regards, SR> Stephan -- Best regards, Groszer Adam -- Quote of the day: A day without sunshine is like night. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Yet Another Relations (aka Reference) Engine...
Helmut Merz wrote: >Am Freitag, 11. November 2005 18:00 schrieb Jean-Marc Orliaguet: > > > >>I was thinking more about the policy of assigning unique ids >>to objects in a relation. It's the application that really >>should decide about that policy. >> >> > >in fact the unique ids aren't "assigned" to the objects (the >objects aren't touched at all) by the IntIds utility - if you >have registered a local IntIds utility they are just created in >the utility driven by the IObjectAdded event. So this IntIds >stuff should not interfere with anything else and the >application should not be concerned at all about it. > > The good thing about IntIds is that it leaves the objects untouched, the bad thing is that it creates a hard coupling between the integer id that is used to *refer* to the object and the key that is used to *represent* the object in the relation. These are really two different aspects. In cpsskins when objects are set in relation, it is the application's responsibility to tell the engine how objects will be identified in the relation, i.e. with a unique id (IntIds), or with a URI or a with a name (that may be share between several objects) ... The relation engine then stores this key as well as an internal reference to the object. so for each object put in relation we have: - a key (used by the application to query the engine) - a reference to the object (used internally by the relation engine to get the object) the application only "sees" the keys until the objects get dereferenced. But no 1:1 mapping between the key and the object is imposed by any external IntIds utility. Which make it possible to ask the engine: "give me all the portlets associated to the 'left' slot" even though the 'left' slot is materialized in more than one instance. In your implementation only objects that are identified uniquely can be put in relation, and it doesn't seem to be a design choice other than a limitation imposed by the catalog. http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/j mo -perspectives/storage/relations.py >>>I read this, and it indeed gave me the impression that it >>>might be a not so bad idea to use a catalog ;-) >>> >>> >>well, you haven't written the catalog indexes yet :-) >> >> > >I needn't because I just use the FieldIndex from zope.index. > > > I understand, but the idea is to index relations, not simply the references between in the objects put in relation. My impression is that you are thinking of a reference engine rather than a relation engine with the difference compared to the Archetype's engine that references are stored outside the objects. /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: SVN: Zope/trunk/lib/python/ use a specific revision of the Zope 3 trunk for now until we have some sort of tag
Stephan Richter wrote: On Friday 11 November 2005 12:15, Tres Seaver wrote: Philipp von Weitershausen wrote: Log message for revision 40048: use a specific revision of the Zope 3 trunk for now until we have some sort of tag available (e.g. a Zope 3.2 beta tag). We should have cut a Zope3-3.2 beta tag on the day of the feature freeze, so that release / stabilization activities could proceed without leaving the trunk frozen. In fact, I thought we had committed to do first beta for 2.9 and 3.2 on 1 November. Actually, I said we ought to be ready for the first beta by Nov 1. :) >> Even if we don't branch at those points, we should be tagging the freeze point any any intermediate "OK, fixed that, now try again" points. Absolutely. Yeah, but the bug day was a big flop for both Zope 2 and Zope 3, so Andreas and I (and even with Jim's approval) decided not to release. I also will not cut a branch until more bugs have been fixed, so that I lower the bar for bug fixers and force people to work on bugs not features. BTW, I think that Philipp did the right thing. Depending on a specific revision is fine, though pointing to the trunk right now would work too, since it is feature frozen. No, it wouldn't. In my strongly held opinion, you should never depend on a trunk or branch unless the people checking in there are running *your* tests before a checkin. A bug fix I made earlier this week actually broke a Five test. Depending on revisions, which you update frequently, provides important stability. The person who updates the revision can first make sure all their tests pass, addressing any issues before checking in. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Extrinsic references
We have a *simple* facility for managing references between objects extrinsically. See: http://svn.zope.org/Sandbox/zc/extrinsicreference/extrinsicreference.txt?view=markup If there is sufficient interest, we plan to move this (tiny) project to the zope repository. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zopeorg-webmaster] Zope3 pages seem woefully outdated
Forwarding ... related to the current [ zope3 website report? ] thread Toni Mueller wrote: Hello, I find that most pages about Zope3 end sometime mid 2004. A lot has happened in the meantime, and I'd like to see updated material on the site. Since I'm rather new to Zope3, I feel not qualified to produce useful content for the site, but having material that old is probably not the best way to make Zope3 take off, as intended. If you have suggestions on how to proceed, or what to do (technically, I find the whole site lacking, and significantly below Zope's capabilities), I'm very much open to any suggestions you might have. Thank you for listening! Kind Regards, --Toni++ ___ Zopeorg-webmaster mailing list [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zopeorg-webmaster Michael -- http://zope.org/Members/d2m http://planetzope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope3 website report?
Stephan Richter wrote: On Tuesday 18 October 2005 21:12, Mikhail Kashkin wrote: I'm also want to offer me as fresh meat in this effort. My proposition for site plan, index pages *mark*:: Having said this, I really wish someone would take ownership in developing our zope3.org site. Unfortunately I have not heard from Uwe anymore, but someone should contact him and see what's going on. With that much interest I would hope that a steady developer group around zope3.org would form. Is that possible? IS someone willed to take the lead? Hi Stephan, And I agree to help zope3.org group. I can spend 2-3 hours everyday. Where to start? -- Regards, Netlander ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Deleting utilities in site management doesn't work correct
On Saturday 12 November 2005 07:12, jürgen Kartnaller wrote: > Ups, sorry here is the attachment. Very nice work! Check it in! Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Deleting utilities in site management doesn't work correct
Ups, sorry here is the attachment. Jürgen Stephan Richter wrote: > On Friday 11 November 2005 12:00, jürgen Kartnaller wrote: > >>I could now manage to have a relatively simple test (see attached file). > > > No file attached in my E-mail. :-( > > >>I also found and fixed some other problems I encountered with the >>utility registration. >> >>Can you please have a look at the test implementation and let me know if >>this look ok. >> >>This test will not work with the current implementation of the >>SiteManagementView ! >>I already fixed some problems in my sandbox. >> >>Problems solved : >>- adding a utility without name >>- renaming utilities to a name another already renamed utility had >>- deleting more than one utility >>- better message support >> - show the message at the utility not just on top of the page >> - show UserError exception as message > > > Sounds very exciting! :-) Thanks a lot for your work! I will also review your > file, once I get it. > > Regards, > Stephan -- --- Jürgen Kartnaller mailto:juergen_at_kartnaller.at http://www.kartnaller.at http://www.mcb-bregenz.at --- == The Tools View == >>> from zope import interface First we define a utility to work with : >>> from zope.app.content.interfaces import IContentType >>> from zope.app.component.interfaces.registration import IRegisterable >>> class IFooUtil(interface.Interface): ... pass >>> class FooUtil(object): ... __parent__ = None ... __name__ = u'' ... interface.implements(IFooUtil, IRegisterable, IContentType) >>> from zope.app.component.browser import tools >>> from zope import component >>> toolConfig = tools.ToolConfiguration(IFooUtil, 'FooUtil') >>> component.provideUtility(toolConfig, tools.IToolConfiguration, 'IFooUtil') We need a factory to create our new utility : >>> from zope.component.interfaces import IFactory >>> from zope.component.factory import Factory >>> from zope.app.security import protectclass >>> protectclass.protectName(Factory, '__call__', 'zope.public') >>> factory = Factory(FooUtil, ... 'Utility for foo', ... 'This factory creates a foo utility.') >>> component.provideUtility(factory, IFactory, 'IFooUtil') Let's now invoke our site management : >>> from zope.publisher.browser import TestRequest >>> request = TestRequest() >>> request.form['activeTool']='IFooUtil' >>> from zope.app import zapi >>> view = tools.SiteManagementView(zapi.getSiteManager(), request) >>> view.update() u'' >>> request.form['ADD-TOOL-SUBMIT']='submit' >>> request.form['type_name']='IFooUtil' >>> request.form['id']='foo1' >>> view.update() u'' >>> util = component.getUtility(IFooUtil, 'foo1') >>> util is not None True >>> current_tools = view.getTools() >>> len(current_tools) 1 >>> current_tools[0]['instances'][0]['name'] 'foo1' Registering with the same name -- >>> print view.update() The given tool name is already being used. >>> request.form['id']='foo2' >>> view = tools.SiteManagementView(zapi.getSiteManager(), request) >>> view.update() u'' >>> current_tools = view.getTools() >>> current_tools[0]['instances'][0]['name'] 'foo1' >>> current_tools[0]['instances'][1]['name'] 'foo2' Creating a utility without a name - >>> request.form['id']='' >>> view = tools.SiteManagementView(zapi.getSiteManager(), request) >>> view.update() u'' >>> current_tools = view.getTools() >>> current_tools[0]['instances'][0]['name'] 'foo1' >>> current_tools[0]['instances'][1]['name'] 'foo2' >>> current_tools[0]['instances'][2]['name'] u'' Renaming utilities -- >>> request = TestRequest() >>> request.form['activeTool']='IFooUtil' >>> request.form['RENAME-SUBMIT']='submit' First we rename a single utility : >>> request.form['old_names']=['foo1'] >>> request.form['new_names']=['JohnDoe'] >>> view = tools.SiteManagementView(zapi.getSiteManager(), request) >>> view.update() u'Tools successfully renamed.' >>> current_tools = view.getTools() >>> current_tools[0]['instances'][0]['name'] 'JohnDoe' >>> current_tools[0]['instances'][1]['name'] 'foo2' >>> current_tools[0]['instances'][2]['name'] u'' >>> request.form['old_names']=['JohnDoe', 'foo2'] >>> request.form['new_names']=['foo1', 'Tres'] >>> view = tools.SiteManagementView(zapi.getSiteManager(), request) >>> view.update() u'Tools successfully renamed.' >>> current_tools = view.getTools() >>> current_tools[0]['instances'][0]['name'] 'foo1' >>> current_tools[0]['instances'][1]['name'] 'Tres' >>> current_tools[0]['instances'][2]['name'] u'' Deleting utilities -- >>> request = TestRequest
Re: [Zope3-dev] Re: Deleting utilities in site management doesn't work correct
On Friday 11 November 2005 12:00, jürgen Kartnaller wrote: > I could now manage to have a relatively simple test (see attached file). No file attached in my E-mail. :-( > I also found and fixed some other problems I encountered with the > utility registration. > > Can you please have a look at the test implementation and let me know if > this look ok. > > This test will not work with the current implementation of the > SiteManagementView ! > I already fixed some problems in my sandbox. > > Problems solved : > - adding a utility without name > - renaming utilities to a name another already renamed utility had > - deleting more than one utility > - better message support > - show the message at the utility not just on top of the page > - show UserError exception as message Sounds very exciting! :-) Thanks a lot for your work! I will also review your file, once I get it. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope3 design question
On Thursday 10 November 2005 11:17, rubberduckee wrote: > I know that this might be too general a question (or perhaps a dumb > one) but I'm hoping that someone could help guide me in the right > direction. Please send those types of questions to [EMAIL PROTECTED] > How does one go about designing an application that will > allow for dynamic schemas i.e. schemas built at run time? You would need persistent schemas. Unfortunately persistent schemas are broken right now. > Users would be able to 'extend' the schemas TTW. Persistent schemas do exactely allow this. The code is in the trunk, but your schemas will loose changes due to a bug. The problem is known, but has not been tackled. > Would using a database be a better option rather that to use ZopeDB or a > marriage of both? Depends on what you like. I would always use the ZODB for my stuff. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] conflict error in configuration file
On Sunday 06 November 2005 03:23, baiju m wrote: > I am developing small Zope3 app using Zope 3.1, > today when I installed Zope svn trunk, I got two conflict errors. > > I used a 'title' which is same as that used in zwiki (addMenuItem > directive). and 'name' in addform directive. The problem here is that menu items are named adapters and are thus discriminated by their name. In the case of menu items this is suboptimal. I agree with you that you should be allowed to have several menu items with the same name. Your fix below is definitely unacceptable, because it fixes the issue and the wrong place. The real fix would be to not make the menu item name the same as the title. It would be great, if you could fix the issue; if you do not have the time or skills, please file a bug issue, at least. Thanks a lot! Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.app.appsetup.bootstrap proposal
On Friday 04 November 2005 14:07, Adam Groszer wrote: > I think (that may be stupid, because I'm not an expert) that the > module is not 100% consistent, once it is checking on the passed > folder's SiteManager (in ensureUtility) and then tries to add the > utility to a maybe completely different SM (in addUtility). > > I propose a change to getSiteManagerDefault: > > def getSiteManagerDefault(root_folder): > #default = zapi.traverse(folder.getSiteManager(), 'default') > #package_name = '/++etc++site/default' > #package = traverse(root_folder, package_name) > package = traverse(root_folder.getSiteManager(), 'default') > return package > > After that the module could be used even on sub-sites. +1 for the change. Please write a test and check that in. If you cannot check it in, put the fix and the test into the issue collector please. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Re[2]: [Zope3-dev] ServerControlForm.html / Restart, Shutdown does not work
On Friday 04 November 2005 11:50, Adam Groszer wrote: > I think I have something for tomorrow's bug day. It is not working > again. I have the current trunk and brand new instance. Could you add it to the issue collector please? Thanks! Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Changing zope.app.rdb to better support sqlos
On Monday 07 November 2005 10:18, Brian Sutherland wrote: > > Please don't check this in yet, I want to review the problem before you > > do, because I think specific interfaces are just nuts unless we have a > > very good reason. > > Sure;) > > The guts of the issue are how to know what type of SQL the connection > accepts so that sqlos can choose the right adapter for it. An interface > seemed best. After thinking about it on and off for the last week, I agree now. The simplest, easiest and most effective solution are specific interfaces. *sigh* Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] (zope/app/cache/ram.py) class Storage's cleanup problem.
On Tuesday 01 November 2005 05:10, Simon Hang wrote: > Dear all, > > I'm happen to find out call Storage only do cleanup when new Entry comes > and do nothing when entries get from storage. So entries will be next > expired if there are only read activities. I agree with your analysis and solution. If you provide a test for the fix, I'll check it in. If you cannot write a test, please add least add an issue to the issue collector. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] tagged value handling inconsequent for interface methods and attributes and interfaces themself
On Tuesday 01 November 2005 04:27, Grégoire Weber wrote:
> 2005/10/24, Stephan Richter <[EMAIL PROTECTED]>:
> > class IFoo(zope.interface.Interface):
> >
> > attr = zope.interface.Attribute('doc string')
> > ITaggedValues(attr).someVariable = value
> >
> > Any comments before I spend time writing this up?
>
> The drawback*) of this is that the adapter registry has to be in place.
>
> *) Mostly a drawback if you only use ``zope.interface``
No it does not need to necessarily, because the __conform__ method is called
before a standard adapter lookup is made. Also, for those type of scenarios
we could have a custom adapter registry. Luckily adapter registries are
implemented in zope.interface.adapter, so no external packages would be
necessary.
Regards,
Stephan
--
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
---
--
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] simpleTraverse raises NameError?
On Sunday 23 October 2005 03:12, Stefan H. Holek wrote: > So, is there or would this qualify as a bug? There is a test that > seems to point to some use with regard to namespaces, but I don't see > how this wouldn't work just as well with AttributeError. I definitely think this is a bug. I guess the | operator should simply also know how to deal with NameError. Stefan, it would be great if you could fix this or at least file a bug report. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] initial checkin of cxoracleda
On Thursday 20 October 2005 11:19, Bernd Dorn wrote:
> in my testcase http://svn.zope.org/cxoracleda/trunk/tests/
> test_adapter.py?rev=39515&view=auto
You need to bug Jim, so that this directory is part of the Zope3-Checkins
mailing list. ;-)
> i need to somehow get the connection information from a property
> file, is this the right way to do this
>
> i do this like this::
>
> import os
> propFile = os.path.join(os.environ.get('HOME'),"etc/zope/cxoracleda/
> testproperties.py")
>
> try:
> execfile(propFile)
> except:
> raise "Local property file not found",propFile
>
> this is a problem i think for automated tests etc.
>
> any sugestions ?
This is a problem. It would be easier if you add a sample configuration file
in your test directory, e.g. cxoracle/tests/configfile.py and then reference
it as follows in your test:
import os
dir = os.path.dirname(__file__)
config = os.path.join(dir, 'configfile.py')
Regards,
Stephan
--
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope3 website report?
On Tuesday 18 October 2005 21:12, Mikhail Kashkin wrote: > I'm also want to offer me as fresh meat in this effort. > > My proposition for site plan, index pages *mark*:: Hi Mikhail, the outline is nice, but contains items that we do not have already; for example it has a huge documentation section with lots of items, but none of this type of documentation exists and you cannot expect it to magically appear. Having said this, I really wish someone would take ownership in developing our zope3.org site. Unfortunately I have not heard from Uwe anymore, but someone should contact him and see what's going on. With that much interest I would hope that a steady developer group around zope3.org would form. Is that possible? IS someone willed to take the lead? Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: SVN: Zope/trunk/lib/python/ use a specific revision of the Zope 3 trunk for now until we have some sort of tag
On Friday 11 November 2005 12:15, Tres Seaver wrote: > Philipp von Weitershausen wrote: > > Log message for revision 40048: > > use a specific revision of the Zope 3 trunk for now until we have some > > sort of tag available (e.g. a Zope 3.2 beta tag). > > We should have cut a Zope3-3.2 beta tag on the day of the feature > freeze, so that release / stabilization activities could proceed without > leaving the trunk frozen. In fact, I thought we had committed to do > first beta for 2.9 and 3.2 on 1 November. Even if we don't branch at > those points, we should be tagging the freeze point any any intermediate > "OK, fixed that, now try again" points. Yeah, but the bug day was a big flop for both Zope 2 and Zope 3, so Andreas and I (and even with Jim's approval) decided not to release. I also will not cut a branch until more bugs have been fixed, so that I lower the bar for bug fixers and force people to work on bugs not features. BTW, I think that Philipp did the right thing. Depending on a specific revision is fine, though pointing to the trunk right now would work too, since it is feature frozen. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
