[Zope-dev] (no subject)

2006-10-09 Thread 快看




___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] (no subject)

2006-10-09 Thread 免费




___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] (no subject)

2006-10-09 Thread 真的

与美女视频聊天直播,按此进入


___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Re: Moving ZopeVersionControl to subversion?

2006-10-09 Thread Miles Waller


I noticed that Tres was making changes in CVS and preparing a 0.3.2
release, so there is at least some activity.



That was me ... I badgered Tres into incorporating a patch I'd put into 
the tracker.  Before that there was no activity.


It definitely doesn't have a maintainer.  There are clues that there are 
people out there using it, but noone has admitted so 'in the open'!


Miles

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Maintainer of Zope 2 Windows builds?

2006-10-09 Thread Chris Withers

Sidnei da Silva wrote:

On Sat, Oct 07, 2006 at 09:25:29AM +0200, Andreas Jung wrote:
| Who is currently in charge or who feels responsible for the Windows builds?

Tim Peters.


Er, no. Tim isn't even at Zope Corp anymore, as far as I know...

I built the last couple of Zope 2.9.x release, but my access to a 
Windows build environment is gone now...


Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Re: Moving ZopeVersionControl to subversion?

2006-10-09 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Miles Waller wrote:

 I noticed that Tres was making changes in CVS and preparing a 0.3.2
 release, so there is at least some activity.

 
 That was me ... I badgered Tres into incorporating a patch I'd put into
 the tracker.  Before that there was no activity.
 
 It definitely doesn't have a maintainer.  There are clues that there are
 people out there using it, but noone has admitted so 'in the open'!

I don't see a problem with moving ZVC into Subversion;  I do think that
those who have an interest in it should work together to name a
maintainer (and I'm *not* volunteering ;)


Tres.
- --
===
Tres Seaver  +1 202-558-7113  [EMAIL PROTECTED]
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFKmuz+gerLs4ltQ4RAiPzAJ4qw4dzq1kqYgW+HsLpn3b0n2OVzQCfWYOV
eWFTWVEWDfr0tpoQBvCWbqc=
=fRmI
-END PGP SIGNATURE-

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Maintainer of Zope 2 Windows builds?

2006-10-09 Thread Sidnei da Silva
On Mon, Oct 09, 2006 at 03:25:55PM +0100, Chris Withers wrote:
| Sidnei da Silva wrote:
| On Sat, Oct 07, 2006 at 09:25:29AM +0200, Andreas Jung wrote:
| | Who is currently in charge or who feels responsible for the Windows 
| builds?
| 
| Tim Peters.
| 
| Er, no. Tim isn't even at Zope Corp anymore, as far as I know...

That shouldn't be related, should it?

| I built the last couple of Zope 2.9.x release, but my access to a 
| Windows build environment is gone now...

Odd. I believe Tim built 2.9.4 because you could not?

-- 
Sidnei da Silva
Enfold Systemshttp://enfoldsystems.com
Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Moving ZopeVersionControl to subversion?

2006-10-09 Thread Jens Vagelpohl

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 6 Oct 2006, at 18:55, Jens Vagelpohl wrote:


On 6 Oct 2006, at 17:38, Wichert Akkerman wrote:

I noticed that ZopeVersionControl is still actively maintained in  
CVS.

Would its maintainers mind moving it to subversion? That would make
it a lot easier for us to include it in the Plone 3.0 bundle.


I don't think it *has* a maintainer...

I think the sandbox for moving items from CVS to SVN that I built  
on cvs.zope.org for items like CMF and PAS still exists and I could  
do the physical move.


I'm afraid I spoke too soon. My sudo access has been removed. Jim  
tells me any task requiring root access must be performed by him (or  
other ZC staff I presume). I'm hereby un-volunteering myself from  
this task.


jens


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFFKnDiRAx5nvEhZLIRAvZ9AJ9sPCZFrIGr8MOxfNBLEtkjzd+1pgCfbqDl
O7aaWFvHT1o90GhvibrRXjg=
=Q86p
-END PGP SIGNATURE-
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Maintainer of Zope 2 Windows builds?

2006-10-09 Thread Tim Peters

[Andreas Jung]

Who is currently in charge or who feels responsible for the Windows
builds?


[Sidnei da Silva]

Tim Peters.


[Chris Withers]

Er, no. Tim isn't even at Zope Corp anymore, as far as I know...


[Sidnei]

That shouldn't be related, should it?


Don't know about should be, but it /is/ related ;-)  I had job-related
reasons before to make at least minimal ongoing efforts toward keeping the
Zope test suites happy on Windows, and that in turn meant I kept many full
checkouts of various Zopes current, at least ran the tests routinely, gave
real attention to discussions of possible Windows glitches, built Windows
installers routinely, and so on.

But I don't do anything related to web development anymore, and bit rot is
setting in wrt my once-encyclopedic knowledge of the umpteen quirky build
procedures for the umpteen versions of Windows Zope.  When, months ago,
someone else volunteered to take over the Zope3 Windows builds, and actually
followed up on it (yay!), I mentally resigned from these tasks.

You (ZC, ZF, the community) want someone who /uses/ Zope on Windows to make
Windows releases.  It was at best half nuts that I kept doing it after
building  testing an installer once each N weeks became my only contact
with Zope.


I built the last couple of Zope 2.9.x release, but my access to a
Windows build environment is gone now...



Odd. I believe Tim built 2.9.4 because you could not?


I don't remember, but it's possible.  I'm still willing to build an
installer when there's no alternative, but it's long past time that was
treated as a last-ditch fallback instead of business as usual.
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope )


