Re: [PHP] Web application design considerations - a good reference ?
Tony Marston wrote: If you are building a business application with PHP rather than an ordinary website then I suggest that you use a framework instead of trying to reinvent the wheel (and making a hash of it). The Radicore framework was specifically designed for CRUD applications - it uses forms to perform Create/Read/Update/Delete operations on the database - so it would be a better fit than one which was designed for common-or-garden websites. The heart of any database application is the database design. Get this wrong and you are stuffed from the very start. Once you have used the rules of data normalisation to design your database you simply build it, then import the database into the Radicore data dictionary. Then you export each table to produce a class file for that table. Still in the data dictionary you can build end-user transactions by selecting a database table, a transaction pattern, then pressing the 'generate' button. This will generate the scripts and the screen layouts to access the table, and you can run these scripts through the Radicore menu system. All this without having to write a single line of SQL, HTML or even PHP. The only PHP code you need to write is when you want to alter the default behaviour or implement custom business rules. The Radicore framework comes with a built-in Role Based Access Control (RBAC) system, and Audit Logging system and a Workflow system. It was designed using the Three Tier Architecture and MVC design patterns, so makes maximum use of reusable modules. There is an enormous amount of documentation to be found at http://www.radicore.org as well as a tutorial and some sample applications. Try it and see. -- Tony Marston http://www.tonymarston.net http://www.radicore.org Angus Mann angusm...@pobox.com wrote in message news:e23929c24916447cbef5c45eac9af...@guspc... Hi all. I'm working on a PHP project for my own personal business use. It will handle billing and invoices as well as payments and time management, bookings, appointments and a few more. I may add things like personal messaging between the various users and a customer login to check on the progress of their accounts. It is a big project and will probably take a year or so to complete in my spare time. I have made a couple of starts but I have no experience in creating such large applications and I find I often end up with spaghetti code. I've tried using session variables to keep track of where and what the program is doing but there are so many permuations and combinations I found myself writing endless streams of if's, and's and or's just to figure out what page to display. The code is not the probblem for me...it's the flow and organization of the code. Can anybody point me to a good book or tutorial that lays down the principles and gives some suggestions for integrating the many subroutines of a large application? I want to make the code readable and logical in its flow, and avoid repetition of code segments. Much appreciated. Angus -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php How easy is it to write custom modules that plugin to the Radicore framework? I am always interested in those kinds of aspects of frameworks. I see that you are one of the team members, with a Framework like Radicore I wonder how much support and help from others you will receive especially the community. Anyway worth having a look at. http://www.Elemental.co.za http://www.Elemental.co.za http://www.wapit.co.za http://www.wapit.co.za -- View this message in context: http://www.nabble.com/PHP-problem-tp23825924p23857549.html Sent from the PHP - General mailing list archive at Nabble.com. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Web application design considerations - a good reference ?
I am on the same position, half a year ago I tried to wrote the PHP application (sake of learning) using from scratch approaches. Now I want to have a production application, I am bussy to start over and writting/intergrating everthing using a framework. I think for my case is Joomla... So I think its worth using platforms... GR Muhsin Angus Mann wrote: Hi all. I'm working on a PHP project for my own personal business use. It will handle billing and invoices as well as payments and time management, bookings, appointments and a few more. I may add things like personal messaging between the various users and a customer login to check on the progress of their accounts. It is a big project and will probably take a year or so to complete in my spare time. I have made a couple of starts but I have no experience in creating such large applications and I find I often end up with spaghetti code. I've tried using session variables to keep track of where and what the program is doing but there are so many permuations and combinations I found myself writing endless streams of if's, and's and or's just to figure out what page to display. The code is not the probblem for me...it's the flow and organization of the code. Can anybody point me to a good book or tutorial that lays down the principles and gives some suggestions for integrating the many subroutines of a large application? I want to make the code readable and logical in its flow, and avoid repetition of code segments. Much appreciated. Angus -- Extra details: OSS:Gentoo Linux profile:x86 Hardware:msi geforce 8600GT asus p5k-se location:/home/muhsin language(s):C/C++,VB,VHDL,bash,PHP,SQL,HTML,CSS Typo:40WPM url:http://mambo-tech.net url:http://blog.mambo-tech.net -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Web application design considerations - a good reference ?
hi angus... You're probably going to get a lot of different approaches to this one! as a long term/time developer in a past life.. In my humble opinion, a reasonable approach is to start by laying out the key things that the app has to accomplish, and then to break this down into a list/sublist until you get a comprehensive list of things that your app should do... You can put these items into buckets to help keep track of what you've thought about. Each bucket can then be aligned with a given section of your website as you start to get into the UI/Look-feel of the site. One of the most important/key things you can try to do, is to find someone a few people, who are willing to act as a sounding board for the different aspects/parts of your project. Once you've gotten the list, and a basic UI/Wireframe kind of overview (and you can use word/openoffice/etc.. to create a wireframe) you can then have something that you can kind of look at, kick the tires so to speak of what you're envisioning the app to be. This overall process forces you to really think about what the app should consist of, as well well as how it's going to be put together, how the different sections are going to flow... Once you all of the above, you can focus on the workflow/processes of the app. What happens when the user does X, who gets notified, when the user does Y, that kind of thing... There's a lot more, but this should get you started!!! Good luck! -Original Message- From: Angus Mann [mailto:angusm...@pobox.com] Sent: Monday, June 01, 2009 9:51 PM To: php-general@lists.php.net Subject: [PHP] Web application design considerations - a good reference ? Hi all. I'm working on a PHP project for my own personal business use. It will handle billing and invoices as well as payments and time management, bookings, appointments and a few more. I may add things like personal messaging between the various users and a customer login to check on the progress of their accounts. It is a big project and will probably take a year or so to complete in my spare time. I have made a couple of starts but I have no experience in creating such large applications and I find I often end up with spaghetti code. I've tried using session variables to keep track of where and what the program is doing but there are so many permuations and combinations I found myself writing endless streams of if's, and's and or's just to figure out what page to display. The code is not the probblem for me...it's the flow and organization of the code. Can anybody point me to a good book or tutorial that lays down the principles and gives some suggestions for integrating the many subroutines of a large application? I want to make the code readable and logical in its flow, and avoid repetition of code segments. Much appreciated. Angus -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Web application design considerations - a good reference ?
On Tue, Jun 02, 2009 at 02:50:36PM +1000, Angus Mann wrote: Hi all. I'm working on a PHP project for my own personal business use. It will handle billing and invoices as well as payments and time management, bookings, appointments and a few more. I may add things like personal messaging between the various users and a customer login to check on the progress of their accounts. It is a big project and will probably take a year or so to complete in my spare time. I have made a couple of starts but I have no experience in creating such large applications and I find I often end up with spaghetti code. I've tried using session variables to keep track of where and what the program is doing but there are so many permuations and combinations I found myself writing endless streams of if's, and's and or's just to figure out what page to display. The code is not the probblem for me...it's the flow and organization of the code. Can anybody point me to a good book or tutorial that lays down the principles and gives some suggestions for integrating the many subroutines of a large application? I want to make the code readable and logical in its flow, and avoid repetition of code segments. Other responders have cautioned you to use a framework (my vote is CodeIgniter) to save time. You can do this, but I've done what you're doing, without a framework, and it's not that hard. The first and most important point is to get the database right, as pointed out elsewhere. Think long and hard about this one. Once done, write code to build the database from scratch (I typically call this coldstart code). In general, your screens will involve adding, editing, deleting, searching and listing records from your database. Consider doing an outline of what screens you'll need. Take the various items you deal with, like customers, invoices, jobs, etc., and determine if you want to create add, edit, delete, search and listing screens for each. Put everthing you might need in your outline. You may find, in the process of doing all this, that you need to rethink parts of your database. Think about security, as in passwords, usernames, etc. Put in your outline some screens for logging in and logging out, and add whatever infrastructure you need to your database. One point here: The only time I use session variables is in this area. Otherwise, you shouldn't need them for keeping track of things. Let me expand on that. When you have a form (which is what most of your application will be composed of), it will return all the data you need to process it. You process it, and proceed to a menu or somesuch to tackle the next task. If, for some reason, you need to track data across invocations of screens, you can typically do it with hidden fields in your forms. You'll typically need a template which contains the HTML stuff that needs to fit around your individual screens, and which won't change from screen to screen. Inside that template, you can include a call to whatever view file is needed for that screen. Something like: ?php include($viewfile); ? You can build each screen however you want, but it's really just form work-- a field for name, a field for address, etc. At the bottom, a submit button. Each form will be driven by a controller which sets everything up for the view file. And it will also process the results for the view (once the user hits the submit button). It will hand off results to the model file, which knows all about the database, so the model file (class) can vet and store the data properly. That's the way I've done this, through two iterations of my applications. My internal system handles customers, invoices, payables, statistics, mailing lists, payroll, pricing, a calendar, and several other areas for my business. Others will doubtless argue about how I've done this. There are about as many opinions about how all this should be done as there are developers. I'm just giving you advice on how I've done it. Feel free to ask other questions. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Web application design considerations - a good reference ?
Angus Mann wrote: Hi all. I'm working on a PHP project for my own personal business use. It will handle billing and invoices as well as payments and time management, bookings, appointments and a few more. I may add things like personal messaging between the various users and a customer login to check on the progress of their accounts. It is a big project and will probably take a year or so to complete in my spare time. I have made a couple of starts but I have no experience in creating such large applications and I find I often end up with spaghetti code. I've tried using session variables to keep track of where and what the program is doing but there are so many permuations and combinations I found myself writing endless streams of if's, and's and or's just to figure out what page to display. The code is not the probblem for me...it's the flow and organization of the code. Can anybody point me to a good book or tutorial that lays down the principles and gives some suggestions for integrating the many subroutines of a large application? I want to make the code readable and logical in its flow, and avoid repetition of code segments. Much appreciated. Angus I wrote one from Scratch over many years and I don't know how I would operate my business without it at this point. Some little things I would suggest... if you have multiple relationships over several .dbs.. customers db relating to a invoices db, proposals db, quotes db etc.. make sure to use a global unique ID across all databases.. meaning, every time a new record is created in any of these databases, I grab an I.D. from a function that exists only to create a unique ID. This way you don't run the risk of creating false relationships. Some ideas?.. I probably went over board, but all my invoices, quotes etc. also have a corresponding hard copy (file that is written), other than the database record, which acts as redundancy. The problem with any framework such as Drupal is, though you can avoid reinventing the wheel in some cases, you also build stuff that looks like existing stuff and you have the same known security management as existing stuff, and you are sometimes limited on function... So, I just wanted to add this alternate perspective that it is perfectly doable starting from the ground up. Donovan -- =o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o D. BROOKE EUCA Design Center WebDNA Software Corp. WEB: http://www.euca.us | http://www.webdna.us =o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o WebDNA: [** Square Bracket Utopia **] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Web application design considerations - a good reference ?
On Tuesday 02 June 2009 07:50:36 am Angus Mann wrote: Hi all. I'm working on a PHP project for my own personal business use. It will handle billing and invoices as well as payments and time management, bookings, appointments and a few more. I may add things like personal messaging between the various users and a customer login to check on the progress of their accounts. It is a big project and will probably take a year or so to complete in my spare time. I have made a couple of starts but I have no experience in creating such large applications and I find I often end up with spaghetti code. I've tried using session variables to keep track of where and what the program is doing but there are so many permuations and combinations I found myself writing endless streams of if's, and's and or's just to figure out what page to display. The code is not the probblem for me...it's the flow and organization of the code. Can anybody point me to a good book or tutorial that lays down the principles and gives some suggestions for integrating the many subroutines of a large application? I want to make the code readable and logical in its flow, and avoid repetition of code segments. Much appreciated. Angus Hello, Use CMS/Framework like Drupal or TYPO3 All of them have coding principles. You can follow. Plus they do tons of things. (authentication. this that) Your time may cut 3 months. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Web application design considerations - a good reference?
Paul M Foster pa...@quillandmouse.com wrote in message news:20090602134327.gk14...@quillandmouse.com... On Tue, Jun 02, 2009 at 02:50:36PM +1000, Angus Mann wrote: Hi all. I'm working on a PHP project for my own personal business use. It will handle billing and invoices as well as payments and time management, bookings, appointments and a few more. I may add things like personal messaging between the various users and a customer login to check on the progress of their accounts. It is a big project and will probably take a year or so to complete in my spare time. I have made a couple of starts but I have no experience in creating such large applications and I find I often end up with spaghetti code. I've tried using session variables to keep track of where and what the program is doing but there are so many permuations and combinations I found myself writing endless streams of if's, and's and or's just to figure out what page to display. The code is not the probblem for me...it's the flow and organization of the code. Can anybody point me to a good book or tutorial that lays down the principles and gives some suggestions for integrating the many subroutines of a large application? I want to make the code readable and logical in its flow, and avoid repetition of code segments. Other responders have cautioned you to use a framework (my vote is CodeIgniter) to save time. You can do this, but I've done what you're doing, without a framework, and it's not that hard. The first and most important point is to get the database right, as pointed out elsewhere. Think long and hard about this one. So, so true. Once done, write code to build the database from scratch (I typically call this coldstart code). With the Radicore framework you don't write code to build the database, you build your database then import the schema into the data dictionary and then have the code generated for you. In general, your screens will involve adding, editing, deleting, searching and listing records from your database. Consider doing an outline of what screens you'll need. Take the various items you deal with, like customers, invoices, jobs, etc., and determine if you want to create add, edit, delete, search and listing screens for each. Put everthing you might need in your outline. As a rule of thumb for most tables you will need the same family of forms - list, search, create, read, update and delete - and the Radicore framework has patterns that will generate these for you at the touch of a button. When you want to combine 2 tables in a single form, such as for a selected CUSTOMER show me a list of related INVOICES or for a selected INVOICE show me a list of related INVOICE_LINES then there is a different pattern. Try it, and be anazed at how much code you DON'T have to write. You may find, in the process of doing all this, that you need to rethink parts of your database. Think about security, as in passwords, usernames, etc. Put in your outline some screens for logging in and logging out, These functions are built into Radicore, along with password encryption. You also have the choice of Single or Two Factor Authentication (via a RADIUS or LDAP server) and add whatever infrastructure you need to your database. One point here: The only time I use session variables is in this area. Otherwise, you shouldn't need them for keeping track of things. Let me expand on that. When you have a form (which is what most of your application will be composed of), it will return all the data you need to process it. You process it, and proceed to a menu or somesuch to tackle the next task. If, for some reason, you need to track data across invocations of screens, you can typically do it with hidden fields in your forms. I would advise against this as hidden fields in forms are NOT in fact invisible. The user can see what is there simply by using the browser's View Source button. It is even possible for the user to copy the the form, change the variables and submit it with different data. How much of a security breach could that be? I use session data for everything so that nothing is exposed on the client that does not need to be. You'll typically need a template which contains the HTML stuff that needs to fit around your individual screens, and which won't change from screen to screen. Inside that template, you can include a call to whatever view file is needed for that screen. Something like: ?php include($viewfile); ? You can build each screen however you want, but it's really just form work-- a field for name, a field for address, etc. At the bottom, a submit button. Each form will be driven by a controller which sets everything up for the view file. And it will also process the results for the view (once the user hits the submit button). It will hand off results to the model file, which knows all about the database, so the model file
Re: [PHP] Web application design considerations - a good reference ?
My suggestion to you is probably mosty a rehashing of what a lot of other people have said. I definitely think you should take a good, hard look at some existing solutions (frameworks, cms's, etc.) and decide whether you want to use one or not. In my experience, which is admittedly limited, pre-fabricated frameworks like those mentioned in this thread often have way more functionality than you'll actually need, like putting up a painting with a jackhammer. If you decide not to use one, you'll at the very least get a lot of invaluable experience working with PHP and seeing how things are setup. Maybe you'll directly emulate a code layout and flow structure, maybe you'll take a bit from drupal, and a bit from cake, and a bit from wordpress, or maybe by seeing them, you'll reject their ideas for your own. No matter what you do, it's exposure to someone else's ideas and through that, you can help build your own instead of walking down that same road and falling in the same pitfalls that other people have. I'd also like to second someone's previous suggestion that you not work alone. In my experience, there's pros and cons to every idea and every idea has a sibling - at least one other way of accomplishing the same task. If you surround yourself with good people that know what they're doing and have a good discourse about how to do A, B and C and bounce ideas off of one another, there's a good chance that the ultimate product will be much better than if you had elected to work alone. That's all I've got --Eddie On Tue, Jun 2, 2009 at 9:48 AM, Lists li...@euca.us wrote: Angus Mann wrote: Hi all. I'm working on a PHP project for my own personal business use. It will handle billing and invoices as well as payments and time management, bookings, appointments and a few more. I may add things like personal messaging between the various users and a customer login to check on the progress of their accounts. It is a big project and will probably take a year or so to complete in my spare time. I have made a couple of starts but I have no experience in creating such large applications and I find I often end up with spaghetti code. I've tried using session variables to keep track of where and what the program is doing but there are so many permuations and combinations I found myself writing endless streams of if's, and's and or's just to figure out what page to display. The code is not the probblem for me...it's the flow and organization of the code. Can anybody point me to a good book or tutorial that lays down the principles and gives some suggestions for integrating the many subroutines of a large application? I want to make the code readable and logical in its flow, and avoid repetition of code segments. Much appreciated. Angus I wrote one from Scratch over many years and I don't know how I would operate my business without it at this point. Some little things I would suggest... if you have multiple relationships over several .dbs.. customers db relating to a invoices db, proposals db, quotes db etc.. make sure to use a global unique ID across all databases.. meaning, every time a new record is created in any of these databases, I grab an I.D. from a function that exists only to create a unique ID. This way you don't run the risk of creating false relationships. Some ideas?.. I probably went over board, but all my invoices, quotes etc. also have a corresponding hard copy (file that is written), other than the database record, which acts as redundancy. The problem with any framework such as Drupal is, though you can avoid reinventing the wheel in some cases, you also build stuff that looks like existing stuff and you have the same known security management as existing stuff, and you are sometimes limited on function... So, I just wanted to add this alternate perspective that it is perfectly doable starting from the ground up. Donovan -- =o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o D. BROOKE EUCA Design Center WebDNA Software Corp. WEB: http://www.euca.us | http://www.webdna.us =o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o WebDNA: [** Square Bracket Utopia **] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Web application design considerations - a good reference?
On Tue, Jun 02, 2009 at 03:49:03PM +0100, Tony Marston wrote: Paul M Foster pa...@quillandmouse.com wrote in message news:20090602134327.gk14...@quillandmouse.com... On Tue, Jun 02, 2009 at 02:50:36PM +1000, Angus Mann wrote: snip I would advise against this as hidden fields in forms are NOT in fact invisible. The user can see what is there simply by using the browser's View Source button. It is even possible for the user to copy the the form, change the variables and submit it with different data. How much of a security breach could that be? I use session data for everything so that nothing is exposed on the client that does not need to be. The point of using hidden fields is just to track the state of an application from invocation to invocation. It wouldn't/doesn't matter if the user can see this or not when they view source. Here's an example: an invoicing application. At the first screen, you select a customer. The controller/model brings in their name, invoice terms, method of payment, etc. This is used in the next screen, when I enter the invoice header information, some of which is determined by the results of fetching the customer data. Since this application encompasses about four screens, by the third screen, you're going to want to save and get back some of the data you got from that first screen, without having to query the database again. The simplest way to do this is just to store it in hidden variables along the way. None of this has a big security impact. Hidden variables could be considered the memory of the application. Unless, of course, the data you need to save *is* sensitive. In which case, I agree, use session variables. snip Likewise I have written an entire ERP application using nothing but the Radicore framework and the Data Model Resource Book by Len Silverston. I built the PARTY, PRODUCT, ORDER, SHIPMENTS and INVENTORY databases from the shemas in the book, then used the Radicore data dictionary to generate the basic trasactions. All I had to do then was modify the table classes for the business rules, customise a few screens, and I have my working application. It is being used in real life by an online jewelery company, so it's not just an amateur product. snip Gosh, Tony, I just sounds like you have something to do personally with this Radicore framework. Hmm. grin Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Web application design considerations - a good reference?
Tony Marston wrote: Let me expand on that. When you have a form (which is what most of your application will be composed of), it will return all the data you need to process it. You process it, and proceed to a menu or somesuch to tackle the next task. If, for some reason, you need to track data across invocations of screens, you can typically do it with hidden fields in your forms. I would advise against this as hidden fields in forms are NOT in fact invisible. The user can see what is there simply by using the browser's View Source button. It is even possible for the user to copy the the form, change the variables and submit it with different data. How much of a security breach could that be? I use session data for everything so that nothing is exposed on the client that does not need to be. Hidden fields are good for some things but of course must be validated along with anything else sent by post. I use hidden fields for things where keeping it in session might not be appropriate because the user may have several forms open at same time. But yeah - if session variables will work, then session variables should be used. One place you should use hidden inputs is for a post validation token to prevent CSRF attacks. I wrote a class that I use for that. Some consider it overkill as I use a database for it but it works for me: http://www.clfsrpm.net/csrf/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Web application design considerations - a good reference ?
Do not under any circumstances try to do this from scratch. :-) Use an existing framework like Zend Framework or CakePHP or a CMS/framework hybrid like Drupal or a dedicated app for billing and processing. It will save you months of work, and countless security holes. Even if you don't use it directly, studying a large existing system like that will open your mind to better ways of thinking. I only half-joke when I say that everything I know about PHP I learned from Drupal. :-) On Monday 01 June 2009 11:50:36 pm Angus Mann wrote: Hi all. I'm working on a PHP project for my own personal business use. It will handle billing and invoices as well as payments and time management, bookings, appointments and a few more. I may add things like personal messaging between the various users and a customer login to check on the progress of their accounts. It is a big project and will probably take a year or so to complete in my spare time. I have made a couple of starts but I have no experience in creating such large applications and I find I often end up with spaghetti code. I've tried using session variables to keep track of where and what the program is doing but there are so many permuations and combinations I found myself writing endless streams of if's, and's and or's just to figure out what page to display. The code is not the probblem for me...it's the flow and organization of the code. Can anybody point me to a good book or tutorial that lays down the principles and gives some suggestions for integrating the many subroutines of a large application? I want to make the code readable and logical in its flow, and avoid repetition of code segments. Much appreciated. Angus -- Larry Garfield la...@garfieldtech.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
