[Zope-dev] How should an ideal Zope IDE look like?

2004-04-23 Thread Martin Kretschmar
Hello,

it looks as if some people are missing a nice Zope IDE.

So I would like to have your oppinions on what an ideal
Zope IDE should look like and what technologies it should
be built on.

Regards,
 Martin


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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] The bleak Future of Zope?

2004-04-23 Thread Lennart Regebro
From: Dieter Maurer [EMAIL PROTECTED]
 I do not believe you.

But I believe him. :-)

If Zope has a steep lurning curve, that's nothing compared with CMF.  There
are many good things with CMF, the actions are a good idea, DCWorkflow of
course, and some more. But

portal_skins are a fundamentally flawed idea and has the tendency to move
logic out from the products into the skins, instead of facilitating a
separation between logic and design. Other evidence that the thinking is
wrong is that skins are stored on disk, but through some clever predenting
on Zopes part they look like they are in the ZODB. This shows that somebody
has been thinking backwards. :-)

The skins that come with CMF are incomprehensible, and stopped me from using
CMF before I was forced to (something which is solved by using Plone or CPS,
but that's not obvious first of all, and secondly, none of them were
available when I started looking at CMF).

And the member management is a complete mess with gazillion tools involved.
:-)


A lot of the things that are CMF should have been put into Zope core.
DCWorkflow should have been there. acl_user folder should have been extended
with property management and other member management instead of shimming
tools and wrapping user objects as is done now. And even if portal_skins
would have been included, they should have been empty of skins, instead of
sending with a bunch of skins that makes CMF look like it almost is a
finished product, when in fact, it just a bunch of handy tools.

But ah well, what is done is done. Too late to change the past now. :-0


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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: When should one call Connection.sync?

2004-04-23 Thread Syver Enstad
Dieter Maurer [EMAIL PROTECTED] writes:

 Syver Enstad wrote at 2004-4-21 18:03 +0200:
 I have done some experiments with this scheme and I find that
 everything gets unloaded when do a connection.close() or
 connection.sync() so that performance takes quite a hit.
 
 Maybe, the connection cache is too small.
 
 Usually, an incremental cache garbage collection is performed
 in connection.close() and at transaction boundaries
 (sync causes an implicit transaction.abort() which means,
 it marks a transaction boundary). The cache garbage collection
 tries to flush as many objects from the cache as are necessary
 to reach the target cache size.

Yes that was the problem, I found out about this after some
experiments and by upping the cache_size to at least 20 000 I manage
to keep the instances in memory even when I do a sync or close.

Thank you anyway.




___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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] The bleak Future of Zope?

2004-04-23 Thread Jamie Heilman
Lennart Regebro wrote:
 From: Dieter Maurer [EMAIL PROTECTED]
  I do not believe you.
 
 But I believe him. :-)

Adding more framework code to a project as large as Zope already is,
is adding complexity.  It might help you get your project done faster,
because the new tools are better suited to the job, but it doesn't
simplify what a developer needs to know in the long run.  There's
nothing quite as telling as looking at the full set of methods
available on a 3rd or 4th generation object.  By the time you've
crawled your way down the paths of all the inherited classes, you can
usually uncover some fairly severe inconsistencies.  The permissions
associated with those methods are usually laughable by that point.
Mashing 3 different permissions onto the same object meta data via 7
differen't APIs is complete HELL for people who want to program with
any degree of security/privacy, and thats exactly what happens in a
lot of these large add-on frameworks.


-- 
Jamie Heilman http://audible.transient.net/~jamie/

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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] [Q] Pickle support for C wrapper and ZEO

2004-04-23 Thread Ames Andreas (MPA/DF)
Hello Dieter,

thanks for your answer.


Dieter Maurer [EMAIL PROTECTED] writes:

 You mean ZEO client instances not ZEO (server) instances, don't you?

Exactly, sorry for having been ambiguous.


 Why do you think your ODBC objects should be consistent across
 ZEO clients?
 I do not think that it is necessary as all your requests your
 be independent which means all transactions inside a single
 request which implied that connections need not to be shared.

The reason why I think about this ZEO scenario is that I thought it
was a goal for a ZEO deployment that all ZEO clients behave identical
when they respond to the same request.  That requires some sort of
shared state, which is what ZODB is used for in ZEO, AFAIK.

Furthermore such shared state is only useful when the state persist
across requests.  So I guess my real question should have been:

Is it useful/sensible to keep state across request-boundaries within a
database adapter in Zope (such state as ODBC-environment,
ODBC-connections, ODBC-statements and ODBC-descriptors)?