RE: [Zope-dev] Maintainer of Zope 2 Windows builds?

2006-10-09 Thread Andreas Jung



--On 9. Oktober 2006 12:19:22 -0400 Tim Peters [EMAIL PROTECTED] wrote:


Don't know about should be, but it /is/ related ;-)  I had job-related
reasons before to make at least minimal ongoing efforts toward keeping the
Zope test suites happy on Windows, and that in turn meant I kept many full
checkouts of various Zopes current, at least ran the tests routinely, gave
real attention to discussions of possible Windows glitches, built Windows
installers routinely, and so on.

But I don't do anything related to web development anymore, and bit rot
is setting in wrt my once-encyclopedic knowledge of the umpteen quirky
build procedures for the umpteen versions of Windows Zope.  When, months
ago, someone else volunteered to take over the Zope3 Windows builds, and
actually followed up on it (yay!), I mentally resigned from these tasks.

You (ZC, ZF, the community) want someone who /uses/ Zope on Windows to
make Windows releases.  It was at best half nuts that I kept doing it
after building  testing an installer once each N weeks became my only
contact with Zope.


Thanks for your work on the windows builds in the past. We appreciate
your work very much.





I built the last couple of Zope 2.9.x release, but my access to a
Windows build environment is gone now...



Odd. I believe Tim built 2.9.4 because you could not?


I don't remember, but it's possible.  I'm still willing to build an
installer when there's no alternative, but it's long past time that was
treated as a last-ditch fallback instead of business as usual.


I'd like to see someone taking over the responsibility for the Windows
builds for the mid-term future. We have enough smart Windows users that 
could step in.


Thanks in advance,
Andreas


pgpqEsVoDY0ju.pgp
Description: PGP signature
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Maintainer of Zope 2 Windows builds?

2006-10-09 Thread Sidnei da Silva
On Mon, Oct 09, 2006 at 12:19:22PM -0400, Tim Peters wrote:
| You (ZC, ZF, the community) want someone who /uses/ Zope on Windows to make
| Windows releases.  It was at best half nuts that I kept doing it after
| building  testing an installer once each N weeks became my only contact
| with Zope.

I'm using Zope on Windows on a daily basis now. So that might mean me. :)

I would like to propose setting up some sort of 'nightly build' using
the buildbot already in place. We can setup it so that you don't need
to change the buildbot config to point it to another release. Then
whenever a release tarball is done, we poke the buildbot and an
installer will show up. If the installer breaks we get some visibility
at least.

I'm already running a slave for pybots which has all the needed tools
in place. It wouldn't require much effort to add a Zope Installer
build to that.

-- 
Sidnei da Silva
Enfold Systemshttp://enfoldsystems.com
Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Re: Future of ZClasses

2006-10-09 Thread Dieter Maurer
Philipp von Weitershausen wrote at 2006-10-7 23:51 +0200:
 ...
 I find that the introduction of classes with (multiple) inheritance
 has been very economic. It was another concept but a highly fruitful
 one, despite the fact that they are not so liked in Zope3 land.

I think fat objects from mixing many different concerns into a single 
implementation are a failed approach.

Seeing how flexible you can be wit

   a) separating concerns (functionality, responsibilities) into 
separate objects called components and

   b) making the lookup of these components pluggable (using registries 
a.k.a. the Component Architecture),

I am almost convinced that in some years these registries
will share the fate of acquisition: they will be seens as too much
magic.

