[Zope-dev] Announcement: gocept.zcapatch 1.0 released
Hello, after much discussion[1], Thomas Lotze and I tried to implement generic copying/stacking of component registries[2], but ultimately failed due to the same issues that Martin Aspeli had already foreseen: For the general case there are way too many edge cases, especially regarding persistent registries. So we decided to solve our most immediate needs (that are not taken care of by plone.testing's stacking solution of the global registry), namely temporarily altering utility/adapter/handler registrations. We've now released this effort as gocept.zcapatch[3], and look forward to comments and further ideas about this. I also wonder whether this might eventually get another home (plone.testing? zope.component? Or, nowadays, zope.interface?), but that's for after trying it out in the real world. Wolfgang [1] http://thread.gmane.org/gmane.comp.web.zope.devel/26469/focus=26484 [2] http://svn.zope.org/zope.component/branches/wosc-test-stacking/ http://svn.zope.org/zope.interface/branches/wosc-test-stacking/ [3] http://pypi.python.org/pypi/gocept.zcapatch -- Wolfgang Schnerring · email/jabber: w...@gocept.com · software development gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 219401 0 · fax +49 345 1229889 1 Python, Pyramid, Plone, Zope - consulting, development, hosting, operations signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] merge zope.configuration dictactions branch
On Mon, 2011-12-05 at 08:07 +0100, Wolfgang Schnerring wrote: * Chris McDonough chr...@plope.com [2011-12-05 04:02]: ssh://svn.zope.org/repos/main/zope.configuration/branches/chrism-dictactions I want to be able to associate a new value (introspectables) with each ZCML configuration action On the zope.configuration trunk (and in all past releases), each ZCML action is maintained as a tuple. The tuple can be of any length up to seven elements, but mustn't exceed a length of seven. the z.config code is much easier to understand when the action is just a dictionary instead of a pseudo-struct. +1, this makes a lot of sense to me. The chrism-dictactions branch was merged to trunk; the changes will be present in zope.configuration 3.8.0 (once released). - C ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] merge zope.configuration dictactions branch
Hi Chris,
Am 05.12.2011, 04:02 Uhr, schrieb Chris McDonough chr...@plope.com:
On the zope.configuration trunk (and in all past releases), each ZCML
action is maintained as a tuple. The tuple can be of any length up to
seven elements, but mustn't exceed a length of seven. A complex system
of lengthening and shortening (in
zope.configuration.config.resolveConflicts) tries to ensure that the
tuple is of the smallest length required by chopping false elements off
the end of each action tuple during storage and reconstituting them to
7-element tuples during processing and sorting. I think this juke was
purely to make doctests easier to write, but I'm not entirely sure.
eek! I'm sure there was a better reason for this in the first place. As
things stand ZCML declarations are not orthogonal so a key-based approach
seems the better fit.
Up til now, pyramid_zcml could live with actions being at most 7
elements. But recent changes to the Pyramid trunk (adding
introspectables) blew out the presumption that an action tuple could
be no longer than 7 elements (it now might need to be 8 elements).
Rather than extend the structure of the zope.configuration tuple with a
Pyramid-only introspectables argument, I've created the
chrism-dictactions branch
(http://svn.zope.org/zope.configuration/branches/chrism-dictactions/)
which changes ZCML action structures to be dictionaries. This allows
each action to contain arbitrary keys. This modification satisfies the
immediate requirement (adding introspectables) and allows us to never
need to change the zope.config code again if more elements need to be
added to actions.
+1 as all ZTK test pass.
I could have instead added an extras dictionary on to the end of the
tuple as an 8th element, but it seems six of one a half dozen of
another, and the z.config code is much easier to understand when the
action is just a dictionary instead of a pseudo-struct.
I'm trying to think of where I've seen that pattern of {'organised'
'others':{}} before... oh, yes in dodgy RDBMS schema.
Charlie
--
Charlie Clark
Managing Director
Clark Consulting Research
German Office
Kronenstr. 27a
Düsseldorf
D- 40217
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] transaction pkg release (was Re: zope.sqlalchemy+py3 test failures)
On Sun, 2011-12-04 at 22:12 -0500, Chris McDonough wrote: I'm going to make a new major release of the transaction package tomorrow (without the savepoint release features, and bw incompat with 2.4 and 2.5), unless I hear otherwise. transaction 1.2.0 released with Py3 compat (and removing Py2.4 and Py2.5) compatibility. Tested against the ztk trunk tests under Python 2.6. - C ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zope.sqlalchemy release
Tomorrow, I plan to: - Merge the chrism-py3 branch of zope.sqlalchemy into its trunk. (http://svn.zope.org/zope.sqlalchemy/branches/chrism-py3/) to get Python 3 compatibility. - Once the compat branch is merged, I'll make a 0.7 release of zope.sqlalchemy. Any dissent? - C ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zope-tests - FAILED: 3, OK: 44
This is the summary for test reports received on the zope-tests list between 2011-12-04 00:00:00 UTC and 2011-12-05 00:00:00 UTC: See the footnotes for test reports of unsuccessful builds. An up-to date view of the builders is also available in our buildbot documentation: http://docs.zope.org/zopetoolkit/process/buildbots.html#the-nightly-builds Reports received Bluebream / Python2.5.5 64bit linux Bluebream / Python2.6.7 64bit linux Bluebream / Python2.7.2 64bit linux ZTK 1.0 / Python2.4.6 Linux 64bit ZTK 1.0 / Python2.5.5 Linux 64bit ZTK 1.0 / Python2.6.7 Linux 64bit ZTK 1.0dev / Python2.4.6 Linux 64bit ZTK 1.0dev / Python2.5.5 Linux 64bit ZTK 1.0dev / Python2.6.7 Linux 64bit ZTK 1.1 / Python2.5.5 Linux 64bit ZTK 1.1 / Python2.6.7 Linux 64bit ZTK 1.1 / Python2.7.2 Linux 64bit ZTK 1.1dev / Python2.5.5 Linux 64bit ZTK 1.1dev / Python2.6.7 Linux 64bit ZTK 1.1dev / Python2.7.2 Linux 64bit Zope 3.4 KGS / Python2.4.6 64bit linux Zope 3.4 KGS / Python2.5.5 64bit linux Zope 3.4 Known Good Set / py2.4-32bit-linux Zope 3.4 Known Good Set / py2.4-64bit-linux Zope 3.4 Known Good Set / py2.5-32bit-linux Zope 3.4 Known Good Set / py2.5-64bit-linux Zope-2.10 Python-2.4.6 : Linux Zope-2.11 Python-2.4.6 : Linux Zope-2.12 Python-2.6.6 : Linux Zope-2.12-alltests Python-2.6.6 : Linux Zope-2.13 Python-2.6.6 : Linux Zope-2.13-alltests Python-2.6.6 : Linux Zope-trunk Python-2.6.6 : Linux Zope-trunk-alltests Python-2.6.6 : Linux [1]winbot / ZODB_dev py_254_win32 [2]winbot / ZODB_dev py_265_win32 [3]winbot / ZODB_dev py_265_win64 winbot / ZODB_dev py_265_win64 winbot / ZODB_dev py_270_win32 winbot / ZODB_dev py_270_win64 winbot / ztk_10 py_254_win32 winbot / ztk_10 py_265_win32 winbot / ztk_10 py_265_win64 winbot / ztk_11 py_254_win32 winbot / ztk_11 py_265_win32 winbot / ztk_11 py_265_win64 winbot / ztk_11 py_270_win32 winbot / ztk_11 py_270_win64 winbot / ztk_dev py_265_win32 winbot / ztk_dev py_265_win64 winbot / ztk_dev py_270_win32 winbot / ztk_dev py_270_win64 Non-OK results -- [1]FAILED winbot / ZODB_dev py_254_win32 https://mail.zope.org/pipermail/zope-tests/2011-December/053672.html [2]FAILED winbot / ZODB_dev py_265_win32 https://mail.zope.org/pipermail/zope-tests/2011-December/053673.html [3]FAILED winbot / ZODB_dev py_265_win64 https://mail.zope.org/pipermail/zope-tests/2011-December/053674.html ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope-tests - FAILED: 3, OK: 44
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [1]FAILED winbot / ZODB_dev py_254_win32 https://mail.zope.org/pipermail/zope-tests/2011-December/053672.html This appears to be due to the incompatibility of transaction 1.2 with Python 2.6: - -- % --- Getting distribution for 'transaction=1.1.0'. File build\bdist.win32\egg\transaction\tests\savepointsample.py, line 26 class SampleDataManager(object): ^ SyntaxError: invalid syntax File c:\eggs\tmpp2qpjq\transaction-1.2.0-py2.5.egg\transaction\tests\savepointsample.py, line 26 class SampleDataManager(object): ^ SyntaxError: invalid syntax - -- % --- [2]FAILED winbot / ZODB_dev py_265_win32 https://mail.zope.org/pipermail/zope-tests/2011-December/053673.html [3]FAILED winbot / ZODB_dev py_265_win64 https://mail.zope.org/pipermail/zope-tests/2011-December/053674.html These are both odd doctest failures, perhaps also related to the recent transaction release? - -- % --- File c:\buildslave\zodb_dev_py_265_win32\build\src\ZODB\tests\testConnectionSavepoint.txt, line 185, in testConnectionSavepoint.txt Failed example: savepoint2.rollback() Expected: Traceback (most recent call last): ... InvalidSavepointRollbackError Got: Traceback (most recent call last): File c:\Python26_32\lib\doctest.py, line 1253, in __run compileflags, 1) in test.globs File doctest testConnectionSavepoint.txt[49], line 1, in module savepoint2.rollback() File c:\eggs\transaction-1.2.0-py2.6.egg\transaction\_transaction.py, line 705, in rollback 'invalidated by a later savepoint') InvalidSavepointRollbackError: invalidated by a later savepoint - -- % --- Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7dcHcACgkQ+gerLs4ltQ6d0gCfZCjd/rcQ7hf15SJrbEU6CZU+ UgIAoIDHZ6ekXMXy/I/cifX6eKQaHcWN =9ig/ -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope-tests - FAILED: 3, OK: 44
On Mon, 2011-12-05 at 20:31 -0500, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [1]FAILED winbot / ZODB_dev py_254_win32 https://mail.zope.org/pipermail/zope-tests/2011-December/053672.html This appears to be due to the incompatibility of transaction 1.2 with Python 2.6: - -- % --- Getting distribution for 'transaction=1.1.0'. File build\bdist.win32\egg\transaction\tests\savepointsample.py, line 26 class SampleDataManager(object): ^ SyntaxError: invalid syntax File c:\eggs\tmpp2qpjq\transaction-1.2.0-py2.5.egg\transaction\tests\savepointsample.py, line 26 class SampleDataManager(object): ^ SyntaxError: invalid syntax - -- % --- This bot configuration needs to be disabled (py 2.5 + ZODB trunk, that is). [2]FAILED winbot / ZODB_dev py_265_win32 https://mail.zope.org/pipermail/zope-tests/2011-December/053673.html [3]FAILED winbot / ZODB_dev py_265_win64 https://mail.zope.org/pipermail/zope-tests/2011-December/053674.html These are both odd doctest failures, perhaps also related to the recent transaction release? Yes. I'll see if I can fix it in the ZODB trunk. - C ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.sqlalchemy release
On Mon, Dec 05, 2011 at 04:21:51PM -0500, Chris McDonough wrote: Tomorrow, I plan to: - Merge the chrism-py3 branch of zope.sqlalchemy into its trunk. (http://svn.zope.org/zope.sqlalchemy/branches/chrism-py3/) to get Python 3 compatibility. - Once the compat branch is merged, I'll make a 0.7 release of zope.sqlalchemy. Any dissent? None from me! This all looks like great work. -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope-tests - FAILED: 3, OK: 44
Hello, Jim? On Mon, 05 Dec 2011 23:47:06 -0500 you wrote: On Mon, 2011-12-05 at 20:31 -0500, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [1]FAILED winbot / ZODB_dev py_254_win32 https://mail.zope.org/pipermail/zope-tests/2011-December/053672.html This appears to be due to the incompatibility of transaction 1.2 with Python 2.6: - -- % --- Getting distribution for 'transaction=1.1.0'. File build\bdist.win32\egg\transaction\tests\savepointsample.py, line 26 class SampleDataManager(object): ^ SyntaxError: invalid syntax File c:\eggs\tmpp2qpjq\transaction-1.2.0-py2.5.egg\transaction\tests\savepointsample.py, line 26 class SampleDataManager(object): ^ SyntaxError: invalid syntax - -- % --- This bot configuration needs to be disabled (py 2.5 + ZODB trunk, that is). [2]FAILED winbot / ZODB_dev py_265_win32 https://mail.zope.org/pipermail/zope-tests/2011-December/053673.html [3]FAILED winbot / ZODB_dev py_265_win64 https://mail.zope.org/pipermail/zope-tests/2011-December/053674.html These are both odd doctest failures, perhaps also related to the recent transaction release? Yes. I'll see if I can fix it in the ZODB trunk. - C ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope ) -- Best regards, Adam GROSZER -- Quote of the day: Even on the road to hell, flowers can make you smile. - Deng Ming-Dao ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope] Help in deciding approach to Web App
On 12/04/2011 09:56 PM, Fernando Martins wrote: On 12/04/2011 09:31 PM, John Schinnerer wrote: In any case, this looks (to me anyhow) like a very object-oriented system you are modeling so an object oriented approach and language would seem most suitable. And how would you create (and update) objects in Python for: at least 500 tools as of now, and it is bound to grow in the future as newer tools are introduced. Existing tools will also have version updates. Each tool, on average, has at least 100 properties that define the tool. Some of them have as high as 1000 unique properties. How familiar are you with OOP? What I mean is, when I read your high-level description of what you want to do, I imagine objects interacting with other. In your car wash example I see that, for instance. Or any kind of work-flow, which is what this sounds like to me. A state machine. Each tool is an object; it knows what its properties and abilities and possible states are and can communicate them to other objects and can accept and act on communication from other objects. In that way the objects interact with one another to do whatever it is you build them to do. I'm thinking of your car wash metaphor. In a car wash there are a variety of elements (objects) that communicate with one another to move the car through and to wash it as it moves through. Simple example: * mechanism that pulls or pushes the car through * mechanism that sprays it with water and soap * mechanism that scrubs and wipes and rubs it * mechanism that sprays it with rinse water * drying mechanism(s) These all need to signal one another so they do the right thing at the right time. Spray (or scrub or blow hot air) only when the car is in the right place for each. If some tools can be built by adding to/extending other tools, that is an object-friendly situation, since enhancing an existing tool to make another that you need saves you having to create all tools from scratch. In the car wash, maybe the different sized scrubbers used are all made by bolting together two or more of the smallest size scrubber. Maybe in parallel, maybe in series, depends on what is needed. Maybe the same scrubber controller can have different size brushes attached to it. In short, an object - tool - is code and data that interacts with other tools (other entities of code and data). An upgrade to a tool would involve changing the code and/or data that constitutes the tool. If that introduces some new way of interacting that other tools need to also know, then you add that to those tools also. Adding more tools means coding them. If they can be based on existing tools, so much the easier (and more object-appropriate). So that's some high-level information about an object-oriented approach to what I think your project is about. Tthe flexibility you appear to need as the system grows may be problematic for an RDB. And, my bias is OO, so perhaps someone who thinks in RDB-space can describe at high level how this would look in an RDB implmentation. cheers, John S. -- John Schinnerer - M.A., Whole Systems Design - Eco-Living - Whole Systems Design Services People - Place - Learning - Integration j...@eco-living.net http://eco-living.net ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Help in deciding approach to Web App
Am Sonntag, 4. Dezember 2011, 16:15:13 schrieben Sie: As you mentioned, if I have to use mySQL, isn't it better for me to go with PHP+mySQL - easier to learn and deploy? ...just from my experience: PHP is - for different, but mainly technical/historical reasons - very widely spread within web applications, one major reason was/is i.e. the large (because easy) availability on low cost hosting environments in the past - but the most advantages was/are on the side of the hosting providers PHP might be easier to learn then other languages or frameworks, but maintaining large / complex applications / software projects within PHP could be a real mess. We develop nearly any web application with Zope / ZODB since = 10 years but are a hosting company byself - so we was not bound to PHP as many other internet hosting users in the past. A colleagues company produces very high level expert systems on Perl and Catalyst - requiring high skilled Perl programmers. From my experience developing within Zope / ZODB (with Python, DTML and/or ZPT) allows very high quality products within very short timeframes and even further maintaining the project is relative ressource efficient - especially compared to PHP. Most web application data structures (i.e. a simple web page) fit's much better by a oo object strategy then a relational (RDBMS) one. The major typical ressource hole within typical PHP+SQL web applications or i.e. a CMS solution is the translation of typical data objects into tables and vice versa. Producing i.e. one simple CMS page within a PHP-SQL CMS easily could trigger hundreds of SQL requests into many different tables - a significant overhead which has to implemented by developers and handled by the machines. But this is my view onto the issue - just my two cents... cheers, Niels. -- --- Niels Dettenbach Syndicat ITInternet http://www.syndicat.com/ signature.asc Description: This is a digitally signed message part. ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Help in deciding approach to Web App
On Dec 5, 2011 09:48 John Schinnerer j...@eco-living.net wrote: On 12/04/2011 09:56 PM, Fernando Martins wrote: On 12/04/2011 09:31 PM, John Schinnerer wrote: In any case, this looks (to me anyhow) like a very object-oriented system you are modeling so an object oriented approach and language would seem most suitable. And how would you create (and update) objects in Python for: at least 500 tools as of now, and it is bound to grow in the future as newer tools are introduced. Existing tools will also have version updates. Each tool, on average, has at least 100 properties that define the tool. Some of them have as high as 1000 unique properties. How familiar are you with OOP? I think you are confusing me with the OP. And you did not answer my question. Are you recommending that a programmer codes all these objects by hand in Python? The know-how of what constitutes a tool, their properties and even the tool selection criteria is not developer know-how. Therefore, this information should be defined outside the program in way that the tool expert(s) can manage it. Which leads us to some storage solution, an RDB being the most common. Since, as I pointed out before, SQL most likely would not be able to do the tool selection alone, Python would merely load the data from the external source and create objects and expertise on the fly. Anyway, I agree with you that the main issue does not seem to be the web publishing solution, but rather how to represent the tool information and how to do tool selection, which is off-topic. Regards, Fernando ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Help in deciding approach to Web App
Hi NielsI agree with you, even though I have no experience. But I'm restricted by hosting options for Zope at the moment, and will revert to Python once the project is deployed - and when I figure out whether mySQL is good enough or not. I hate having to type all those extra characters in php though.sareesh From: n...@syndicat.com To: ays...@hotmail.com; zope@zope.org Subject: Re: [Zope] Help in deciding approach to Web App Date: Mon, 5 Dec 2011 11:25:18 +0100 Am Sonntag, 4. Dezember 2011, 16:15:13 schrieben Sie: As you mentioned, if I have to use mySQL, isn't it better for me to go with PHP+mySQL - easier to learn and deploy? ...just from my experience: PHP is - for different, but mainly technical/historical reasons - very widely spread within web applications, one major reason was/is i.e. the large (because easy) availability on low cost hosting environments in the past - but the most advantages was/are on the side of the hosting providers PHP might be easier to learn then other languages or frameworks, but maintaining large / complex applications / software projects within PHP could be a real mess. We develop nearly any web application with Zope / ZODB since = 10 years but are a hosting company byself - so we was not bound to PHP as many other internet hosting users in the past. A colleagues company produces very high level expert systems on Perl and Catalyst - requiring high skilled Perl programmers. From my experience developing within Zope / ZODB (with Python, DTML and/or ZPT) allows very high quality products within very short timeframes and even further maintaining the project is relative ressource efficient - especially compared to PHP. Most web application data structures (i.e. a simple web page) fit's much better by a oo object strategy then a relational (RDBMS) one. The major typical ressource hole within typical PHP+SQL web applications or i.e. a CMS solution is the translation of typical data objects into tables and vice versa. Producing i.e. one simple CMS page within a PHP-SQL CMS easily could trigger hundreds of SQL requests into many different tables - a significant overhead which has to implemented by developers and handled by the machines. But this is my view onto the issue - just my two cents... cheers, Niels. -- --- Niels Dettenbach Syndicat ITInternet http://www.syndicat.com/ ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Help in deciding approach to Web App
Am Montag, 5. Dezember 2011, 11:37:46 schrieb Sareesh Sudhakaran: But I'm restricted by hosting options for Zope at the moment, and will revert to Python once the project is deployed - and when I figure out whether mySQL is good enough or not. I hate having to type all those extra characters in php though.sareesh If i talk about Zope / Python i mean Zope (with Zope Python Script Objects and/or external (Python) Methods). At a earlier stage Zope devels discussed for integrating ingres or another RDBMS natively into Zope - but this is not longer the case as there are many Zope adapters / integrations / products available for different major RDBMS like MySQL or Postgres. For the data structures where you have to handle large tables MySQL would be the first choice while oo data structures would preferrably go into your ZODB. I.e. we handle large amounts of user data records within MySQL while all of the web content objects or even complex shopping products are handled within ZODB - both within the same Shopping Cart application. This all depends highly from you data model. By theory you are able to handle both in just on of the DB solutions. With Zope you have many options to use external database solutions within your Zope based application. best regards, Niels. -- --- Niels Dettenbach Syndicat ITInternet http://www.syndicat.com/ signature.asc Description: This is a digitally signed message part. ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Help in deciding approach to Web App
On Dec 5, 2011 10:25 Niels Dettenbach n...@syndicat.com wrote: From my experience developing within Zope / ZODB (with Python, DTML and/or ZPT) allows very high quality products within very short timeframes and even further maintaining the project is relative ressource efficient - especially compared to PHP. How would you put 500+ objects (for the tools) each with hundreds or thousands of attributes in in ZODB? Regards, Fernando ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Fwd: Re: Re: Help in deciding approach to Web App
On Dec 5, 2011 14:38 Niels Dettenbach n...@syndicat.com wrote: Am Montag, 5. Dezember 2011, 14:23:57 schrieben Sie: How would you put 500+ objects (for the tools) each with hundreds or thousands of attributes in in ZODB? This depends from the object structure and transforms to do with it, but - as i wrote - it could make sense to use different database solutions in parallel for the same application and/or different parts of the same data objects. I was asking about tools and technology, not about object design. Would you develop a Zope Product (or set of Products) or is there a different approach. The Zope book tells us nothing about creating custom objects in ZODB. Assuming a simple case of a web form to input a set of fixed attributes to define a tool object in ZODB, what is the simplest approach to create/update an object in ZODB? Putting 500+ data objects with very different and changing structures into a RDBMS could be a much larger mess... I agree, that's why I mentioned in my first post that this is not a typical Books and Authors data model. In a case like this, without more requirements information, I would say a table to define tools only with common attributes, another table to define relationships between tools, another table to list all possible attribute names and another one to define the specific attribute values for the tools. But this discussion is off-topic and even irrelevant with so little specification. Regards, Fernando ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Zope Digest, Vol 91, Issue 2
On 12/05/2011 03:12 PM, Sareesh Sudhakaran wrote: Hi John and Fernando Intuitively I feel that my project fits in with an Object DB, which is why I have spent a lot of time trying to understand its methodology. But now I'm more confused than ever. Sareesh, could you be more specific about what confuses you? You have several routes, you need to give proper consideration to those routes. Maybe it would also help us if you clarify what is your skillset and experience in software development. Also, is your problem a CIM one? see http://en.wikipedia.org/wiki/Computer-integrated_manufacturing and specifically the key challenge listed over there. I have the impression you might be underestimating the problem. Finally, do you already have information about the tools in some electronic format? And what about the rules to choose tools? Is there already some computer based solution to help with the current problem? Please keep in mind that OOP and Object DB is not the same thing. You can work with objects in Python and never rely on OODB. I have serious doubts about using ZODB at your stage because AFAIK, creating custom objects requires the development of zope Products. Note that the zope book does not teach you about creating custom objects in the ZODB. You need another whole book for that. And the combination RDB and ZODB suggested by Neils/John seems too complicated as a start. I think you have a high learning curve ahead of you if have to learn to create Zope Packages to put objects in ZODB. But maybe there are simpler ways that I am not aware of. I'm sure OOP in Python and RDB is a good option. ZODB itself, I'm not so sure. Maybe others can enlighten you better here. It appears to me you don't have much experience and it looks like there is a long evolutionary project ahead of you. For these reasons, I would highly recommend Python. BTW, I never recommended and I do not recommend C/C++ for your needs, I just mentioned that I used it for a similar purpose many years ago. I would recommend you to do some programming in Python just to read some tool data from a text file, create some objects and try to do some tool selection where the output is merely done with print. Then you can upgrade to use MySQL to store your tool data and then you can decide if you go the Zope or the PHP route. Keep in mind that RDBs are a huge standard with many people and tools around it, whereas ZODB is very much a small niche in comparison. That should also weigh in your criteria. Regards, Fernando ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Zope Digest, Vol 91, Issue 2
Hi Fernando, I have experience in Pascal and C - but from 10 years ago and only in college capacity. But I've done some medium size projects in both (about 8000 to 10,000 lines each). Lately, my experience is limited to HTML/CSS and a tiny bit of Actionscript (for my flash websites). I have no OOP experience (C++). I have downloaded Python and PHP and have used both with Komodo Edit IDE, side by side, and have realized I would ideally want to program in Python. But I'm okay with PHP also - which means my choice of programming language depends on my choice of DB. Also, PHP has OOP 'capabilities' whatever that means - so maybe I can still use it like Python to a certain extent. I want to learn the least number of programs, which is why I had given myself three options:1. PHP + mySQL - the path of least resistance if an Object DB is not required. [I have no idea how to use Python with mySQL and the advice from googling is too confusing]2. Doctrine + PHP + mySQL or Django - for ORM with RDB 3. Bluebream for Object DB (I've found a couple of hosting providers who will let me install Zope on their VPS plans - so I'm okay with that) Can you point me to a resource for Python and mySQL? I've bought 'Dive into Python' but it has no reference on how to use it with mySQL. If my current hosting provider supports Python and mySQL, can I make it work? They won't let me install anything on the server side though, so I can't use any modules that aren't there already. Coming back to my particular scenario: No, it's not a CIM problem, but it does share the same level of complexity and hierarchy. There is no computer based solution that can be used - I'd researched that first. My app is purely software based for now. I already have information on the tools - but I have to organize them to suit the logic I'm going to use. I've spent the last two weeks collecting data in Excel, and this exercise is what started the confusion and my subsequent 'discovery' of the concept of Object Databases. I'll try to make my issue clearer. Let's say I want to compare the performance of two light bulbs, within a Building Management System (Lighting Component). If I use two CFL bulbs from two manufacturers - e.g. Philips and GE, they have slightly 'mis-matching' specifications. The possible scenarios:1. As marketing gimmicks, manufacturers might use different standards to test their bulbs, and maybe the same variable on paper (say lux, voltage, whatever) means two different things. Also, some manufacturers will include irrelevant data but I cannot discard it. As the 'expert' it is my job to make sense of the specifications and enter the data to use in the logic. However, my own standards might change in the future - either due to error or better methodology, etc. 2. One bulb might have a dimmer that has only two stops (similar to the rpm example) and the other bulb might have a continuous dimmer over a variable voltage. How do I input this information in a database? Other variables might have similar issues - like the first bulb can only operate strictly at 110/240V while the other can go from 50 to 300 or maybe it's only 240V. Etc. This issue exists in most tools, and is not a one-off problem.3. What happens when I suddenly decide to add 'different' tools? Instead of comparing CFLs, I now have to add a tungsten or an LED bulb and compare it against a CFL. The standards are completely different, and the logic is easy.4. Once a bulb is manufactured its specifications are set. But for complex machinery, there might be firmware updates that change a lot of variables. For each update, I have to create a new tool in the database - but I'll be repeating a lot of data. What if a manufacturer has the habit of releasing updates every month?5. Even on old tools, I might 'discover' new data - e.g., the materials used in a bulb might contribute towards toxicity or environmental pollution, and is now an important factor to consider - so I'll have to update a tool to add this new feature.6. My logic will have to pull data from any database - e.g. to find the best energy saving path in a building many different kinds of electric devices have to be considered. The total number of tools right now is only around 500 (1000), and it will always remain less than 10x this amount (at least in the foreseeable future). However, the relationships between these tools is many to many. I'm not sure whether this complexity has to be shared by the database or is it just a problem for the logic.7. Some tools are manufactured products, and their data will not change 99.9% of the time (unless it's point 5 above). However, some tools are software based, and its functioning can be affected by many features - e.g. changing the RAM/HDD/CPU etc might speed up or slow down a piece of software. The variables for this kind of tool can change - the data is not constant in this case.8. Last but not least, if my app is to