If you don't know ODBC well enough:  How do you do it in comparable
remote access adapters (for example a CORBA client in Zope or
something)?


TIA,

andreas


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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: Zope3, CMS, IDEs

2004-04-23 Thread Seb Bacon
Joachim Werner wrote:
I've proposed that a couple of times already. There are two problems in real 
life: 
 
1) Somebody has to take care of managing the project. 

2) If politics take over, things will quickly fall apart.
I agree.  I hope that Heimo  Paul's session at EP will help work 
through some solutions to these points.

I disagree that performance is a problem in Zope 2. 

I've heard that a couple of times. But let's face it: Of course you can get 
Zope to deliver partly dynamic pages at high speed and if you use caching you 
can deliver pages at wire speed, but it will not be nearly as fast as a 
solution using Java or .NET/C# if we are talking about a lot of two-way 
traffic and CPU-intensive tasks in the back end, e.g. an online shopping mall, 
a booking system, or a groupware.
Well, the site I am talking about is a real-world, huge-traffic, highly 
dynamic, personalised shopping site and multiple bookings system which 
gets millions of visits a day.  It performs very well under extreme load 
in test conditions, *even when you take squid out*: better than the 
previous Java solution.

I would take this as a pretty good indication that performance need not 
be an issue when evaluating Zope.  Let's face it: there are plenty of 
badly-performing Java sites out there ;-)

I do agree that it is hard to find best practice information about this 
subject, though.  I am planning to do a talk about it at Europython.  If 
Chris M doesn't mind, I'll be using some of his material, and 
elaborating on it:

  http://www.plope.org/misc/szweb

The reason the Zope site I'm talking about performs better, IMO, is 
nothing to do with the language, but to do with (a) the better 
application design and (b) the ease of scaling horizontally with ZEO.

seb

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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] The bleak Future of Zope?

2004-04-23 Thread Sidnei da Silva
On Fri, Apr 23, 2004 at 10:57:18AM +0200, Lennart Regebro wrote:
| A lot of the things that are CMF should have been put into Zope core.
| DCWorkflow should have been there. acl_user folder should have been extended
| with property management and other member management instead of shimming
| tools and wrapping user objects as is done now. And even if portal_skins
| would have been included, they should have been empty of skins, instead of
| sending with a bunch of skins that makes CMF look like it almost is a
| finished product, when in fact, it just a bunch of handy tools.

Add to that some fancy xml-based configuration named zcml and a nice
architecture and bingo, you have zope3 ;)

-- 
Sidnei da Silva [EMAIL PROTECTED]
http://awkly.org - dreamcatching :: making your dreams come true
http://plone.org/about/team#dreamcatcher

FORTRAN is for pipe stress freaks and crystallography weenies.

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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: Zope Book development moved

2004-04-23 Thread Brian Lloyd
 I've come to the unfortunate conclusion that Zope.org is just not going
 to cut it to do Zope Book development work due to its speed (or lack
 thereof).
 
 I'd like to help fix the Zope.org slowness problem, but I'm a little
 unclear about what's required for me to get the level of access required
 to do so.  I read the stuff at Zope.org/About and Zope.com/Legal but
 it's a little hard to divine out of the combination what I need to do
 before I can be allowed to help.  So of the Zope.org Application Server
 Working Group/Zope Application Working Group/Whoever wants help trying
 to fix it, you know where to find me!  Just don't make me attend a 7am
 committee meeting or sign a noncompete instrument wink.

BTW, once Shane is safely settled out west we plan to engage him 
to fix a number of the ills of zope.org, so I expect we'll see a 
marked improvement in the near future.

As to zope.org/About, it is confusing right now because the actual 
docs aren't yet posted. Michael is working as we speak to get the 
click-wrap alluded to in /About up and running and a place to 
organize these docs, have a place for working groups, expand the FAQ, 
etc.


Brian Lloyd[EMAIL PROTECTED]
V.P. Engineering   540.361.1716  
Zope Corporation   http://www.zope.com 



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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: Zope Book development moved

2004-04-23 Thread Chris McDonough
On Fri, 2004-04-23 at 13:21, Brian Lloyd wrote:
 BTW, once Shane is safely settled out west we plan to engage him 
 to fix a number of the ills of zope.org, so I expect we'll see a 
 marked improvement in the near future.

OK, in the meantime if we wanted to organize a (one-day) Zope.org
sprint I would attend.

 As to zope.org/About, it is confusing right now because the actual 
 docs aren't yet posted. Michael is working as we speak to get the 
 click-wrap alluded to in /About up and running and a place to 
 organize these docs, have a place for working groups, expand the FAQ, 
 etc.