I expect this to happen as soon as Zope3 is becoming main stream
and not only used by the fittest people.

I would not recommend anyone to over-use multiple inheritance as it's 
been done in Zope 2.

I am a strong favorite of (multiple) inheritance and use it excessively.
I have the feeling that it makes me very productive.



-- 
Dieter
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: Future of ZClasses

2006-10-09 Thread Andreas Jung



--On 9. Oktober 2006 19:11:55 +0200 Dieter Maurer [EMAIL PROTECTED] 
wrote:



I would not recommend anyone to over-use multiple inheritance as it's
been done in Zope 2.


I am a strong favorite of (multiple) inheritance and use it excessively.
I have the feeling that it makes me very productive.


We have some code where some classes have up to 15(!) base classes (usually 
mixin classes), not counting classes inherited from the mix-in classes. I 
would call that unmanageable. Personal productivity is one side of the 
medal, readability and understandability of code for other team member is 
the other side of the medal. Although I am not the biggest fan of the 
component architecture I have to admit that it makes a lot of things 
clearer and cleaner.


-aj  

pgpyPNxGod5GG.pgp
Description: PGP signature
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Fat vs Greasy (Was: [Zope-dev] Re: Future of ZClasses)

2006-10-09 Thread Lennart Regebro

On 10/9/06, Dieter Maurer [EMAIL PROTECTED] wrote:

Philipp von Weitershausen wrote at 2006-10-7 23:51 +0200:
 ...
 I find that the introduction of classes with (multiple) inheritance
 has been very economic. It was another concept but a highly fruitful
 one, despite the fact that they are not so liked in Zope3 land.

I think fat objects from mixing many different concerns into a single
implementation are a failed approach.

Seeing how flexible you can be wit

   a) separating concerns (functionality, responsibilities) into
separate objects called components and

   b) making the lookup of these components pluggable (using registries
a.k.a. the Component Architecture),

I am almost convinced that in some years these registries
will share the fate of acquisition: they will be seens as too much
magic.

I expect this to happen as soon as Zope3 is becoming main stream
and not only used by the fittest people.

I would not recommend anyone to over-use multiple inheritance as it's
been done in Zope 2.

I am a strong favorite of (multiple) inheritance and use it excessively.
I have the feeling that it makes me very productive.


There is of course no conflict between the two attitudes. It may
*look* like there is, though. ;)

In one case, you make loads of small objects with separate concerns,
and merge them into one object by multiple-inheritance. In the other
case you make loads of small objects with separate concerns and merge
them via adapters. The first version is less flexible, as changing the
behaviour of the resulting fat objects requires subclassing, while
the other attitude can be hard to overview and grasp (and hence, I'll
call it greasy. Haha.)

I think one generally should, in Zope3/Five, use objects as if they
always need to be adapted. That is, you get the context, and you adapt
it to whatever interface you need, with IMyinterface(context). Then,
of course, you may very well make your object a fat object that
implement all the bloody interfaces you need, instead of having
multiple sets of objects and adapters, which in most cases just make
things complicated.

But with this attitde, that is make fat objects, but never assume they
are fat when you use them, you can with little effort make something
flexible.


For example: The CalZope calendar attaches all views directly to the
ICalendar interface. Only ICalendar objects can have these views. A
calendar object in CPS is therefore a calendar that directly
implements ICalendar, and some other extended interfaces with CPS
support and stuff. This seems perfectly reaonable, but it turns out
Plone people don't want that. They want ordinary folder to have these
views. The solution to that is to attach all the views to
ICalendarViewable and in all views make self.context =
ICalendar(context), and this way adapt the context.

By making my fat calendar objects IcalendarViewable, I need not to
change any other code in CPSSharedCalendar or CalZope. I still have
the same monolithic objects, that are easy to understand and debug.

But for Plone, it would with these changes be perfectly possible to
make adapters from Plone folders to ICalendar, and therefore use
CalZope views for folders full of plone events.

So, as long as you *use* the objects as if they always need to be
adapted, you can very well write the objects monolithically if that
suits you.  So, heres a new tagline:

Use your objects as if they were greasy, and it isn't a problem if
they are fat.

;-)

--
Lennart Regebro, Nuxeo http://www.nuxeo.com/
CPS Content Management http://www.nuxeo.org/
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Re: Future of ZClasses

2006-10-09 Thread Philipp von Weitershausen

Dieter Maurer wrote:

Philipp von Weitershausen wrote at 2006-10-7 23:51 +0200:

