Problem in zope 3, this is developper use speudo interface, because the interface inherit others interfaces, there are one or more dependace, the philosophy of Design Pattern this just avoid heritage. normaly, a developper passe by interface or in the concept of zope3 a developper create one class who passe by interface (heritage disguised)? Where are you simplification ?
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: vendredi 25 novembre 2005 11:57 To: [email protected] Subject: Zope3-dev Digest, Vol 28, Issue 48 Send Zope3-dev mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit http://mail.zope.org/mailman/listinfo/zope3-dev or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than "Re: Contents of Zope3-dev digest..." Today's Topics: 1. Re: RFC: Reunite Zope 2 and Zope 3 in the source code repository (Chris Withers) 2. Re: [Zope-dev] Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository (Paul Winkler) 3. Re: RE: Zope3-dev Digest, Vol 28, Issue 41 (Paul Winkler) 4. Re: [Zope-dev] Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository (Martijn Faassen) 5. Re: [Zope-dev] Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository (Paul Winkler) 6. Re: [Zope-CMF] Re: [Zope3-dev] Retaining ease of customisation (Jean-Marc Orliaguet) 7. Re: RFC: Reunite Zope 2 and Zope 3 in the source code repository (Stephan Richter) 8. Re: [Zope-CMF] Re: [Zope3-dev] Retaining ease of customisation (Jean-Marc Orliaguet) 9. Re: zope.testbrowser.browser problem (Gary Poster) 10. Re: [Zope-CMF] Re: [Zope3-dev] Retaining ease of customisation (Jean-Marc Orliaguet) ---------------------------------------------------------------------- Message: 1 Date: Thu, 24 Nov 2005 17:44:31 +0000 From: Chris Withers <[EMAIL PROTECTED]> Subject: Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository To: Julien Anguenot <[EMAIL PROTECTED]> Cc: Philipp von Weitershausen <[EMAIL PROTECTED]>, [email protected], [email protected] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Julien Anguenot wrote: > Some Zope3 developers don't care about Zope2 and this is fair enough in > my point of view. Zope2 starts to get old and appears to be really a > mess compared to Zope3 in *2005*, plus it's not such an attractive > platform as it used to be couple of years ago. (Don't get me wrong on > this. Time just changed. I'm using Zope2 much more than Zope3 nowadays > and still I like it even if I'm *dreaming* about only using a modern > platform "` la" Zope3) I would fear that some new folks might find the > Zope3 project much more confusing and less attractive because of the > Zope2 mess around. (common mailing list, common repository etc...) > > Please, let's not mess up Zope3... + lots to this... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ------------------------------ Message: 2 Date: Thu, 24 Nov 2005 12:44:59 -0500 From: Paul Winkler <[EMAIL PROTECTED]> Subject: Re: [Zope-dev] Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository To: [email protected], [email protected] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=us-ascii On Thu, Nov 24, 2005 at 11:03:35PM +0800, Philipp von Weitershausen wrote: > > I'd love to participate in some sprints on these. > > Me too. PyCon Dallas 2006 is only 3 months away and would be a great opportunity for such sprints. There's nothing about Zope here yet: http://wiki.python.org/moin/PyCon2006/Sprints I plan to attend and I would really love to sprint on further "fivification" of zope 2. p.s. No, I can't volunteer to do any coordination work for this. I'll already have plenty to do preparing for my two (Five-related) talks. -- Paul Winkler http://www.slinkp.com ------------------------------ Message: 3 Date: Thu, 24 Nov 2005 12:48:12 -0500 From: Paul Winkler <[EMAIL PROTECTED]> Subject: Re: [Zope3-dev] RE: Zope3-dev Digest, Vol 28, Issue 41 To: [email protected] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=us-ascii On Thu, Nov 24, 2005 at 12:01:58PM +0100, Fabrice Monaco wrote: > Hi, > > I saw a new architectur of Zope 3, In Zope 3 integrate concept of adapter. I > think that is good idea, but I think that concept is false beacause in > python language don't support the class "interface", is necessary for > respect the Design Pattern. Do you think who would be better to do to evolve > language python for support the class "interface" also java? I think you're missing a big point - namely, zope.interfaces and the extensive usage of it throughout zope 3. There have been proposals to add interfaces to the Python core, but nothing has been decided yet. See for example http://python.org/peps/pep-0245.html which is getting a bit old (it predates zope 3). Other projects are using zope.interfaces, too - at least Twisted is. -- Paul Winkler http://www.slinkp.com ------------------------------ Message: 4 Date: Thu, 24 Nov 2005 18:59:46 +0100 From: Martijn Faassen <[EMAIL PROTECTED]> Subject: Re: [Zope-dev] Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository To: Paul Winkler <[EMAIL PROTECTED]> Cc: [email protected], [email protected] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Paul Winkler wrote: > On Thu, Nov 24, 2005 at 11:03:35PM +0800, Philipp von Weitershausen wrote: > >>>I'd love to participate in some sprints on these. >> >>Me too. > > PyCon Dallas 2006 is only 3 months away and would be a great opportunity > for such sprints. There's nothing about Zope here yet: > http://wiki.python.org/moin/PyCon2006/Sprints > I plan to attend and I would really love to sprint on further > "fivification" of zope 2. That'd be really cool. > p.s. No, I can't volunteer to do any coordination work for this. I'll > already have plenty to do preparing for my two (Five-related) talks. Cool to hear you're giving Five related talks. Is there any description of these available online? (not that it's likely I'll be able to attend PyCon, but I'm very curious) Regards, Martijn ------------------------------ Message: 5 Date: Thu, 24 Nov 2005 13:06:28 -0500 From: Paul Winkler <[EMAIL PROTECTED]> Subject: Re: [Zope-dev] Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository To: [email protected], [email protected] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=us-ascii On Thu, Nov 24, 2005 at 06:59:46PM +0100, Martijn Faassen wrote: > Cool to hear you're giving Five related talks. Is there any description > of these available online? (not that it's likely I'll be able to attend > PyCon, but I'm very curious) http://wiki.python.org/moin/PyCon2006/Talks They're just basic "How to develop with Zope" and "...CMF" talks, with as much Five as I can squeeze in since it's 2006 and it would be criminal to ignore it :-) I will not even remotely attempt to be comprehensive or deep. It will be very challenging to work in the short time slots alotted! I was a bit surprised that both talks were accepted, I figured I'd be trumped by presentations from better-known people, but maybe there weren't any! -- Paul Winkler http://www.slinkp.com ------------------------------ Message: 6 Date: Thu, 24 Nov 2005 19:53:55 +0100 From: Jean-Marc Orliaguet <[EMAIL PROTECTED]> Subject: Re: [Zope-CMF] Re: [Zope3-dev] Retaining ease of customisation To: Martin Aspeli <[EMAIL PROTECTED]> Cc: [email protected] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Martin Aspeli wrote: > >A lot of people go with Plone initially based strongly on how easy it is to >customise and re-use elements of the UI. I really don't want to take that >incentive away from them. Yet, as I understand, if global_contentmenu.pt was >implemented as a View, they couldn't customise it TTW and it would be more >difficult (in fact, in my journey through the Five and some of the Z3 >documentation, I've yet to discover how) to override this even if they were >prepared to set up a bunch of directories and XML files. > > > then you wouldn't customize the view, you would customize the *template* used by the view.. Martin, this is why I'm asking: are you sure you want to customize the entire *view* TTW or just the resources used by the view? >So, whilst CPSSkins probably is a long term better solution for many of the >original use cases, it's unlikely to form a core part of the Plone UI in the >near future, and indeed unlikely to be appropriate for every type of >application. > which use cases? >In the interest of evolution, I'd like to find out how to make it >as easy as possible for people to override templates that are parts of views. >Unfortunately I'm still lost. :) > >Martin > > > Then see my previous post that explains how to customize "templates that are part of views", replacing the word "template" with "resources" ... cheers /JM ------------------------------ Message: 7 Date: Thu, 24 Nov 2005 15:08:57 -0500 From: Stephan Richter <[EMAIL PROTECTED]> Subject: Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository To: [email protected], [EMAIL PROTECTED] Cc: Philipp von Weitershausen <[EMAIL PROTECTED]>, [email protected] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="iso-8859-1" On Thursday 24 November 2005 09:17, Jim Fulton wrote: > Now (well, after the December release :), I think it's time to revisit > what the core of Zope 3 is and how we manage the repository. There has > been a trend to manage important components separately and link them in. I > see this trend continuing. The advent of eggs and continuing maturation of > zpkg and testing technology will accelerate this trend, IMO. > > I think that in the future, there may be a much smaller core Zope 3 project > that represents the "object filing system" (zope.ofs? :). This core project > may be a client of a collection of much smaller projects, such as > zope.interface, zope.component. etc.. If that vision comes to pass, Zope 2 > will no longer contain the Zope 3 core, but they will both share a large > number of components which neither of them "contain". Obviously, this > would radically change the nature of this debate. I was counting on you making exactly this suggestion. :-) I agree with all of that. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ------------------------------ Message: 8 Date: Thu, 24 Nov 2005 23:06:21 +0100 From: Jean-Marc Orliaguet <[EMAIL PROTECTED]> Subject: Re: [Zope-CMF] Re: [Zope3-dev] Retaining ease of customisation To: Martin Aspeli <[EMAIL PROTECTED]> Cc: [email protected] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Martin Aspeli wrote: > > On 24 Nov 2005, at 18:53, Jean-Marc Orliaguet wrote: > >> Martin Aspeli wrote: >> >>> >>> A lot of people go with Plone initially based strongly on how easy >>> it is to >>> customise and re-use elements of the UI. I really don't want to >>> take that >>> incentive away from them. Yet, as I understand, if >>> global_contentmenu.pt was >>> implemented as a View, they couldn't customise it TTW and it would >>> be more >>> difficult (in fact, in my journey through the Five and some of the Z3 >>> documentation, I've yet to discover how) to override this even if >>> they were >>> prepared to set up a bunch of directories and XML files. >>> >>> >> >> then you wouldn't customize the view, you would customize the >> *template* used by the view.. >> >> Martin, this is why I'm asking: are you sure you want to customize >> the entire *view* TTW or just the resources used by the view? > > > I think there are two cases: The first is the "tinkerer", who wants > to customise primarily the template as easily as possible, preferably > TTW. > OK, I buy this. You want to be able to modify resources, try different options ... Then you might want to export them the filesystem. > The serious developer wants to customise/override the whole view. > there I'm dubious. "Serious" developers would have a better time writing the code directly in python on the filesystem. the approach in cpsskins is to write the UI components (portlets, widgets) on the filesystem and to combine them through the web. I don't see the point in having a 100% TTW approach. Some of the components need only be written (dropdown menus, boxes, ..). and they should not be changed afterwards however there is a use case which is not currently covered: it's the ability to write the "control" part of the MVC trough the web. but again you can also customize parts of the view (e.g. scripts) in the same way as you'd customize the template You still don't have to customize the entire view. > I think both groups are equally important, though. Even though > overriding the template may mean people put random python: > expressions and make a mess, this is an important way of letting > people tinker, learn, explore and ultimately commit to the platform. > >>> So, whilst CPSSkins probably is a long term better solution for >>> many of the >>> original use cases, it's unlikely to form a core part of the Plone >>> UI in the >>> near future, and indeed unlikely to be appropriate for every type of >>> application. >> >> >> which use cases? > > > To be honest, I haven't played with it sufficiently to know all its > capabilities, but it seems likely that unless you can edit every bit > of every part of the UI, right down to each tag, and changing logic > (e.g. when to display a particular part) as well as presentation, > someone will come up with some use case they desperately need. > this is covered already and in a more flexible and point-and-click way than it is currently done with page templates... the page template approach gives a *feeling* a control. what you call "changing logic (e.g. when to display a particular part)" is done through "perspectives", what you call "editing of every part of the UI right down to each tag" is called "creating a widget". >>> In the interest of evolution, I'd like to find out how to make it >>> as easy as possible for people to override templates that are parts >>> of views. >>> Unfortunately I'm still lost. :) >>> >>> Martin >>> >>> >> Then see my previous post that explains how to customize "templates >> that are part of views", replacing the word "template" with >> "resources" ... > > > Okay, I didn't follow that completely, but I'll try to take another > look. Is this CPSSkins-dependent, though, or is it generic Z3 > mechanism you were describing? > the principle is independent of cpsskins (works in zope3 using utilities), and implemented for cpsskins using a resource manager to be able to write: resources = IResourceManager(setting) resources.customize(name=name, context=context) instead of writing 10 lignes of code each time here are a few pointers if you want to get the background discussion: - http://comments.gmane.org/gmane.comp.web.zope.zope3.ecm.general/466 - http://permalink.gmane.org/gmane.comp.web.zope.zope3.ecm.general/488 - http://www.z3lab.org/sections/blogs/jean-marc-orliaguet/2005_11_10_unified-m odel-for > Specifically, I want to be able to customise a template bound to a > view in Five in Plone right now. Of course, I'm also interested in > the longer term view, in how this fits into Zope 3, and in better > ways of doing things than what may be immediately available. > > Martin > sure, this requires a bit of a setup but this is feasible... you need to register templates as utilities and convert them to local utilities in order to customize them. regards /JM ------------------------------ Message: 9 Date: Thu, 24 Nov 2005 22:43:51 -0500 From: Gary Poster <[EMAIL PROTECTED]> Subject: Re: [Zope3-dev] zope.testbrowser.browser problem To: Chris Withers <[EMAIL PROTECTED]> Cc: [email protected] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Nov 24, 2005, at 6:04 AM, Chris Withers wrote: > Hi All, > > Not sure if this is the right place to report this, please let me > know if I should do so somewhere else... No idea, sounds reasonable. > I have a form as follows: > > <form action="aPythonScript" > method="POST" name="form_name"> > ... > <input type="submit" name="action" value=" Go " /> > <input type="submit" name="action" value=" Do Something " /> > ... > </form> > > Now, I do the following with a zope.testbrowser.browser: > > browser.getForm(name='form_name').getControl(' Do Something ').click() > > However, the value of REQUEST.form['action'] in aPythonScript is " > Go ", not " Do Something ", as I'd expect. > > Any idea what's causing this and how I can fix it? Unfortunately, not off-hand. If you send me a smallest-possible- failing doctest (which might be pretty close to this email?) I'll look at it and try to make it pass. Gary ------------------------------ Message: 10 Date: Fri, 25 Nov 2005 11:46:44 +0100 From: Jean-Marc Orliaguet <[EMAIL PROTECTED]> Subject: Re: [Zope-CMF] Re: [Zope3-dev] Retaining ease of customisation To: Martin Aspeli <[EMAIL PROTECTED]> Cc: [email protected] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Martin Aspeli wrote: >>> >>> I think there are two cases: The first is the "tinkerer", who >>> wants to customise primarily the template as easily as possible, >>> preferably TTW. >>> >> OK, I buy this. You want to be able to modify resources, try >> different options ... Then you might want to export them the >> filesystem. > > > Absolutely. The "export" part is important, too. :) And the import too.. from the filesystem to the memory before you do the customization. Currently this is done via ZCML, but for resources this is not always optimal, so currently resources are imported using an xmlpickle. http://svn.z3lab.org/trac/z3lab/file/cpsskins/branches/jmo-perspectives/conf iguration/resources/metaconfigure.py > >>> The serious developer wants to customise/override the whole view. >>> >> >> there I'm dubious. "Serious" developers would have a better time >> writing the code directly in python on the filesystem. > > > I agree, totally. However, such developers may still want to re-use > as much as possible of other people's work, e.g. by overriding only > those parts of the UI they want to change. Most Plone skin products > work this way, at least - provide a custom stylesheet, override a few > templates that are included from main_template etc. > OK, but I would count them as "serious site designers" not as serious developers. Doing site design shouldn't require so much developer knowledge (python, ZPT, ZCML, HTML...). Application design on the other hand requires that type of knowledge, but only for the application logic (not so much for the visual part). the pattern used in cpsskins which may also be useful in plone is to separate between "resources" and "settings": - resources are just objects in the ZODB that users can play with (customize, modify, ..) - settings embed resources and they are registered by site managers centrally. It means that get an "official" status resources can become settings, and settings can be used as resource factories. for instance a page designer may create a new style of box (a resource) and if the style is retained as the "default box style" for the site, the site designer will be able to take the resource and create a setting out of it and call it "the default box style". other users will be able to use the box style setting and create their own resource out of it, customize it, and so on. I think that you need to define in Plone what belongs to the application and what belongs to the user. >> the approach in cpsskins is to write the UI components (portlets, >> widgets) on the filesystem and to combine them through the web. I >> don't see the point in having a 100% TTW approach. Some of the >> components need only be written (dropdown menus, boxes, ..). and >> they should not be changed afterwards > > > "Should" is relative, though. I totally agree that the "composition" > use case is strong, probably much stronger. But the question is, how > small are your components? And how hard is it to provide new ones? > Like Erik said, he wants to customise what's inside > global_contentmenu. We didn't make that piece small enough for him to > customise without writing some code. And of course, if we end up with > one .pt for each <div>, it'll be unmanageable. So there will always > be some need for tinkering with templates. And the "tinkerer" type > new/quick&dirty developer wants to be able to do that without having > to learn an obscure and complex stack. > this is covered, I'm going to start writing the tutorial part for how to create new widgets next week and add it to: http://www.medic.chalmers.se/~jmo/Zope3/ecm/cpsskins/README.html It is fairly easy to write new widgets, this is done in python, the only difficulty is how to manage everything around it (registration, combination of portlets and widgets ..) http://svn.z3lab.org/trac/z3lab/file/cpsskins/branches/jmo-perspectives/engi nes/default/filters/widget/widgets.py >> however there is a use case which is not currently covered: it's the >> ability to write the "control" part of the MVC trough the web. >> >> but again you can also customize parts of the view (e.g. scripts) >> in the same way as you'd customize the template You still don't have >> to customize the entire view. > > > Indeed. I think this is probably covered by existing technology (not > that I know enough about it to be totally sure of all the > implications). It's the "tinkerer" group I'm trying to speak up for, > because frankly they don't read these lists, but they are a very > important influx into our communities, and we need not to drive them > away. absolutely >>> >>> To be honest, I haven't played with it sufficiently to know all >>> its capabilities, but it seems likely that unless you can edit >>> every bit of every part of the UI, right down to each tag, and >>> changing logic (e.g. when to display a particular part) as well as >>> presentation, someone will come up with some use case they >>> desperately need. >>> >> >> this is covered already and in a more flexible and point-and-click >> way than it is currently done with page templates... >> the page template approach gives a *feeling* a control. >> >> what you call "changing logic (e.g. when to display a particular >> part)" is done through "perspectives", what you call "editing of >> every part of the UI right down to each tag" is called "creating a >> widget". > > > It sounds quite cool. Do you have any understanding of how applicable > this may be for something like Plone? That is, an existing Zope 2 > application that uses a structured set of templates (basically, > main_template has a main_slot that things like document_view will > fill in with content, and it includes a bunch of macros for the > various elements of the UI). > the architecture is quite different actually since it is a complete redesign of the template / macros machinery but without ZPTs .. > Is it accessible in Z2/Five? > no idea, yet. > Is it possible to re-use existing structures? > > Would it require a complete UI rewrite? > > Would it be possible to make products that use the "old" structure > (basically, call main_template and fill a "main" content slot in 95% > of the cases) still work? > The only thing that's left from page templates is the ability to display the content of the "main" macro slot used in the master template. In this way the main content area of existing applications can be preserved, but everything around it (boxes, navigation, images, actions) is replaced. Best regards.. /JM ------------------------------ _______________________________________________ Zope3-dev mailing list [email protected] http://mail.zope.org/mailman/listinfo/zope3-dev End of Zope3-dev Digest, Vol 28, Issue 48 ***************************************** _______________________________________________ Zope3-dev mailing list [email protected] Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