I'm not sure whether helping is blocked on any of this stuff, but if
it's not, I'm willing to do whatever is necessary as time allows.

- C



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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] New mailing list for ZConfig users

2004-04-23 Thread Fred Drake
At a suggestion from the community, I've created a new mailing list for 
ZConfig users.  This is for general discussion and questions.  The list is 
run using Mailman at Zope.org; you can sign up at

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


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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] [Q] Pickle support for C wrapper and ZEO

2004-04-23 Thread Dieter Maurer
Ames Andreas (MPA/DF) wrote at 2004-4-23 13:13 +0200:
 ...
Dieter Maurer [EMAIL PROTECTED] writes:

 You mean ZEO client instances not ZEO (server) instances, don't you?

Exactly, sorry for having been ambiguous.


 Why do you think your ODBC objects should be consistent across
 ZEO clients?
 I do not think that it is necessary as all your requests your
 be independent which means all transactions inside a single
 request which implied that connections need not to be shared.

The reason why I think about this ZEO scenario is that I thought it
was a goal for a ZEO deployment that all ZEO clients behave identical
when they respond to the same request.  That requires some sort of
shared state, which is what ZODB is used for in ZEO, AFAIK.

You really must read my messages very carefully:

  Try to make requests self contained (Zope usually helps you with this),
  then you do not need shared state between requests
  and therefore, the state need not be shared across ZEO clients.

ZEO does not use the ZODB to implement shared state.
Instead, ZEO is used to allow multiple ZEO clients to access the
same storage concurrently (a storage can only be accessed by a single
process at a time -- you need an intermediate process (ZEO) when
several processes need to access it concurrently).

Furthermore such shared state is only useful when the state persist
across requests.  So I guess my real question should have been:

Is it useful/sensible to keep state across request-boundaries within a
database adapter in Zope

It may be for efficiency reasons (for resources that are expensive
to set up).

(such state as ODBC-environment,
ODBC-connections, ODBC-statements and ODBC-descriptors)?

If you don't know ODBC well enough:  How do you do it in comparable
remote access adapters (for example a CORBA client in Zope or
something)?

I already suggested in the previous message that you look at
a database adapter (why not mxODBC) to see how they handle this
issue...
It is also essential to read my messages completely ;-)

-- 
Dieter

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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] The bleak Future of Zope?

2004-04-23 Thread Dieter Maurer
Lennart Regebro wrote at 2004-4-23 10:57 +0200:
From: Dieter Maurer [EMAIL PROTECTED]
 I do not believe you.

But I believe him. :-)

If Zope has a steep lurning curve, that's nothing compared with CMF.

Usually, I am able to explain CMF to my colleagues in something
like a few hours (I do this occasionally for different teams).

 ...
portal_skins are a fundamentally flawed idea and has the tendency to move
logic out from the products into the skins, instead of facilitating a
separation between logic and design.

It is one of our favorite tools...

It provides a flexible way to contruct a namespace (badly termed skin) from
components (layers). This is very useful, whenever
you need several namespaces which large common parts but various
small differences. We use it to describe hierarchies similar
to an inheritance hierarchy:

   Infrastructure/
   ShopPortals/ # overrides (or adds) things special for ShopPortals
   ShopPortal1  # overrides (or adds) things special for ShopPortal1
 ...
   ProductPortal/
   ...
 
It makes it very easy to add new portal grous or new individual
portals.


We will soon use it as a main component for a production environment
to produce many related products (they are described by
a similar hierarchical structure).


Logic, too, can make use of the flexibility provided by the SkinsTool
The production system mentioned above will use the SkinsTool
for logic only.


Other evidence that the thinking is
wrong is that skins are stored on disk, but through some clever predenting
on Zopes part they look like they are in the ZODB. This shows that somebody
has been thinking backwards. :-)

You look at this in a funny way -- in the sense that I see it
totally different.

  That Zope can use the objects in the file system, they must
  be mapped to Python objects. As the mapping is non-trivial,
  it is very helpful that you can check the result via
  the ZMI.
  
  What the DirectoryView does here, is similar to what LocalFS
  does -- and it is very senseful...

The skins that come with CMF are incomprehensible, and stopped me from using
CMF before I was forced to (something which is solved by using Plone or CPS,
but that's not obvious first of all, and secondly, none of them were
available when I started looking at CMF).

Here, you blur the distinction between CMFCore and CMFDefault.
CMFDefault is nothing more than an example for CMFCore
(in my view).