...

I find that the introduction of classes with (multiple) inheritance
has been very economic. It was another concept but a highly fruitful
one, despite the fact that they are not so liked in Zope3 land.
I think fat objects from mixing many different concerns into a single 
implementation are a failed approach.


Seeing how flexible you can be wit

  a) separating concerns (functionality, responsibilities) into 
separate objects called components and


  b) making the lookup of these components pluggable (using registries 
a.k.a. the Component Architecture),


I am almost convinced that in some years these registries
will share the fate of acquisition: they will be seens as too much
magic.


Perhaps. That's to be seen.

For one, the CA's registries are much less magic because look-up is 
always explicit (as opposed to the implicit acquisition as its widely 
used in Zope 2).



I expect this to happen as soon as Zope3 is becoming main stream
and not only used by the fittest people.


This is indeed a good point. There are currently efforts to make Zope 3 
easier for simpler use cases that wouldn't involve dealing with those 
registries, at least not directly. In fact, we're having a sprint on 
this topic this month.


I would not recommend anyone to over-use multiple inheritance as it's 
been done in Zope 2.


I am a strong favorite of (multiple) inheritance and use it excessively.
I have the feeling that it makes me very productive.


That's good. Again, I think multiple inheritance is a valid tool. One 
reason why I would advise against using is excessively, though, is the 
lack of pluggability. The way Zope 2 deals with APIs, for example, makes 
hard to reuse and customize existing components. Sure, you CAN try to 
reuse stuff (and I know some of your tools, e.g. rebindFunction et.al. 
from ReuseUtils), but most of these revolve more around implementation 
details than around well-defined APIs and responsibilities.

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: Future of ZClasses

2006-10-09 Thread Dieter Maurer
Andreas Jung wrote at 2006-10-9 19:24 +0200:
 ...
We have some code where some classes have up to 15(!) base classes (usually 
mixin classes), not counting classes inherited from the mix-in classes. I 
would call that unmanageable.

Each of these classes represent a mixed in feature.
You get 15 classes because the end result needs a lot of features.

Manageability does not increase when you implement the features
differently than listing them in the inheritance clause.



-- 
Dieter
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Re: Future of ZClasses

2006-10-09 Thread Dieter Maurer
Philipp von Weitershausen wrote at 2006-10-9 19:59 +0200:
 ...
Sure, you CAN try to 
reuse stuff (and I know some of your tools, e.g. rebindFunction et.al. 
from ReuseUtils), but most of these revolve more around implementation 
details than around well-defined APIs and responsibilities.

This must mean most of those you know of and not most of my tools :-)


-- 
Dieter
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: Fat vs Greasy (Was: [Zope-dev] Re: Future of ZClasses)

2006-10-09 Thread Lennart Regebro

On 10/9/06, Jean-Marc Orliaguet [EMAIL PROTECTED] wrote:

That's basically what I wrote the other day (The Times... ) : as an
application designer you want a *plugin architecture* with greasy fat
components, not an architecture with hundreds of micro-components wired
together like this:
http://jacobswellchurch.org/tim/archives/wires-bottom.jpg that require
that learn the internals.

Also, plugin logic is not the same as micro-component logic:

- plugins are single units that only need a runtime platform to get
working, while micro-components need to get assembled before they can be
used, the border between the platform and the platform's components is
very blurry.

- plugins have a public API that preserves backward compatibility, and
hence preserves user's investments, while micro-components neither have
a public or private API, they implement interfaces (interface != API)

- plugins can get loaded and unloaded at runtime, or updated, while
micro-components are basically added once at server startup time and
they never get changed at run-time.

- a plugin architecture can manage dependencies between plugins.

- plugins are useful to market an architecture, (cf. Photoshop gimp,
Gimp plugins, VDR plugins (http://www.cadsoft.de/vdr/plugins.htm),
Firefox plugins, skins, Azureus plugins, Eclipse plugins ...). It is
easy to explain what a plugin does in terms of functionality, while it
is difficult to explain what a micro-component does.

//- plugins encourage participation!!! (that's one of the reason of the
success of Plone IMO: every one feel that they can create their own
product, by looking at other existing products), while micro-components
are difficult to grasp.

- plugins can be used by end-users, while micro-components are designed
by developers for developers.


That's not at all what I said. ;)
But you have valid points and I basically agree with your separations
of micro-components and plugins.

--
Lennart Regebro, Nuxeo http://www.nuxeo.com/
CPS Content Management http://www.nuxeo.org/
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope )