Are any of these significant detriments with Zope addressed in 2.7 or later? 0. No standard DB support. I don't think ZPoPyDa has been updated since 2001. I'm sure that fills new developers with lots of confidence. Perhaps it works fine, but it's not being improved. Perhaps other DB interfaces are better. But then again ZSQL Methods are still ancient and in DTML. 1. Build in user management. This is stupid. The user management is good for companies of 10 people or so but what good is that to web application or ecomm site? You going to hand add users? The only solid product for this is LDAPUserFolder, the rest should still be in beta. 2. Debugging. This is worse. It is so complicated to debug Products or Zope crap I can't believe it. This is relative to PHP or JSP or ASP; all I have worked with. 3. Python Keeping python up to date to use products. Pain in the ass. 4. DTML/ZPT Seems 90% of Products are in DTML yet ZPT seems like the obvious thing to use. Fine, except when you need to tweak a product and then have to learn DTML. PHP is PHP same for the most part with ASP (all VB if you like) or JSP (all java if you like). Honestly. If I new know what I do about zope I would not recommend it for commercial development. Go with a product that lots of people are using, this way you are ensured that components will be well supported and improved over time. Not dropped because the author has moved on.
--On Mittwoch, 13. Oktober 2004 9:15 Uhr -0700 Jason Leach <jason.leach@gmail.com> wrote:
Are any of these significant detriments with Zope addressed in 2.7 or later?
0. No standard DB support. I don't think ZPoPyDa has been updated since 2001. I'm sure that fills new developers with lots of confidence. Perhaps it works fine, but it's not being improved. Perhaps other DB interfaces are better. But then again ZSQL Methods are still ancient and in DTML.
There are enough DB adapters available for nearly every DB available. DAs are not shipped with the Zope core. If you need a particular DA you can easily download and install it. What is your problem with ZSQL methods? They are known to work fine (as instance in the ZODb or on the filesystem). Do you know a better framework for specifying SQl queries in a generic way?
1. Build in user management. This is stupid. The user management is good for companies of 10 people or so but what good is that to web application or ecomm site? You going to hand add users? The only solid product for this is LDAPUserFolder, the rest should still be in beta.
Zope is a framework and application and not an out-of-the-box application. Look at the user management as it is written in Plone *on top* of Zope.
2. Debugging. This is worse. It is so complicated to debug Products or Zope crap I can't believe it. This is relative to PHP or JSP or ASP; all I have worked with.
Debugging PHP, JSP or ASP can be a pain in the ass as well.
3. Python Keeping python up to date to use products. Pain in the ass.
What do you want to tell us with this unqualified sentence?
4. DTML/ZPT Seems 90% of Products are in DTML yet ZPT seems like the obvious thing to use. Fine, except when you need to tweak a product and then have to learn DTML. PHP is PHP same for the most part with ASP (all VB if you like) or JSP (all java if you like).
You don't know what you are talking about. ZPT is used over DTMl over the last years. Most projects are using ZPT nowadays. DTML is still there for backward compatibility and because you can before tasks that can not be done in ZPT. But using ZPT is recommended way. If you are happy with PHP then use PHP. No one forces you to use Zope. If Zope overstrains your brain then use PHP. PHP is a framework that mixes logic and presentation. Zope is a framework that provides a larger functionality than PHP does.
Honestly. If I new know what I do about zope I would not recommend it for commercial development. Go with a product that lots of people are using, this way you are ensured that components will be well supported and improved over time. Not dropped because the author has moved on.
That's your personal opinion. There are *enough* examples of companies running Zope in company-critical environments. Not knowing what 'POS' means (assuming it is something rude) I recommend to take some drugs to relax before posting next time. Andreas
Andreas Jung wrote:
--On Mittwoch, 13. Oktober 2004 9:15 Uhr -0700 Jason Leach <jason.leach@gmail.com> wrote:
Are any of these significant detriments with Zope addressed in 2.7 or later?
0. No standard DB support. I don't think ZPoPyDa has been updated since 2001. I'm sure that fills new developers with lots of confidence. Perhaps it works fine, but it's not being improved. Perhaps other DB interfaces are better. But then again ZSQL Methods are still ancient and in DTML.
There are enough DB adapters available for nearly every DB available. DAs are not shipped with the Zope core. If you need a particular DA you can easily download and install it. What is your problem with ZSQL methods? They are known to work fine (as instance in the ZODb or on the filesystem). Do you know a better framework for specifying SQl queries in a generic way?
This is my opinion and only my opinion: I think Zope has a DB (object oriented one). For that, I think that DB connectors are for backward compatibility with your ancien software but I would like to migrate data
1. Build in user management. This is stupid. The user management is good for companies of 10 people or so but what good is that to web application or ecomm site? You going to hand add users? The only solid product for this is LDAPUserFolder, the rest should still be in beta.
Zope is a framework and application and not an out-of-the-box application. Look at the user management as it is written in Plone *on top* of Zope.
In these point ZMI could be better but Z3X is in beta 2?
2. Debugging. This is worse. It is so complicated to debug Products or Zope crap I can't believe it. This is relative to PHP or JSP or ASP; all I have worked with.
Debugging PHP, JSP or ASP can be a pain in the ass as well.
Absolutely agree with the 2 opinions but, Andreas, sorry but complacency is not very good. Zope needs moooore work here, but we are patience with open source, so, no problem
3. Python Keeping python up to date to use products. Pain in the ass.
What do you want to tell us with this unqualified sentence?
4. DTML/ZPT Seems 90% of Products are in DTML yet ZPT seems like the obvious thing to use. Fine, except when you need to tweak a product and then have to learn DTML. PHP is PHP same for the most part with ASP (all VB if you like) or JSP (all java if you like).
You don't know what you are talking about. ZPT is used over DTMl over the last years. Most projects are using ZPT nowadays. DTML is still there for backward compatibility and because you can before tasks that can not be done in ZPT. But using ZPT is recommended way. If you are happy with PHP then use PHP. No one forces you to use Zope. If Zope overstrains your brain then use PHP. PHP is a framework that mixes logic and presentation. Zope is a framework that provides a larger functionality than PHP does.
Honestly. If I new know what I do about zope I would not recommend it for commercial development. Go with a product that lots of people are using, this way you are ensured that components will be well supported and improved over time. Not dropped because the author has moved on.
That's your personal opinion. There are *enough* examples of companies running Zope in company-critical environments.
Not knowing what 'POS' means (assuming it is something rude) I recommend to take some drugs to relax before posting next time.
YESSS, drugs, lots of drugs, jejejeje ;)
Andreas _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
On Wednesday 13 October 2004 22:47, Garito wrote:
Andreas Jung wrote:
--On Mittwoch, 13. Oktober 2004 9:15 Uhr -0700 Jason Leach
<jason.leach@gmail.com> wrote:
0. No standard DB support. I don't think ZPoPyDa has been updated since 2001. I'm sure that fills new developers with lots of confidence. Perhaps it works fine, but it's not being improved. Perhaps other DB interfaces are better. But then again ZSQL Methods are still ancient and in DTML.
There are enough DB adapters available for nearly every DB available. DAs are not shipped with the Zope core. If you need a particular DA you can easily download and install it. What is your problem with ZSQL methods? They are known to work fine (as instance in the ZODb or on the filesystem). Do you know a better framework for specifying SQl queries in a generic way?
This is my opinion and only my opinion: I think Zope has a DB (object oriented one). For that, I think that DB connectors are for backward compatibility with your ancien software but I would like to migrate data
I'm no specialist, but I think that's not true: An object oriented database is perfect for storing objects. But there are cases where you just don't need to store objects and the relational model fits better. Table joins and things like that are handy and surely not "ancient". Moreover relational databases are nowadays very stable and proven, support special hardware, scale extremely well etc. Regards, Hermann -- x1@aon.at GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
Hermann Himmelbauer wrote:
On Wednesday 13 October 2004 22:47, Garito wrote:
Andreas Jung wrote:
--On Mittwoch, 13. Oktober 2004 9:15 Uhr -0700 Jason Leach
<jason.leach@gmail.com> wrote:
0. No standard DB support. I don't think ZPoPyDa has been updated since 2001. I'm sure that fills new developers with lots of confidence. Perhaps it works fine, but it's not being improved. Perhaps other DB interfaces are better. But then again ZSQL Methods are still ancient and in DTML.
There are enough DB adapters available for nearly every DB available. DAs are not shipped with the Zope core. If you need a particular DA you can easily download and install it. What is your problem with ZSQL methods? They are known to work fine (as instance in the ZODb or on the filesystem). Do you know a better framework for specifying SQl queries in a generic way?
This is my opinion and only my opinion: I think Zope has a DB (object oriented one). For that, I think that DB connectors are for backward compatibility with your ancien software but I would like to migrate data
I'm no specialist, but I think that's not true: An object oriented database is perfect for storing objects. But there are cases where you just don't need to store objects and the relational model fits better. Table joins and things like that are handy and surely not "ancient".
Moreover relational databases are nowadays very stable and proven, support special hardware, scale extremely well etc.
Regards, Hermann
Then why use object oriented aproach? If I think object and then store "data" I need a conversion but If I think objects and store objects no conversion needed, isn't it? Sometimes is difficult to change our minds Cheers!
This is my opinion and only my opinion: I think Zope has a DB (object oriented one). For that, I think that DB connectors are for backward compatibility with your ancien software but I would like to migrate data Not necessary. For example what if you want to manage concurrency? You will need row locking and perhaps table locking, thing, which I haven't figured out how to do with zope.
Other point would be the many-to-many relationships. Although there is some product to do this or you can simulate it, I think relational databases are more robust there. Finally, if you use a relational DB, then it will be easier to migrate to another application other than zope. Also, updates are much easier, you won't have problems with the objects as sometimes happens. That's why nowadays I'm working on an application to migrate some of my zope objects to tables. I think the Zope DB is good for documents, templates, scripts, images, files, authentication, and simple objects without special requirements like concurrency, but for more complicated data, a relational db may be more suitable. Regards, Josef
Hi Josef, Josef Meile wrote:
This is my opinion and only my opinion: I think Zope has a DB (object oriented one). For that, I think that DB connectors are for backward compatibility with your ancien software but I would like to migrate data
...[snip]...
I think the Zope DB is good for documents, templates, scripts, images, files, authentication, and simple objects without special requirements like concurrency, but for more complicated data, a relational db may be more suitable.
That's exactly how I see it - I've done some /sites/ which are Zope/Plone only, but most of my work is in developing /applications/ where the data resides in an RDBMS and Zope/Plone provides the infrastructure and user interface. I can see how, coming to it from a cold start, one might see the ZODB vs. RDBMS trade off as an either/or choice - or <gulp> see object databases as superceding RDBMSs. However, it's important to make the case that one should use the appropriate database for the task in hand. It's taken me a /long/ time to get to grips with it, but now I have a toolkit of scripts and templates for RDBMS tasks I'd argue that Zope/Plone may be the best tool around for an RDBMS based web application server, and that the presence of the ZODB may make it less apparent to those evaluating it just how good Zope is in that role. -- Regards, PhilK Email: phil@xfr.co.uk / Voicemail & Facsimile: 07092 070518 "Work as if you lived in the early days of a better nation." - Alasdair Gray
Josef Meile wrote:
This is my opinion and only my opinion: I think Zope has a DB (object oriented one). For that, I think that DB connectors are for backward compatibility with your ancien software but I would like to migrate data
Not necessary. For example what if you want to manage concurrency? You will need row locking and perhaps table locking, thing, which I haven't figured out how to do with zope.
Concurrency do not exists. Computers simulate concurrency but nothing can't do 2 things at time overcoat if you have only 1 HD or 1 CPU
Other point would be the many-to-many relationships. Although there is some product to do this or you can simulate it, I think relational databases are more robust there.
I manage relationships but not automagically like renational databases. In this case there are a lot of work to do, I know
Finally, if you use a relational DB, then it will be easier to migrate to another application other than zope. Also, updates are much easier, you won't have problems with the objects as sometimes happens. That's why nowadays I'm working on an application to migrate some of my zope objects to tables.
I think the Zope DB is good for documents, templates, scripts, images, files, authentication, and simple objects without special requirements like concurrency, but for more complicated data, a relational db may be more suitable.
Jeje, could you see? We are relational DB dependent
Regards, Josef
Regards Garito
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Not necessary. For example what if you want to manage concurrency? You will need row locking and perhaps table locking, thing, which I haven't figured out how to do with zope.
Concurrency do not exists. Computers simulate concurrency but nothing can't do 2 things at time overcoat if you have only 1 HD or 1 CPU What if you have two CPUs trying to access the same HD? I agree, one CPU will have the access first, but somehow you will have to block the resorce. If you try to simulate this with zope, you could think about a lock attribute on the object, but one thing could happen:
Three CPUs: A, B, and C are trying to access object D on Hardisk E. 1) CPU A Arives first and takes Object D and checks lock, which is zero. 2) CPU B, which was late, takes Object D just right after A, so, lock is still zero. 3) CPU A sets lock to one and modifies D on a html form. 4) CPU B sets lock to one and modifies D on a html form. 5) CPU A saves modifications and sets lock to one. 6) CPU C arives and takes D because lock is zero. As you see, CPU B and C are working with the false information. This is difficult to simulate with zope. That's why I think the row locking of a DB like mysql or postgres will do it better. The locking, if I'm not wrong, happens while accessing the data the first time. Regards, Josef
Josef Meile wrote:
Not necessary. For example what if you want to manage concurrency? You will need row locking and perhaps table locking, thing, which I haven't figured out how to do with zope.
Concurrency do not exists. Computers simulate concurrency but nothing can't do 2 things at time overcoat if you have only 1 HD or 1 CPU
What if you have two CPUs trying to access the same HD? I agree, one CPU will have the access first, but somehow you will have to block the resorce. If you try to simulate this with zope, you could think about a lock attribute on the object, but one thing could happen:
Three CPUs: A, B, and C are trying to access object D on Hardisk E.
1) CPU A Arives first and takes Object D and checks lock, which is zero. 2) CPU B, which was late, takes Object D just right after A, so, lock is still zero. 3) CPU A sets lock to one and modifies D on a html form. 4) CPU B sets lock to one and modifies D on a html form. 5) CPU A saves modifications and sets lock to one. 6) CPU C arives and takes D because lock is zero.
As you see, CPU B and C are working with the false information. This is difficult to simulate with zope. That's why I think the row locking of a DB like mysql or postgres will do it better. The locking, if I'm not wrong, happens while accessing the data the first time.
Regards, Josef _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
You are agree. This is what I mean when I talk about do a hard work The only difference between OODB and RDBMS is the previous work (I still remember when MySQL has no triggers or stored procedures) In my opinion a good work in ZODB would be these kind of features solved RDBMS are only more worked in these point but these is not a problem about OODB architecture You know my opinion: If I think in objects why I need a RDBMS data? But this is only an opinion Regards
You are agree. This is what I mean when I talk about do a hard work The only difference between OODB and RDBMS is the previous work (I still remember when MySQL has no triggers or stored procedures) In my opinion a good work in ZODB would be these kind of features solved RDBMS are only more worked in these point but these is not a problem about OODB architecture You know my opinion: If I think in objects why I need a RDBMS data? But this is only an opinion I agree, objects are easier an cleaner ;-)
On Wednesday 13 October 2004 12:15 pm, Jason Leach wrote:
0. No standard DB support.
I don't know what you mean by standard, but there are plenty of databases supported. ZODB comes to mind, and I've been using MySQL with Zope for years.
Perhaps it works fine, but it's not being improved.
If something needs improving, report it to the author.
But then again ZSQL Methods are still ancient and in DTML.
ZSQL Methods and DTML remain important parts of Zope. Neither is ancient.
1. Build in user management. The only solid product for this is LDAPUserFolder,
Then use LDAPUserFolder. I do.
3. Python Keeping python up to date to use products. Pain in the ass.
I find it quite easy to keep Pyhton up to date. apt/yum are your friends.
4. DTML/ZPT Seems 90% of Products are in DTML yet ZPT seems like the obvious thing to use.
ZPT is relatively new; DTML has been around a long time. Many products were written before ZPT became common.
Fine, except when you need to tweak a product and then have to learn DTML.
As mentioned above, DTML remains an important part of Zope. You should learn it. Zope 2 isn't perfect, but it's a very solid product for many. -- Ron
-- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
Am Mi, den 13.10.2004 schrieb Jason Leach um 18:15:
Are any of these significant detriments with Zope addressed in 2.7 or later?
0. No standard DB support. I don't think ZPoPyDa has been updated since 2001. I'm sure that fills new developers with lots of confidence. Perhaps it works fine, but it's not being improved. Perhaps other DB interfaces are better. But then again ZSQL Methods are still ancient and in DTML.
there are DAs for many relational databases.
1. Build in user management. This is stupid. The user management is good for companies of 10 people or so but what good is that to web application or ecomm site? You going to hand add users? The only solid product for this is LDAPUserFolder, the rest should still be in beta.
Aha. And with LDAP you enter users with your foot? :-) There are a number of userfolders where you can basically use whatever you want as source. Also watch out for the upcoming PluggabeAuthSource which will eventually be standard zope gear.
2. Debugging. This is worse. It is so complicated to debug Products or Zope crap I can't believe it. This is relative to PHP or JSP or ASP; all I have worked with.
No its not. You have different levels of debugging and usually you dont have to debug system internals. Can you with PHP, JSP, ASP interactively work in the running server? With Zope you can. (ZEO setup and zopectl debug)
3. Python Keeping python up to date to use products. Pain in the ass.
apt-get update; apt-get install. No pain.
4. DTML/ZPT Seems 90% of Products are in DTML yet ZPT seems like the obvious thing to use. Fine, except when you need to tweak a product and then have to learn DTML. PHP is PHP same for the most part with ASP (all VB if you like) or JSP (all java if you like).
One could argue PHP keeps sucking all the time where with Zope you have python scripts and ZPT to get away from DTML :-)
Honestly. If I new know what I do about zope I would not recommend it for commercial development. Go with a product that lots of people are using, this way you are ensured that components will be well supported and improved over time. Not dropped because the author has moved on.
Feel free to use whatever you feel comfortable with. There are many users who know PHP, ASP, JSP and Zope and use Zope. The point is - you are comparing apples with other fruits. Zope is much more then a bouch of scripts and macros. Regards Tino
Hi Jason, First of all, assuming I have decoded it correctly, let me take issue with your subject line - it's not a "POS". Jason Leach wrote:
Are any of these significant detriments with Zope addressed in 2.7 or later?
0. No standard DB support. I don't think ZPoPyDa has been updated since 2001. I'm sure that fills new developers with lots of confidence. Perhaps it works fine, but it's not being improved. Perhaps other DB interfaces are better.
I've never used ZPoPyDa because I'm not a PostgreSQL user. However, I've done extensive work against Firebird using KInterbasDA and SQL Server using mxODBC Zope DA and am very happy with both. My only criticism of the dB tools is that I'd like to see a free (as in beer) ODBC adapter - there is an ADO adapter, but I've not had cause to try it yet.
But then again ZSQL Methods are still ancient and in DTML.
I don't see the problem with DTML - it's v.useful in ZSQL methods, although I use ZPT for markup. I'm not sure what you mean by "ancient".
1. Build in user management. This is stupid. The user management is good for companies of 10 people or so but what good is that to web application or ecomm site? You going to hand add users? The only solid product for this is LDAPUserFolder, the rest should still be in beta.
Well from my PoV, that's simply not true - I'm using SMB authentication against Windows, and it works fine. What do you want to authenticate against?
2. Debugging. This is worse. It is so complicated to debug Products or Zope crap I can't believe it. This is relative to PHP or JSP or ASP; all I have worked with.
Again, I disagree. Admittedly my stuff is fairly simple, but I've recoiled in horror at the complexity and number of choices in JSP, and the general crumminess of ASP.
3. Python Keeping python up to date to use products. Pain in the ass.
You need the right version for what's running under it. I update my Python when I update my Zope, and use products that work with that combination of Zope and Python. Seems logical to me.
4. DTML/ZPT Seems 90% of Products are in DTML yet ZPT seems like the obvious thing to use. Fine, except when you need to tweak a product and then have to learn DTML. PHP is PHP same for the most part with ASP (all VB if you like) or JSP (all java if you like).
Well, ZPT made my head hurt for a long time - but it's very powerful. It's true that it's an issue that so much is still in DTML, but it's hardly a show stopper - take a look at Plone, which is all ZPT. I'm not qualified to comment on PHP, but WRT ASP, that's not true any more either, is it? Unless your aversion to "ancient" lets ASP 2.0 under your radar and you have missed ThisWeeksBigThing.NET! ;-)
Honestly. If I new know what I do about zope I would not recommend it for commercial development. Go with a product that lots of people are using, this way you are ensured that components will be well supported and improved over time. Not dropped because the author has moved on.
Well, I make a living doing commercial development with Zope and Plone, and whilst my RDBMS skills are good (most of my apps are web front ends for RDBMS applications) my Python/Zope/Plone skills are pretty primitive compared to many on this list. I've had to persevere a bit more than a Python coder would, but it has paid off in satisfaction. Your comment about components does not stand up. This business moves fast, and many fall by the wayside, so it's important to be selective about your choice of components - but this would apply in any environment in this business. I'm not sure if you're just venting, or if you want to address some of these issues. If the former, well you've done it. If the latter, you need to go into a bit more depth about what you want to accomplish in Zope and what you are comparing it to. HTH -- Regards, PhilK Email: phil@xfr.co.uk / Voicemail & Facsimile: 07092 070518 "Work as if you lived in the early days of a better nation." - Alasdair Gray
Actually, ZODB is a Persistent Object System, not Zope proper, so it would be better to say that Zope is built on a POS. pleased-to-have-cleared-that-up-ly y'rs - tim
I think sometimes newbies are thrown off by the object-orientedness of python, and by association, zope. Perhaps Jason never took any computer science classes. Also, an abstracted interface to objects is only good when documentation for the interfaces is plentiful and clear..... On Wed, 13 Oct 2004 13:26:25 -0400, Tim Peters <tim.peters@gmail.com> wrote:
Actually, ZODB is a Persistent Object System, not Zope proper, so it would be better to say that Zope is built on a POS.
pleased-to-have-cleared-that-up-ly y'rs - tim
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
-- Regards, Bryan Simmons -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Rick Osborne -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Jason Leach wrote:
Are any of these significant detriments with Zope addressed in 2.7 or later?
0. No standard DB support. I don't think ZPoPyDa has been updated since 2001. I'm sure that fills new developers with lots of confidence. Perhaps it works fine, but it's not being improved. Perhaps other DB interfaces are better. But then again ZSQL Methods are still ancient and in DTML.
1. Build in user management. This is stupid. The user management is good for companies of 10 people or so but what good is that to web application or ecomm site? You going to hand add users? The only solid product for this is LDAPUserFolder, the rest should still be in beta.
2. Debugging. This is worse. It is so complicated to debug Products or Zope crap I can't believe it. This is relative to PHP or JSP or ASP; all I have worked with.
3. Python Keeping python up to date to use products. Pain in the ass.
4. DTML/ZPT Seems 90% of Products are in DTML yet ZPT seems like the obvious thing to use. Fine, except when you need to tweak a product and then have to learn DTML. PHP is PHP same for the most part with ASP (all VB if you like) or JSP (all java if you like).
Honestly. If I new know what I do about zope I would not recommend it for commercial development. Go with a product that lots of people are using, this way you are ensured that components will be well supported and improved over time. Not dropped because the author has moved on. _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
No problem, don't recomend it (its pretty clear you don't undersand Zope) jejejeje To the rest: some critiques are not quite unjust, we need to work stronger! ;)
0. No standard DB support. I don't think ZPoPyDa has been updated since 2001. I'm sure that fills new developers with lots of confidence. Perhaps it works fine, but it's not being improved. Perhaps other DB interfaces are better. But then again ZSQL Methods are still ancient and in DTML. You're right about ZPoPyDa, but why to use it having psycopg, which is newer (dated from 2003-11-24, which is not bad) and works with zope 2.7.2? I agree also that ZSQL Methods look weard, but they work. However, you could also user pure python if you want, after all they are just wrappers. And about the DA changes, I think there isn't much things to improve them, after all the heavy work is still done by the database engine.
2. Debugging. This is worse. It is so complicated to debug Products or Zope crap I can't believe it. This is relative to PHP or JSP or ASP; all I have worked with. I think there is a commercial IDE, which works with Python, Zope, and Plone. If debugging is a concern to you, then buy it.
4. DTML/ZPT Seems 90% of Products are in DTML yet ZPT seems like the obvious thing to use. Fine, except when you need to tweak a product and then have to learn DTML. PHP is PHP same for the most part with ASP (all VB if you like) or JSP (all java if you like). I think that's not a zope's problem. The choosing of DTML or ZPT is done by the developer and not by zope corp. Welcome to open source.
Honestly. If I new know what I do about zope I would not recommend it for commercial development. Go with a product that lots of people are using, this way you are ensured that components will be well supported and improved over time. Not dropped because the author has moved on. I think zope is also well supported, the comunity is great and it's used by lots of people. Perhaps the documentation isn't good sometimes (I included me here as well), but it is open source, so the people doing it isn't hired to write it. It is a voluntary effort.
Anyway, I only have to say that I'm a happy zope user and I really appreciate the effort of the core and product developers. Thanks to all of them. Regards, Josef
Jason Leach wrote: (snipped - obvious troll) Please, Jason, stick to PHP/ASP/JSP/whatever you like best. -- Bruno Desthuilliers - Analyste-programmeur bruno@modulix.org www.modulix.com
participants (12)
-
Andreas Jung -
bruno modulix -
Bryan Simmons -
Garito -
Hermann Himmelbauer -
Jason Leach -
Josef Meile -
Philip Kilner -
Ron Bickers -
Tim Peters -
Tino Wildenhain -
Tres Seaver