While we use CMFCore very successfully and very profitably,
we do not use CMFDefault at all (other than as some example code).

And the member management is a complete mess with gazillion tools involved.
:-)

This provides for a great deal of modularity...


A lot of the things that are CMF should have been put into Zope core.

We consider CMFCore (and DCWorkflow) as part of the Zope core.
Nothing prevents you to do the same...

 ...
acl_user folder should have been extended
with property management and other member management instead of shimming
tools and wrapping user objects as is done now.

When CMF was designed there were already several dozens of
UserFolders around. It is not too bad an idea to use existing
components and wrap them with new functionality...

And even if portal_skins
would have been included, they should have been empty of skins, instead of
sending with a bunch of skins that makes CMF look like it almost is a
finished product, when in fact, it just a bunch of handy tools.

Disregard CMFDefault (when you like) and just use CMFCore
as a bunch of handy tools. In fact, this was the main purpose.
Again: CMFDefault was considered as an example how to use
the framework CMFCore.

But ah well, what is done is done. Too late to change the past now. :-0

There is no need to change the past.
You can start using CMFCore profitable in the future :-)


-- 
Dieter

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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: zLOG changes

2004-04-23 Thread Dieter Maurer
Fred Drake wrote at 2004-4-22 17:15 -0400:
I wrote:
  - In debug mode, add a new handler that dumps to standard output.  This
  is fairly easy to code, but is inflexible.

Andreas responded:
  But flexible enough for most usecase. The point is that you want to see
  the tracebacks on the console during the development phase. Watching the
  event.log with tail -f is somewhat annoying.

Understood!  I've committed changes that that I think should do the trick for 
you.

- In debug mode, a log handler is added to the root logger that writes events
  to standard error.  This is no longer conflated with the startup logging.

Hopefully, you do this not automatically?

While one *sometimes* wants messages on the console, *often* one does
not.

This means, it should be a configuration option.

- When running Zope using zopectl fg (the best way to run things for
  debugging), zopectl will force debug mode to be enabled.

I do not think this coupling is good.
You might have problems in production mode that you do not
have in development mode.

   - In debug mode, use an alternate or auxillary logging configuration to
 replace or augment the eventlog configuration section.  This is more
   work   up front, but keeps everything flexible.

I like this much more...

-- 
Dieter

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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] How should an ideal Zope IDE look like?

2004-04-23 Thread Andre Meyer
So, I give it a try and submit a wish list for an ideal IDE for 
Python/Zope.

Maybe some words about the IDEs I have been working with, so you can 
track where the features I wish to have come from: I used CodeWarrior, 
NetBeans, jEdit for both Java and Python/Zope, Boa Constructor and 
Eclipse with several plugins (like Omondo UML plugin, TruStudio and PyDev).

And here comes the list of features:

- Syntax coloring (standard everywhere) for python and zpt/xml/html/css 
code.

- Commenting/uncommenting code (any hope Python will ever offer 
multi-line comments?).

- Auto-completion for python and zpt/xml/html/css, incl. parameter 
editing. One should be able to specify the path to modules: for example 
I have a Python installation and a Zope installation with Python 
offering different modules.

- Show declaration: jump to definition of classes/instances elsewhere in 
the code using a context menu.

- Refactoring: actions, such as renaming a class, method or module and 
modify all references in the rest of the code; move classes and methods 
up or down in the class hierarchy. Eclipse supports this for Java and it 
saves a LOT of time,

- Unit tests with reporting.

- Folding: show/hide parts of the source code (like in jEdit).

- Split windows.

- Project management.

- CVS/Subversion integration.

- Search/replace, incl. regex in open files, project,

- Compare and edit files/folders (diff, meld).

- Dragdrop editing.

- Multi-threaded debugging.

- Outline: display classes, methods, attributes of a source file.

- Class/method popup.

- Bookmarks.

- Class browser: multi-part window for browsing and editing classes and 
their methods and attributes. Similar to the NeXTstep file browser and 
the Java Browser perspective in Eclipse.

- UML editor (incl. code generation and reverse engineering). Eclipse 
has several UML plugins and offers a language-independent modelling 
framework (EMF) that supports code generation. This could be adapted for 
Python.

- Design patterns, templates: not found anywhere, yet, but might be an 
interesting feature, especially for Zope development, where we have a 
lot of recipes that need to be applied often.

- Pydoc integration: show the docs simultaneously with the code.

- ZPT debugging, sensible error messages.

- ZODB inspection: give insight into what is actually stored in the ZODB.

- Ftp, WebDav

- Launching/restarting Zope locally and remotely.

