[Zope-dev] zope-tests - FAILED: 5, OK: 46
This is the summary for test reports received on the zope-tests list between 2011-12-03 00:00:00 UTC and 2011-12-04 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 [1]Repository policy check found errors in 301 projects [2]Total languishing bugs for zope2: 5 [3]Total languishing bugs for zope: 71 [4]Total languishing bugs for zopeapp: 1 [5]Total languishing bugs for zopetoolkit: 206 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 winbot / ZODB_dev py_254_win32 winbot / ZODB_dev py_265_win32 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 Repository policy check found errors in 301 projects https://mail.zope.org/pipermail/zope-tests/2011-December/053590.html [2]FAILED Total languishing bugs for zope2: 5 https://mail.zope.org/pipermail/zope-tests/2011-December/053588.html [3]FAILED Total languishing bugs for zope: 71 https://mail.zope.org/pipermail/zope-tests/2011-December/053587.html [4]FAILED Total languishing bugs for zopeapp: 1 https://mail.zope.org/pipermail/zope-tests/2011-December/053582.html [5]FAILED Total languishing bugs for zopetoolkit: 206 https://mail.zope.org/pipermail/zope-tests/2011-December/053586.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 )
[Zope-dev] merge zope.configuration dictactions branch
ssh://svn.zope.org/repos/main/zope.configuration/branches/chrism-dictactions Rationale: I want to be able to associate a new value (introspectables) with each ZCML configuration action, in support of ZCML support for Pyramid features described at: http://docs.pylonsproject.org/projects/pyramid/en/latest/narr/introspector.html http://docs.pylonsproject.org/projects/pyramid/en/latest/narr/extconfig.html#configuration-introspection A rough example UI for the feature is shown here: http://static.repoze.org/introspection/ 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. 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. 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. All ZTK tests pass with the chrism-dictactions branch, and any code that depended upon the action structures was likely overstepping its bounds anyway. I'd like to merge this branch to the zope.configuration trunk as a result, and create a new release. The (unlikely) alternatives are: drop support for ZCML in Pyramid, drop plans to support introspectables in Pyramid. ___ 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] transaction pkg release (was Re: zope.sqlalchemy+py3 test failures)
On Wed, 2011-10-12 at 06:07 -0400, Chris McDonough wrote: On Sat, 2011-10-01 at 03:28 -0400, Chris McDonough wrote: On Thu, 2011-09-29 at 15:22 +0100, Laurence Rowe wrote: I've added chrism as an owner. Before we make a final release I'd like to revisit the savepoint release branches of transaction / zope.sqlalchemy. I'll bring this up in another mail. Sorry I haven't merged the transaction stuff to trunk yet. While doing a review, I realize that one downside to doing this merge is that it will kill Python 2.4 and 2.5 compatibility. I think this is a reasonable thing, given that Python 2.5 will no longer get any maintenance as of today or so, and Python 2.4 hasn't gotten any for a long time, and folks who need a 2.4/2.5 compat version can always use an older version. That said, before I go ahead and do this merge, is there anyone who believes we should continue to support 2.4 and 2.5 in the transaction package? If so, for how long? Nobody responded to this, so I've merged the chrism-py3 branch into the trunk. Any word on the savepoint release branch featureset before I make a release? 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. - 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
* 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. Wolfgang ___ 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
Thanks AJ. I assumed an OODBMS would be the right choice because of the object nature of my 'tools'. Of course, it was an assumption. Instead of Pyramid+RDBMS, can I use PHP+mySQL (my current hosting provider supports this).If ZODB isn't for my project, then would a GraphDB help? I have no idea on where to start with Graph DB - I've read the wikis and it's made me more confused. -ss Date: Sun, 4 Dec 2011 08:40:28 +0100 From: li...@zopyx.com To: ays...@hotmail.com CC: zope@zope.org Subject: Re: [Zope] Help in deciding approach to Web App -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - From reading: your database model appears pretty much relational. Where would you take advantages from using Zope as framework? This sounds like a task for Pyramid + RDBMS or a graph DB. - -aj Sareesh Sudhakaran wrote: I have a personal project - a web application I wanted to develop - but I'm confused on which route to take. I am not under any time constraint. *About the App:* The best I can describe it is as a kind of expert system (but not AI) that needs to find the best workflow for a process, given a set of initial and final parameters. E.g. a 'capsule' of data must pass through many 'tools' or 'environments' to reach a desired output - something like a very complicated car wash. Let's say there are many tools that can be used at various stages in the process. I have estimated there are 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. Some of these tools are linked to each other - e.g if one tool is selected, there are only n tools that can correspond to it for the next step in the process. I also have the problem of 'matching' the tools for analysis. E.g. Tool A might have only three fixed rpms - 100, 200 and 500, but Tool B might have rpms from 20 to 2000. I'm not sure how I can construct a database without spelling out each number, as in the example above. The total number of tools needed for the process can be defined at the beginning, however, it will change as the application becomes more complex in the future. I plan to address every contingency in the process. The idea is - if the user inputs the initial parameters and the desired outcome (another set of parameters), the app must find the 'best' path - sort of like a decision tree. The best path can be the fastest, cheapest, etc. I would like the user to choose what is best for him/her. Unfortunately, parameters might change, relationships might change (but not regularly) - the 'rules' I will be using might be revised for better accuracy in prediction. I also need to track each user's path and solutions' for future reference (but no personal details except username and email address for logging in). Maybe when the app is up and running, I'd like to make it more democratic, with users contributing to refining the logic/rules involved. If possible, I would also like the app to output a graphical flowchart at the end showing the workflow with all tools grouped in an easy to understand layout. *My questions:* 1. Will the app be better served with a relational DB like mySQL or an Object database? After a lot of research I've guessed that my particular case might be better served with Python and Zope/ZODB. But I might be wrong? Maybe PHP+mySQL or Django is a better fit? 2. Can anyone provide general advice on how to go about beginning such a project in ZOPE. Which is the best place to start learning for a newbie? 3. Can anyone recommend a good shared hosting provider that supports Zope fully but is not expensive? 4. Is there a module or app that is open source that I can use to output a graphical flowchart based on the results, or will I be better served programming it from scratch with Python? I would appreciate any help in getting started. Thank you in advance. I have tried most online forums but have not good any productive answers. Most of the answers I got were pro-PHP+mySQL. Adam ___ 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 ) - -- ZOPYX Limited | zopyx group Charlottenstr. 37/1 | The full-service network for Zope Plone D-72070 Tübingen| Produce Publish www.zopyx.com | www.produce-and-publish.com - E-Publishing, Python, Zope Plone development, Consulting
Re: [Zope] Help in deciding approach to Web App
Thanks Niels. Just to clarify:Does my particular instance fall under an OODBMS model or a RDBMS model (with ORM if necessary)? I will begin by reading the Zope Book. Thanks for your assistance. Appreciate it. -ss Subject: Re: [Zope] Help in deciding approach to Web App From: n...@syndicat.com Date: Sun, 4 Dec 2011 09:24:10 +0100 To: ays...@hotmail.com; zope@zope.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Sareesh Sudhakaran ays...@hotmail.com schrieb: My questions:Will the app be better served with a relational DB like mySQL or an Object database? After a lot of research I've guessed that my particular case might be better served with Python and Zope/ZODB. But I might be wrong? Maybe PHP+mySQL or Django is a better fit?Can anyone provide general advice on how to go about beginning such a project in ZOPE. This hardly depends from your data structure, but with Zope you have the option to use ZODB and SQL DBs like MySQL in parallel. Typical relational data should go into a SQLDB while complex / oo Data structures should go into ZODB. We developed several complex to very complex web based applications - incl. expert systems - on Zope ZODB plus MySQL. I can't believe that someone would be able to solve such issues with PHP/SQL within the same time / ressources. Which is the best place to start learning for a newbie? You should start by trying the short zope practice / excercise as described in the Zope book. The Zope Book should be the best source for getting into Zope step by step from nothing. ß) Can anyone recommend a good shared hosting provider that supports Zope fully but is not expensive? Looking for zope hosting or similiar in google should advice you. Our company - as one of many - offers Zope hosting to. Is there a module or app that is open source that I can use to output a graphical flowchart based on the results, or will I be better served programming it from scratch with Python? There are different modules as i.e. Python Imaging (PIL) and higher level modules. I would appreciate any help in getting started. Thank you in advance. I have tried most online forums but have not good any productive answers. Most of the answers I got were pro-PHP+mySQL. Yes, because the peoples did not know anything other solution usually... cheers, Niels. - -- Niels Dettenbach Syndicat ITInternet http://www.syndicat.com -BEGIN PGP SIGNATURE- Version: APG v1.0.8 iIEEAREIAEEFAk7bLio6HE5pZWxzIERldHRlbmJhY2ggKFN5bmRpY2F0IElUJklu dGVybmV0KSA8bmRAc3luZGljYXQuY29tPgAKCRBU3ERlZRyiDUhlAJ4/XPl3Oet6 XN4UlkQ611FNoWqZCwCfZ1IPVjaLMD32wOlFE9cDnrm6bJQ= =ukyi -END PGP SIGNATURE- ___ 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 12/04/2011 09:52 AM, Sareesh Sudhakaran wrote: Thanks Niels. Just to clarify: Does my particular instance fall under an OODBMS model or a RDBMS model (with ORM if necessary)? Data modelling is a bit of an art and probably you could tackle your problem with any approach. I think the important is for you to figure out which model suits more your personality. No kidding. I would personally start with the RDBMS approach considering only the information you provide. Also, you can easily use zope in combination with a RDBMS. When you read the book, beware that zope has been changing from a through the web approach, to a typical file system based approach, which is a loss, but it seems to be what suits the needs of the zope developers. The approach I use is: zpt page - (one) Python Script - (some) ZSQL Methods - MySQL The zpt defines the layout of the pages, the ZSQL Methods retrieve the data needed and the Python script massages the data to make it suitable for the ZPT page. Or the other way around, from user input in a form to storage in the database. The advantage of the relational approach is that it is a very well understood model and although different people will still come to different models there are sufficient objective guidelines out there (e.g., the normalization rules, and then criteria for when to denormalise) to help you along. Furthermore, there are lots of people in db-related forums that can help you. Also, RDBMS provides you with a standard query language, SQL, which plenty of systems and tools can use. In general, RDBMS gives you the safest approach to keep your data and not loose it when you need to migrate either the front-end or the back-end. This language is very powerful and can avoid you a lot of low level programming. However, plenty of people can not deal well with SQL because it follows a paradigm so different from the classic imperative programming. With SQL, you specify the what, with the other languages you specify the how. The advantage of the what is that you can do a lot of data processing in a few lines of code. The problem with the what is that because you don't know the how of it, you feel you don't have control and you are led to say the language is obscure or unreadable. However, even if you are not comfortable with the what (you have to try to know), you can still rely on an library like SQLAlchemy to keep you a bit in the comfort zone of the how. So instead of learning SQL, you need to learn the API of a specific library. Your choice. I recommend the first by far. The real main issue with Relational is that it is a highly structured data model. It allows you to keep high quality data but if you don't get it right soon enough in the development cycle, some later changes can have a huge impact in the application, requiring rewrites. Furthermore, it works the best when you have many objects with the same properties. If you have many entities all different from each other (the tools in your case, maybe), then maybe a OODBMS might be better. But here, there is no standard language, or standard whatever. Perosnally, I would avoid as much as possible to put data in something like ZODB (I use it merely to store and manage the application). The problem with your specific case is that it does not seem to be a typical case of books and authors, which might be a risk for someone without experience. The issue Tool A might have only three fixed rpms - 100, 200 and 500, but Tool B might have rpms from 20 to 2000, is indeed tricky. I suspect in general the needs of your system will be too specific to be able to rely only on SQL queries. You would need to put a lot of intelligence in the data (really highly structured) and it might become unmanageable or not scalable. I guess you will need to put a lot of intelligence in the Python Script. So, the ZSQL retrieves the relevant tool data and then makes the tool choice. The knowledge of the meaning of the attributes is maintained in programming. I should say I am not totally sure the Python Script is the best approach here, in terms of management facilities. But Python is surely a very good language due to its readability. However, you might need to use External methods or a more typical file-system based Python approach. Or maybe you actually need to create a Domain Specific Language to encode the intelligence needed for your tool selection process. If your python code becomes repetitive, with patterns showing up, then a DSL might be a good approach, but this might be too much engineering for you at this stage. It looks like you are in a typical CIM scenario and I remember handling a similar problem 20 years ago. I vaguely remember at that time to use custom graph structures in C and the the intelligence was coded in Lisp/Scheme. So, there is a big range of solutions to try out :) If you have time, then the simple approach zpt page - (one) Python
Re: [Zope] Help in deciding approach to Web App
Thanks Fernando! I really appreciate the time and effort you have put in answering my query. My personality sides with Python but my hosting provider does not support Django or Zope. 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? Can I just start out with a framework like Symphony instead? In the future I'll have to use either Python or C/C++ for my business logic and math. But the focus now is to get a prototype out, and if I'm doomed to change everything later I might as well start with the easiest and most obvious. Is this a viable starting point compared to what you have suggested? Or am I missing something? -Sareesh Date: Sun, 4 Dec 2011 13:28:36 +0100 From: ferna...@cmartins.nl To: ays...@hotmail.com CC: n...@syndicat.com; zope@zope.org Subject: Re: [Zope] Help in deciding approach to Web App On 12/04/2011 09:52 AM, Sareesh Sudhakaran wrote: Thanks Niels. Just to clarify: Does my particular instance fall under an OODBMS model or a RDBMS model (with ORM if necessary)? Data modelling is a bit of an art and probably you could tackle your problem with any approach. I think the important is for you to figure out which model suits more your personality. No kidding. I would personally start with the RDBMS approach considering only the information you provide. Also, you can easily use zope in combination with a RDBMS. When you read the book, beware that zope has been changing from a through the web approach, to a typical file system based approach, which is a loss, but it seems to be what suits the needs of the zope developers. The approach I use is: zpt page - (one) Python Script - (some) ZSQL Methods - MySQL The zpt defines the layout of the pages, the ZSQL Methods retrieve the data needed and the Python script massages the data to make it suitable for the ZPT page. Or the other way around, from user input in a form to storage in the database. The advantage of the relational approach is that it is a very well understood model and although different people will still come to different models there are sufficient objective guidelines out there (e.g., the normalization rules, and then criteria for when to denormalise) to help you along. Furthermore, there are lots of people in db-related forums that can help you. Also, RDBMS provides you with a standard query language, SQL, which plenty of systems and tools can use. In general, RDBMS gives you the safest approach to keep your data and not loose it when you need to migrate either the front-end or the back-end. This language is very powerful and can avoid you a lot of low level programming. However, plenty of people can not deal well with SQL because it follows a paradigm so different from the classic imperative programming. With SQL, you specify the what, with the other languages you specify the how. The advantage of the what is that you can do a lot of data processing in a few lines of code. The problem with the what is that because you don't know the how of it, you feel you don't have control and you are led to say the language is obscure or unreadable. However, even if you are not comfortable with the what (you have to try to know), you can still rely on an library like SQLAlchemy to keep you a bit in the comfort zone of the how. So instead of learning SQL, you need to learn the API of a specific library. Your choice. I recommend the first by far. The real main issue with Relational is that it is a highly structured data model. It allows you to keep high quality data but if you don't get it right soon enough in the development cycle, some later changes can have a huge impact in the application, requiring rewrites. Furthermore, it works the best when you have many objects with the same properties. If you have many entities all different from each other (the tools in your case, maybe), then maybe a OODBMS might be better. But here, there is no standard language, or standard whatever. Perosnally, I would avoid as much as possible to put data in something like ZODB (I use it merely to store and manage the application). The problem with your specific case is that it does not seem to be a typical case of books and authors, which might be a risk for someone without experience. The issue Tool A might have only three fixed rpms - 100, 200 and 500, but Tool B might have rpms from 20 to 2000, is indeed tricky. I suspect in general the needs of your system will be too specific to be able to rely only on SQL queries. You would need to put a lot of
Re: [Zope] Help in deciding approach to Web App
On 12/04/2011 05:15 PM, Sareesh Sudhakaran wrote: 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? Can I just start out with a framework like Symphony instead? Well, if all you have is PHP + MySQL in your provider, there is no which is better question, is it? You might want to look at http://phptal.org/ a library that provides a templating system similar to ZPT. The advantage is the better separation between presentation and business layers. 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
Aloha, Very briefly, from what you describe, it looks like you are dealing with large numbers of complex objects (your 'tools') that interact with each other - and with some other elements that are going through this workflow process? And a context for the process? ...not sure of that part... 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. Python is one reasonable language option; zope for the web publishing aspect of the project would fit well with that. I haven't worked with other OO languages enough to usefully compare. It also sounds to me like the web publishing is the lesser part of this...? That is, the workflow of interacting tools is the real 'app' here, a process which does not all get shown somehow on a web page...or does it? Or just the outcomes? LAMP platform is so common and cheap that it's all a lot of people know about. It can be used well, and, it is all too easy to make horrible hacks and Frankestein monster apps in PHP/MySQL. Meaning, a highly structured (yet powerful) OO programming language will support you in avoiding that. Also, for development (or just to explore if python+zope might meet your needs) you don't need any hosting, you can install python+zope on your development system and try it out. best wishes... John S. On 12/03/2011 07:12 PM, Sareesh Sudhakaran wrote: I have a personal project - a web application I wanted to develop - but I'm confused on which route to take. I am not under any time constraint. *About the App:* The best I can describe it is as a kind of expert system (but not AI) that needs to find the best workflow for a process, given a set of initial and final parameters. E.g. a 'capsule' of data must pass through many 'tools' or 'environments' to reach a desired output - something like a very complicated car wash. Let's say there are many tools that can be used at various stages in the process. I have estimated there are 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. Some of these tools are linked to each other - e.g if one tool is selected, there are only n tools that can correspond to it for the next step in the process. I also have the problem of 'matching' the tools for analysis. E.g. Tool A might have only three fixed rpms - 100, 200 and 500, but Tool B might have rpms from 20 to 2000. I'm not sure how I can construct a database without spelling out each number, as in the example above. The total number of tools needed for the process can be defined at the beginning, however, it will change as the application becomes more complex in the future. I plan to address every contingency in the process. The idea is - if the user inputs the initial parameters and the desired outcome (another set of parameters), the app must find the 'best' path - sort of like a decision tree. The best path can be the fastest, cheapest, etc. I would like the user to choose what is best for him/her. Unfortunately, parameters might change, relationships might change (but not regularly) - the 'rules' I will be using might be revised for better accuracy in prediction. I also need to track each user's path and solutions' for future reference (but no personal details except username and email address for logging in). Maybe when the app is up and running, I'd like to make it more democratic, with users contributing to refining the logic/rules involved. If possible, I would also like the app to output a graphical flowchart at the end showing the workflow with all tools grouped in an easy to understand layout. *My questions:* 1. Will the app be better served with a relational DB like mySQL or an Object database? After a lot of research I've guessed that my particular case might be better served with Python and Zope/ZODB. But I might be wrong? Maybe PHP+mySQL or Django is a better fit? 2. Can anyone provide general advice on how to go about beginning such a project in ZOPE. Which is the best place to start learning for a newbie? 3. Can anyone recommend a good shared hosting provider that supports Zope fully but is not expensive? 4. Is there a module or app that is open source that I can use to output a graphical flowchart based on the results, or will I be better served programming it from scratch with Python? I would appreciate any help in getting started. Thank you in advance. I have tried most online forums but have not good any productive answers. Most of the answers I got were pro-PHP+mySQL. Adam ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related
Re: [Zope] Help in deciding approach to Web App
Thanks Fernando. I would choose ZOPE or Django and a new provider at the drop of a hat - if someone can confirm if that's the way to go. However, since, there are too many grey areas, it might be better if I stuck to what I have and see how things turn out. Once again, thanks for your support. Appreciate it! - Sareesh Date: Sun, 4 Dec 2011 18:19:25 +0100 From: ferna...@cmartins.nl To: ays...@hotmail.com CC: n...@syndicat.com; zope@zope.org Subject: Re: [Zope] Help in deciding approach to Web App On 12/04/2011 05:15 PM, Sareesh Sudhakaran wrote: 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? Can I just start out with a framework like Symphony instead? Well, if all you have is PHP + MySQL in your provider, there is no which is better question, is it? You might want to look at http://phptal.org/ a library that provides a templating system similar to ZPT. The advantage is the better separation between presentation and business layers. 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
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. 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 )
