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: nd@syndicat.com Date: Sun, 4 Dec 2011 09:24:10 +0100 To: aysand@hotmail.com; zope@zope.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Sareesh Sudhakaran <aysand@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 IT&Internet http://www.syndicat.com -----BEGIN PGP SIGNATURE----- Version: APG v1.0.8
iIEEAREIAEEFAk7bLio6HE5pZWxzIERldHRlbmJhY2ggKFN5bmRpY2F0IElUJklu dGVybmV0KSA8bmRAc3luZGljYXQuY29tPgAKCRBU3ERlZRyiDUhlAJ4/XPl3Oet6 XN4UlkQ611FNoWqZCwCfZ1IPVjaLMD32wOlFE9cDnrm6bJQ= =ukyi -----END PGP SIGNATURE-----
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 Script -> (some) ZSQL Methods -> MySQL database might be a good starting point. You should not need to spend much time to implement a prototype using this approach. In the worse case scenario it helps you understand better your problem and what could be a better approach with little investment. Essentially you try the classical approach and if it does not work well, either you are doing something wrong, or you have a better understanding of your needs and where to go. Good luck, Fernando
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: fernando@cmartins.nl To: aysand@hotmail.com CC: nd@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 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 Script -> (some) ZSQL Methods -> MySQL database might be a good starting point. You should not need to spend much time to implement a prototype using this approach. In the worse case scenario it helps you understand better your problem and what could be a better approach with little investment. Essentially you try the classical approach and if it does not work well, either you are doing something wrong, or you have a better understanding of your needs and where to go. Good luck, Fernando
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
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: fernando@cmartins.nl To: aysand@hotmail.com CC: nd@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
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 IT&Internet http://www.syndicat.com/
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: nd@syndicat.com To: aysand@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 IT&Internet http://www.syndicat.com/
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 IT&Internet http://www.syndicat.com/
On Dec 5, 2011 10:25 "Niels Dettenbach" <nd@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
participants (4)
-
Fernando -
Fernando Martins
-
Niels Dettenbach -
Sareesh Sudhakaran