- Python and Jython support.

- Live error tracking (while typing).

- Task management.

- Calling trees: who calls whom and who is called by whom?

Well, there is certainly more, but this is a start... ;-)

One could start from Eclipse/PyDev (http://pydev.sourceforge.net/) and 
add features. Does anybody (Martin) have concrete plans to do this?

Also look at 
http://www.python.org/cgi-bin/moinmoin/EclipsePythonIntegration 5 for 
more ideas.

kind regards and success
Andre
Martin Kretschmar wrote:

Hello,

it looks as if some people are missing a nice Zope IDE.

So I would like to have your oppinions on what an ideal
Zope IDE should look like and what technologies it should
be built on.
Regards,
Martin
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )

 

--
Dr. Andre P. Meyerhttp://home.hccnet.nl/a.meyer/
TNO FEL Command  Control and Simulation, http://www.fel.tno.nl/div2/
Delft Cooperation on Intelligent Systems, http://www.decis.nl/
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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] How should an ideal Zope IDE look like?

2004-04-23 Thread Aleks Totic
Nice wishlist. About 3-4 man years worth of coding, 2 min is my 
guess.

My goal is not quite so ambitious. I wanted to learn Eclipse 
well. I was always jelaous of Emacs guys that could whip up a 
mode for their favorite lanuguage. Implementing a Python IDE 
sounded like a good starter project. By IDE, I mean something 
with a debugger.

In the next release (by the end of next month) I'll have some 
hyperlinking (function/classdefs withing the same file, and on 
imports), maybe some code completion (that's up to Dana), and a 
decent debugger (multithreaded).

After that, I am not sure. My goal for pydev is for it to be good 
enough for small-size projects, and we'll almost be there. The 
larger projects requirements (unit tests/UML editor/module 
awareness) are not that exciting as a hobby.

Aleks

Andre Meyer wrote:

So, I give it a try and submit a wish list for an ideal IDE for 
Python/Zope.

Maybe some words about the IDEs I have been working with, so you can 
track where the features I wish to have come from: I used CodeWarrior, 
NetBeans, jEdit for both Java and Python/Zope, Boa Constructor and 
Eclipse with several plugins (like Omondo UML plugin, TruStudio and PyDev).

And here comes the list of features:

- Syntax coloring (standard everywhere) for python and zpt/xml/html/css 
code.

- Commenting/uncommenting code (any hope Python will ever offer 
multi-line comments?).

- Auto-completion for python and zpt/xml/html/css, incl. parameter 
editing. One should be able to specify the path to modules: for example 
I have a Python installation and a Zope installation with Python 
offering different modules.

- Show declaration: jump to definition of classes/instances elsewhere in 
the code using a context menu.

- Refactoring: actions, such as renaming a class, method or module and 
modify all references in the rest of the code; move classes and methods 
up or down in the class hierarchy. Eclipse supports this for Java and it 
saves a LOT of time,

- Unit tests with reporting.

- Folding: show/hide parts of the source code (like in jEdit).

- Split windows.

- Project management.

- CVS/Subversion integration.

- Search/replace, incl. regex in open files, project,

- Compare and edit files/folders (diff, meld).

- Dragdrop editing.

- Multi-threaded debugging.

- Outline: display classes, methods, attributes of a source file.

- Class/method popup.

- Bookmarks.

- Class browser: multi-part window for browsing and editing classes and 
their methods and attributes. Similar to the NeXTstep file browser and 
the Java Browser perspective in Eclipse.

- UML editor (incl. code generation and reverse engineering). Eclipse 
has several UML plugins and offers a language-independent modelling 
framework (EMF) that supports code generation. This could be adapted for 
Python.

- Design patterns, templates: not found anywhere, yet, but might be an 
interesting feature, especially for Zope development, where we have a 
lot of recipes that need to be applied often.

- Pydoc integration: show the docs simultaneously with the code.

- ZPT debugging, sensible error messages.

- ZODB inspection: give insight into what is actually stored in the ZODB.

- Ftp, WebDav

- Launching/restarting Zope locally and remotely.

- Python and Jython support.

- Live error tracking (while typing).

- Task management.

- Calling trees: who calls whom and who is called by whom?

Well, there is certainly more, but this is a start... ;-)

One could start from Eclipse/PyDev (http://pydev.sourceforge.net/) and 
add features. Does anybody (Martin) have concrete plans to do this?

Also look at 
http://www.python.org/cgi-bin/moinmoin/EclipsePythonIntegration 5 for 
more ideas.

kind regards and success
Andre


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )