[Zope3-dev] RE: Zope3-dev Digest, Vol 28, Issue 48
Fabrice Monaco
fmonaco at cirb.irisnet.be
Fri Nov 25 08:28:57 EST 2005
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: zope3-dev-bounces+fmonaco=cirb.irisnet.be at zope.org
[mailto:zope3-dev-bounces+fmonaco=cirb.irisnet.be at zope.org]On Behalf Of
zope3-dev-request at zope.org
Sent: vendredi 25 novembre 2005 11:57
To: zope3-dev at zope.org
Subject: Zope3-dev Digest, Vol 28, Issue 48
Send Zope3-dev mailing list submissions to
zope3-dev at zope.org
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
zope3-dev-request at zope.org
You can reach the person managing the list at
zope3-dev-owner at zope.org
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 <chris at simplistix.co.uk>
Subject: Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source
code repository
To: Julien Anguenot <ja at nuxeo.com>
Cc: Philipp von Weitershausen <philipp at weitershausen.de>,
zope3-dev at zope.org, zope-dev at zope.org
Message-ID: <4385FBFF.6080006 at simplistix.co.uk>
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 <pw_lists at slinkp.com>
Subject: Re: [Zope-dev] Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3
in the source code repository
To: zope-dev at zope.org, zope3-dev at zope.org
Message-ID: <20051124174459.GD9128 at slinkp.com>
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 <pw_lists at slinkp.com>
Subject: Re: [Zope3-dev] RE: Zope3-dev Digest, Vol 28, Issue 41
To: zope3-dev at zope.org
Message-ID: <20051124174812.GE9128 at slinkp.com>
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 <faassen at infrae.com>
Subject: Re: [Zope-dev] Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3
in the source code repository
To: Paul Winkler <pw_lists at slinkp.com>
Cc: zope3-dev at zope.org, zope-dev at zope.org
Message-ID: <4385FF92.4020906 at infrae.com>
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 <pw_lists at slinkp.com>
Subject: Re: [Zope-dev] Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3
in the source code repository
To: zope-dev at zope.org, zope3-dev at zope.org
Message-ID: <20051124180628.GG9128 at slinkp.com>
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 <jmo at ita.chalmers.se>
Subject: Re: [Zope-CMF] Re: [Zope3-dev] Retaining ease of
customisation
To: Martin Aspeli <optilude at gmx.net>
Cc: zope3-dev at zope.org
Message-ID: <43860C43.602 at ita.chalmers.se>
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 <srichter at cosmos.phy.tufts.edu>
Subject: Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source
code repository
To: zope3-dev at zope.org, jim at zope.com
Cc: Philipp von Weitershausen <philipp at weitershausen.de>,
zope-dev at zope.org
Message-ID: <200511241508.57242.srichter at cosmos.phy.tufts.edu>
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 <jmo at ita.chalmers.se>
Subject: Re: [Zope-CMF] Re: [Zope3-dev] Retaining ease of
customisation
To: Martin Aspeli <optilude at gmx.net>
Cc: zope3-dev at zope.org
Message-ID: <4386395D.5040705 at ita.chalmers.se>
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 <gary at zope.com>
Subject: Re: [Zope3-dev] zope.testbrowser.browser problem
To: Chris Withers <chris at simplistix.co.uk>
Cc: zope3-dev at zope.org
Message-ID: <7BD155DD-A084-4D29-866C-892A2CCF101D at zope.com>
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 <jmo at ita.chalmers.se>
Subject: Re: [Zope-CMF] Re: [Zope3-dev] Retaining ease of
customisation
To: Martin Aspeli <optilude at gmx.net>
Cc: zope3-dev at zope.org
Message-ID: <4386EB94.6080601 at ita.chalmers.se>
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
Zope3-dev at zope.org
http://mail.zope.org/mailman/listinfo/zope3-dev
End of Zope3-dev Digest, Vol 28, Issue 48
*****************************************
More information about the Zope3-dev
mailing list