Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.php > #5471 > unrolled thread
| Started by | Charles <cchamb2@gmail.com> |
|---|---|
| First post | 2012-04-11 20:48 -0700 |
| Last post | 2012-04-13 15:27 +0200 |
| Articles | 20 on this page of 95 — 16 participants |
Back to article view | Back to comp.lang.php
Dynamic form generation Charles <cchamb2@gmail.com> - 2012-04-11 20:48 -0700
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-12 00:03 -0400
Re: Dynamic form generation The Natural Philosopher <tnp@invalid.invalid> - 2012-04-12 05:46 +0100
Re: Dynamic form generation Michael Vilain <vilain@NOspamcop.net> - 2012-04-11 21:52 -0700
Re: Dynamic form generation Denis McMahon <denismfmcmahon@gmail.com> - 2012-04-12 12:42 +0000
Re: Dynamic form generation Charles <cchamb2@gmail.com> - 2012-04-12 20:43 -0700
Re: Dynamic form generation Michael Vilain <vilain@NOspamcop.net> - 2012-04-12 21:55 -0700
Re: Dynamic form generation Denis McMahon <denismfmcmahon@gmail.com> - 2012-04-13 13:19 +0000
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-13 09:59 +0100
Re: Dynamic form generation Denis McMahon <denismfmcmahon@gmail.com> - 2012-04-13 13:22 +0000
Re: Dynamic form generation Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-17 14:49 +0200
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-17 11:36 -0400
Re: Dynamic form generation "Tony Marston" <TonyMarston@hotmail.com> - 2012-04-18 09:33 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-18 07:59 -0400
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-19 09:56 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-19 08:29 -0400
Re: Dynamic form generation "Tony Marston" <TonyMarston@hotmail.com> - 2012-04-20 09:27 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-20 07:47 -0400
Re: Dynamic form generation "Tony Marston" <TonyMarston@hotmail.com> - 2012-04-21 12:22 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-21 10:19 -0400
Re: Dynamic form generation "Tony Marston" <TonyMarston@hotmail.com> - 2012-04-22 11:45 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-22 10:09 -0400
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-24 18:21 +0100
Re: Dynamic form generation Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-24 20:56 +0200
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-25 09:23 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-24 16:20 -0400
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-25 10:04 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-25 08:29 -0400
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-26 12:45 +0100
Re: Dynamic form generation Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-22 19:21 +0200
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-23 13:50 +0100
Re: Dynamic form generation Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-24 11:10 +0200
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-24 17:11 +0100
Re: Dynamic form generation Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-24 18:54 +0200
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-24 18:55 +0100
[OT] Was: Dynamic form generation Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-04-25 13:22 +0200
Re: [OT] Was: Dynamic form generation The Natural Philosopher <tnp@invalid.invalid> - 2012-04-25 12:46 +0100
Re: [OT] Was: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-26 12:51 +0100
Re: [OT] Was: Dynamic form generation Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-04-27 10:26 +0200
[OT] Yes-or-no questions (was: [OT] Was: Dynamic form generation) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-28 07:56 +0200
Re: Dynamic form generation "Peter H. Coffin" <hellsop@ninehells.com> - 2012-04-14 08:53 -0500
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-15 08:33 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-15 08:51 -0400
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-16 09:31 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-16 08:33 -0400
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-16 15:11 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-16 11:18 -0400
Re: Dynamic form generation "Tony Marston" <TonyMarston@hotmail.com> - 2012-04-17 09:18 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-17 06:07 -0400
Re: Dynamic form generation "Tony Marston" <TonyMarston@hotmail.com> - 2012-04-18 09:10 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-18 08:09 -0400
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-19 09:27 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-19 08:41 -0400
Re: Dynamic form generation "Tony Marston" <TonyMarston@hotmail.com> - 2012-04-20 10:10 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-20 08:09 -0400
Re: Dynamic form generation "Tony Marston" <TonyMarston@hotmail.com> - 2012-04-21 10:35 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-21 06:21 -0400
Re: Dynamic form generation "Tony Marston" <TonyMarston@hotmail.com> - 2012-04-22 10:27 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-22 10:43 -0400
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-23 15:23 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-23 12:24 -0400
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-26 17:29 +0100
Re: Dynamic form generation The Natural Philosopher <tnp@invalid.invalid> - 2012-04-23 20:37 +0100
What Jerry Stuckle thinks of PHP programmers "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-23 14:10 +0100
Re: What Jerry Stuckle thinks of PHP programmers Paul Herber <paul@pherber.com> - 2012-04-23 14:22 +0100
Re: What Jerry Stuckle thinks of PHP programmers "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-23 15:27 +0200
Re: What Jerry Stuckle thinks of PHP programmers Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-23 09:33 -0400
Re: What Jerry Stuckle thinks of PHP programmers "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-23 15:26 +0100
Re: What Jerry Stuckle thinks of PHP programmers Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-23 12:25 -0400
Re: What Jerry Stuckle thinks of PHP programmers Luuk <luuk@invalid.lan> - 2012-04-23 19:45 +0200
Re: What Jerry Stuckle thinks of PHP programmers The Natural Philosopher <tnp@invalid.invalid> - 2012-04-23 20:35 +0100
Re: What Jerry Stuckle thinks of PHP programmers Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-24 19:45 +0200
Re: What Jerry Stuckle thinks of PHP programmers "Tony Marston" <TonyMarston@hotmail.com> - 2012-04-28 08:48 +0100
Re: What Jerry Stuckle thinks of PHP programmers The Natural Philosopher <tnp@invalid.invalid> - 2012-04-28 09:23 +0100
Re: What Jerry Stuckle thinks of PHP programmers Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-28 08:37 -0400
Re: What Jerry Stuckle thinks of PHP programmers Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-28 14:46 +0200
Re: What Jerry Stuckle thinks of PHP programmers The Natural Philosopher <tnp@invalid.invalid> - 2012-04-23 20:31 +0100
Re: What Jerry Stuckle thinks of PHP programmers Ross McKay <au.org.zeta.at.rosko@invalid.invalid> - 2012-04-24 12:32 +1000
Re: What Jerry Stuckle thinks of PHP programmers Tim Streater <timstreater@greenbee.net> - 2012-04-24 19:32 +0100
Re: What Jerry Stuckle thinks of PHP programmers Ross McKay <au.org.zeta.at.rosko@invalid.invalid> - 2012-04-25 19:02 +1000
Re: What Jerry Stuckle thinks of PHP programmers The Natural Philosopher <tnp@invalid.invalid> - 2012-04-25 12:20 +0100
Re: Dynamic form generation Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-22 23:59 +0200
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-23 14:05 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-23 09:35 -0400
Re: Dynamic form generation Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-23 15:41 +0200
Re: Dynamic form generation The Natural Philosopher <tnp@invalid.invalid> - 2012-04-23 20:39 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-23 09:47 -0400
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-25 08:52 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-25 08:34 -0400
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-27 09:52 +0100
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-27 14:16 +0100
Re: Dynamic form generation Charles <cchamb2@gmail.com> - 2012-05-03 15:23 -0700
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-12 10:52 +0100
Re: Dynamic form generation Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-04-13 11:39 +0200
Re: Dynamic form generation Jonathan Stein <jstein@image.dk> - 2012-04-13 15:27 +0200
Page 1 of 5 [1] 2 3 4 5 Next page →
| From | Charles <cchamb2@gmail.com> |
|---|---|
| Date | 2012-04-11 20:48 -0700 |
| Subject | Dynamic form generation |
| Message-ID | <7262665.439.1334202496427.JavaMail.geo-discussion-forums@vbgx21> |
I'm working on a database application, and I'd like to write a function that takes the table structure from a MySQL database table and generates a fresh data entry form from it each time someone browses to it. That way I can have four functions that serve the four purposes of data entry, view/query, edit, and delete, instead of 4 scripts for each table (the application has 64 tables so far) that have to be editted every time the table changes. Is it possible to use PHP to generate data entry forms on the fly? Does anyone have any recommendation for a reference resource or some sample code to study for this?
[toc] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-04-12 00:03 -0400 |
| Message-ID | <jm5k72$tss$2@dont-email.me> |
| In reply to | #5471 |
On 4/11/2012 11:48 PM, Charles wrote: > I'm working on a database application, and I'd like to write a function that takes the table structure from a MySQL database table and generates a fresh data entry form from it each time someone browses to it. > > That way I can have four functions that serve the four purposes of data entry, view/query, edit, and delete, instead of 4 scripts for each table (the application has 64 tables so far) that have to be editted every time the table changes. > > Is it possible to use PHP to generate data entry forms on the fly? > > Does anyone have any recommendation for a reference resource or some sample code to study for this? > You can do it. You need to get the table definition, parse it and create the appropriate form. That's what PHPMyAdmin does, for instance. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2012-04-12 05:46 +0100 |
| Message-ID | <jm5mmi$vsc$1@news.albasani.net> |
| In reply to | #5471 |
Charles wrote: > I'm working on a database application, and I'd like to write a function that takes the table structure from a MySQL database table and generates a fresh data entry form from it each time someone browses to it. > > That way I can have four functions that serve the four purposes of data entry, view/query, edit, and delete, instead of 4 scripts for each table (the application has 64 tables so far) that have to be editted every time the table changes. > > Is it possible to use PHP to generate data entry forms on the fly? it certainly is, yes, but a general purpose function is less easy. Because you need to associate e.g. a label for each entry box with a field in each table. And you may want to vary the layout for each presentable form. My way of doing it to start what will probably be a long and acrimonious religious discussion is to write a form library which does basic things like putting and input box with a legend by its size at a given screen location. Plus open and close database functions. And generic stuff goes in there, plus a generic page header that sets up stuff like the overall screen appearance and style sheets and any menu systems that you might have. That code is common to all screens. Then each form is custom written forte tables uit access. In genarl it has these parts. 1/. Set up the page headers and any menu systems by calling a generic initialisation with the page identities as the parameters to pass. Also open the database. 2/. If the form has been called as a result of a submit operation check for that and if so check as to whether (usually) some row ID is set - if it is you can regard that as an update, and parse and valisdate and sanitise the PUT variables before updating the database (or returning some error). 3/. else if its an update but no ID is set assume its new data to be interested. How you arrange to do that depends on how you want the form to work. Insert te data, bick up the last insret id and copy that into your gobal id field. 4/ then draw the screen either with empty data or by reloading the data from the DB using the global record ID variable as the key. Thats what works for me. > > Does anyone have any recommendation for a reference resource or some sample code to study for this? > -- To people who know nothing, anything is possible. To people who know too much, it is a sad fact that they know how little is really possible - and how hard it is to achieve it.
[toc] | [prev] | [next] | [standalone]
| From | Michael Vilain <vilain@NOspamcop.net> |
|---|---|
| Date | 2012-04-11 21:52 -0700 |
| Message-ID | <vilain-8CE047.21522911042012@news.individual.net> |
| In reply to | #5471 |
In article <7262665.439.1334202496427.JavaMail.geo-discussion-forums@vbgx21>, Charles <cchamb2@gmail.com> wrote: > I'm working on a database application, and I'd like to write a function that > takes the table structure from a MySQL database table and generates a fresh > data entry form from it each time someone browses to it. > > That way I can have four functions that serve the four purposes of data > entry, view/query, edit, and delete, instead of 4 scripts for each table (the > application has 64 tables so far) that have to be editted every time the > table changes. > > Is it possible to use PHP to generate data entry forms on the fly? > > Does anyone have any recommendation for a reference resource or some sample > code to study for this? I did this for a site I created to manage the membership database behind it. You'll have to read up on how to use php to access mysql (or whatever database you're using as a backend), display forms, and process them via get or post. It's a little more than can be discussed here. I got a book on building a web site using php but it's most likely hopelessly out of date by now. If you want to do this 'by yourself', then you're going to have to write or reuse various functions to do all this stuff. -- DeeDee, don't press that button! DeeDee! NO! Dee... [I filter all Goggle Groups posts, so any reply may be automatically ignored]
[toc] | [prev] | [next] | [standalone]
| From | Denis McMahon <denismfmcmahon@gmail.com> |
|---|---|
| Date | 2012-04-12 12:42 +0000 |
| Message-ID | <4f86cda7$0$2912$a8266bb1@newsreader.readnews.com> |
| In reply to | #5475 |
On Wed, 11 Apr 2012 21:52:31 -0700, Michael Vilain wrote: > You'll have to read up on how to use php to access mysql (or > whatever database you're using as a backend), display forms, and process > them via get or post. I think he knows that much, what he's asking for is a bit more complex than the very basic "how do I use php and mysql to generate web pages" that you seem to not be answering. What he's talking about, specifically, is code that takes the output of the sql query "describe <tablename>;" or "show columns from <tablename>" and generates forms to enter, update or display the data in that table based on the table structure. i.e. first of all taking the output of the describe <tablename> / show columns from <tablename> query, generating a list of fieldnames and datatypes, and then generating suitable forms / tables etc to display / enter / update those values and insert into / update the tables as appropriate. Rgds Denis McMahon
[toc] | [prev] | [next] | [standalone]
| From | Charles <cchamb2@gmail.com> |
|---|---|
| Date | 2012-04-12 20:43 -0700 |
| Message-ID | <6651622.883.1334288601914.JavaMail.geo-discussion-forums@vbbfj25> |
| In reply to | #5486 |
Absolutely correct. The database has 34 active and 34 historical tables so far, and my guess is that about another dozen or so of each to create. I can visualize the relationships between the tables, and I'm normalizing as I go on table structure, but having to write and maintain somewhere around 150 scripts each and every time I so much as sneeze (add/remove a field or change a field type in any of the 100 tables) is daunting. I'm just as comfortable with calling a script to do crate each form as I need it. Any suggestions? On Thursday, April 12, 2012 5:42:15 AM UTC-7, Denis McMahon wrote: > On Wed, 11 Apr 2012 21:52:31 -0700, Michael Vilain wrote: > > > You'll have to read up on how to use php to access mysql (or > > whatever database you're using as a backend), display forms, and process > > them via get or post. > > I think he knows that much, what he's asking for is a bit more complex > than the very basic "how do I use php and mysql to generate web pages" > that you seem to not be answering. > > What he's talking about, specifically, is code that takes the output of > the sql query "describe <tablename>;" or "show columns from <tablename>" > and generates forms to enter, update or display the data in that table > based on the table structure. > > i.e. first of all taking the output of the describe <tablename> / show > columns from <tablename> query, generating a list of fieldnames and > datatypes, and then generating suitable forms / tables etc to display / > enter / update those values and insert into / update the tables as > appropriate. > > Rgds > > Denis McMahon
[toc] | [prev] | [next] | [standalone]
| From | Michael Vilain <vilain@NOspamcop.net> |
|---|---|
| Date | 2012-04-12 21:55 -0700 |
| Message-ID | <vilain-B24097.21550312042012@news.individual.net> |
| In reply to | #5505 |
In article <6651622.883.1334288601914.JavaMail.geo-discussion-forums@vbbfj25>, Charles <cchamb2@gmail.com> wrote: > Absolutely correct. The database has 34 active and 34 historical tables so > far, and my guess is that about another dozen or so of each to create. > I can visualize the relationships between the tables, and I'm normalizing > as I go on table structure, but having to write and maintain somewhere > around 150 scripts each and every time I so much as sneeze (add/remove a > field or change a field type in any of the 100 tables) is daunting. > > I'm just as comfortable with calling a script to do crate each form as I need > it. > > Any suggestions? > > On Thursday, April 12, 2012 5:42:15 AM UTC-7, Denis McMahon wrote: > > On Wed, 11 Apr 2012 21:52:31 -0700, Michael Vilain wrote: > > > > > You'll have to read up on how to use php to access mysql (or > > > whatever database you're using as a backend), display forms, and process > > > them via get or post. > > > > I think he knows that much, what he's asking for is a bit more complex > > than the very basic "how do I use php and mysql to generate web pages" > > that you seem to not be answering. > > > > What he's talking about, specifically, is code that takes the output of > > the sql query "describe <tablename>;" or "show columns from <tablename>" > > and generates forms to enter, update or display the data in that table > > based on the table structure. > > > > i.e. first of all taking the output of the describe <tablename> / show > > columns from <tablename> query, generating a list of fieldnames and > > datatypes, and then generating suitable forms / tables etc to display / > > enter / update those values and insert into / update the tables as > > appropriate. > > > > Rgds > > > > Denis McMahon I don't know of any php tools that will automatically generate display/modify/delete forms for specific tables if you just give them the table layout. I think you're stuck coding and maintaining each form by hand. I've heard Java does this sort of thing automatically. Seriously. When you change the class in Java, apparently there are libraries that will change the forms automatically. There's no real short cut. If there was, a lot of php developers would be out of work. -- DeeDee, don't press that button! DeeDee! NO! Dee... [I filter all Goggle Groups posts, so any reply may be automatically ignored]
[toc] | [prev] | [next] | [standalone]
| From | Denis McMahon <denismfmcmahon@gmail.com> |
|---|---|
| Date | 2012-04-13 13:19 +0000 |
| Message-ID | <4f8827e4$0$2801$a8266bb1@newsreader.readnews.com> |
| In reply to | #5506 |
On Thu, 12 Apr 2012 21:55:04 -0700, Michael Vilain wrote: > I don't know of any php tools that will automatically generate > display/modify/delete forms for specific tables if you just give them > the table layout. I think you're stuck coding and maintaining each form > by hand. As I think Jerry has already posted, phpmyadmin does this, and the OP could probably, with a bit of searching, lift the code from there. Rgds Denis McMahon
[toc] | [prev] | [next] | [standalone]
| From | "Tony Marston" <tony@NOSPAM.demon.co.uk> |
|---|---|
| Date | 2012-04-13 09:59 +0100 |
| Message-ID | <bWRhr.125797$Js7.110892@fx16.am4> |
| In reply to | #5505 |
"Charles" <cchamb2@gmail.com> wrote in message news:6651622.883.1334288601914.JavaMail.geo-discussion-forums@vbbfj25... > Absolutely correct. The database has 34 active and 34 historical tables > so far, and my guess is that about another dozen or so of each to create. > I can visualize the relationships between the tables, and I'm normalizing > as > I go on table structure, but having to write and maintain somewhere around >150 scripts each and every time I so much as sneeze (add/remove a field or > change a field type in any of the 100 tables) is daunting. > I'm just as comfortable with calling a script to do crate each form as I > need it. > Any suggestions? If you used a proper framework then you wouldn't have to do so much work for a minor database change. If you used radicore all you would have to do is re-import the table's structure into the data dictionary and then export the updated structure to replace the table's structure file. The only time you would need to modify another script would be if you needed to change the screen structure (by modifying a small screen structure file) or a business rule (by modifying that table's class file). A lot of simple changes, such as a field's size, can be achieved with a simple import/export without having to modify any scripts at all. Tony Marston On Thursday, April 12, 2012 5:42:15 AM UTC-7, Denis McMahon wrote: > On Wed, 11 Apr 2012 21:52:31 -0700, Michael Vilain wrote: > > > You'll have to read up on how to use php to access mysql (or > > whatever database you're using as a backend), display forms, and process > > them via get or post. > > I think he knows that much, what he's asking for is a bit more complex > than the very basic "how do I use php and mysql to generate web pages" > that you seem to not be answering. > > What he's talking about, specifically, is code that takes the output of > the sql query "describe <tablename>;" or "show columns from <tablename>" > and generates forms to enter, update or display the data in that table > based on the table structure. > > i.e. first of all taking the output of the describe <tablename> / show > columns from <tablename> query, generating a list of fieldnames and > datatypes, and then generating suitable forms / tables etc to display / > enter / update those values and insert into / update the tables as > appropriate. > > Rgds > > Denis McMahon
[toc] | [prev] | [next] | [standalone]
| From | Denis McMahon <denismfmcmahon@gmail.com> |
|---|---|
| Date | 2012-04-13 13:22 +0000 |
| Message-ID | <4f882879$0$2787$a8266bb1@newsreader.readnews.com> |
| In reply to | #5508 |
On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote: > If you used a proper framework ... ... then you'd have all the junk and baggage that comes along with that framework, including any security flaws in the framework. Not saying that frameworks are inherently bad, but they're not automatically the solution either. Rgds Denis McMahon
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2012-04-17 14:49 +0200 |
| Message-ID | <1977092.XdLjdUsOZY@PointedEars.de> |
| In reply to | #5514 |
Denis McMahon wrote:
> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote:
>> If you used a proper framework ...
>
> ... then you'd have all the junk and baggage that comes along with that
> framework, including any security flaws in the framework.
>
> Not saying that frameworks are inherently bad, but they're not
> automatically the solution either.
TINSTAAFL. If you want complete flexibility of the application as the OP
wants, you have to have an abstraction layer in your application, i.e. it
has to be built on a framework (some people really should reflect on the
term "framework" and its etymology). Abstraction layers come at a price:
Increased overall complexity of the application and decreased efficiency for
tasks that do not require as much flexibility.
Whether that framework was written by you or someone else is another matter.
Chances are that a framework written by someone else has already gained
enough adoption in the global software community that its flaws – including
security flaws – are more quickly detected and fixed than in a framework
that you have written yourself. On the other hand, chances are that a
framework you have written yourself can be better adjusted *by you* to do
what you want than a framework written by someone else, especially if you
created it for the same project in which you are using it.
Inevitably all frameworks become bloated if functionality for flexibility
keeps being added to them. It would appear that there is a point where a
framework author should stop improving it and start something new for a new
project, maybe based on old code (but sometimes a rewrite is less expensive
and turns out to be better). IOW, it is a good idea if you built frameworks
with modularity in mind and use them only *as needed* (not simply for the
sake of using them, like trying to appear cool to the crowd).
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-04-17 11:36 -0400 |
| Message-ID | <jmk2lu$hgn$1@dont-email.me> |
| In reply to | #5553 |
On 4/17/2012 8:49 AM, Thomas 'PointedEars' Lahn wrote: > Denis McMahon wrote: > >> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote: >>> If you used a proper framework ... >> >> ... then you'd have all the junk and baggage that comes along with that >> framework, including any security flaws in the framework. >> >> Not saying that frameworks are inherently bad, but they're not >> automatically the solution either. > > TINSTAAFL. If you want complete flexibility of the application as the OP > wants, you have to have an abstraction layer in your application, i.e. it > has to be built on a framework (some people really should reflect on the > term "framework" and its etymology). Abstraction layers come at a price: > Increased overall complexity of the application and decreased efficiency for > tasks that do not require as much flexibility. > Yup, and when you use a framework you force the application to match the framework, instead of allowing the application to meet the client's needs. It may work - but then it may not, also. > Whether that framework was written by you or someone else is another matter. > Chances are that a framework written by someone else has already gained > enough adoption in the global software community that its flaws – including > security flaws – are more quickly detected and fixed than in a framework > that you have written yourself. On the other hand, chances are that a > framework you have written yourself can be better adjusted *by you* to do > what you want than a framework written by someone else, especially if you > created it for the same project in which you are using it. > So? Good programming practices and test cases will eliminate more security flaws than many of the "frameworks" out there. Have you seen some of the crap code which has been written "by committee"? Not all of it, but a lot of the donations are from people who don't really understand what they're doing - or at least don't write code like they know what they're doing. > Inevitably all frameworks become bloated if functionality for flexibility > keeps being added to them. It would appear that there is a point where a > framework author should stop improving it and start something new for a new > project, maybe based on old code (but sometimes a rewrite is less expensive > and turns out to be better). IOW, it is a good idea if you built frameworks > with modularity in mind and use them only *as needed* (not simply for the > sake of using them, like trying to appear cool to the crowd). > > > PointedEars If a framework attempts to be "all things to all people", then that's quite true. But the same is true of *any* code. However, a limited framework with limited goals doesn't necessarily have to be the case. For instance, in my case - I have a framework which builds PHP classes to interface to a database. It generates a lot of usable code for those classes, including form handling. However, since each class is pretty much independent, I can easily change a class without affecting the rest of the program. I don't have it where it will work with multiple tables yet (something I will do one of these days), but it takes a huge amount of the repetitive work off of me. And no, I don't try to use it for every project. But where a project is database-intensive, it suits my purposes. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | "Tony Marston" <TonyMarston@hotmail.com> |
|---|---|
| Date | 2012-04-18 09:33 +0100 |
| Message-ID | <l%ujr.238053$Js7.15357@fx16.am4> |
| In reply to | #5554 |
"Jerry Stuckle" wrote in message news:jmk2lu$hgn$1@dont-email.me... > >On 4/17/2012 8:49 AM, Thomas 'PointedEars' Lahn wrote: >> Denis McMahon wrote: >> >>> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote: >>>> If you used a proper framework ... >>> >>> ... then you'd have all the junk and baggage that comes along with that >>> framework, including any security flaws in the framework. >>> >>> Not saying that frameworks are inherently bad, but they're not >>> automatically the solution either. >> >> TINSTAAFL. If you want complete flexibility of the application as the OP >> wants, you have to have an abstraction layer in your application, i.e. it >> has to be built on a framework (some people really should reflect on the >> term "framework" and its etymology). Abstraction layers come at a price: >> Increased overall complexity of the application and decreased efficiency >> for >> tasks that do not require as much flexibility. >> > >Yup, and when you use a framework you force the application to match the >framework, instead of allowing the application to meet the client's needs. > >It may work - but then it may not, also. The client's needs are met by screens/reports which have the right layout and which perform the right functions. My framework does not stand in the way of that at all. When user transactions are initially generated they have default screens and default behaviour, but these can be customised to whatever level of sophistication you want. >> Whether that framework was written by you or someone else is another >> matter. >> Chances are that a framework written by someone else has already gained >> enough adoption in the global software community that its flaws – >> including >> security flaws – are more quickly detected and fixed than in a framework >> that you have written yourself. On the other hand, chances are that a >> framework you have written yourself can be better adjusted *by you* to do >> what you want than a framework written by someone else, especially if you >> created it for the same project in which you are using it. >> > >So? Good programming practices and test cases will eliminate more security >flaws than many of the "frameworks" out there. Have you seen some of the >crap code which has been written "by committee"? Not all of it, but a lot >of the donations are from people who don't really understand what they're >doing - or at least don't write code like they know what they're doing. > >> Inevitably all frameworks become bloated if functionality for flexibility >> keeps being added to them. It would appear that there is a point where a >> framework author should stop improving it and start something new for a >> new >> project, maybe based on old code (but sometimes a rewrite is less >> expensive >> and turns out to be better). IOW, it is a good idea if you built >> frameworks >> with modularity in mind and use them only *as needed* (not simply for the >> sake of using them, like trying to appear cool to the crowd). >> >> >> PointedEars > >If a framework attempts to be "all things to all people", then that's quite >true. But the same is true of *any* code. > >However, a limited framework with limited goals doesn't necessarily have to >be the case. > >For instance, in my case - I have a framework which builds PHP classes to >interface to a database. It generates a lot of usable code for those >classes, including form handling. So you framework generates "a lot" of code, does it? My framework generates very small amounts of code which call shared functions or which inherit code from abstract classes. > However, since each class is pretty much independent, I can easily change > a class without affecting the rest of the program. So can I with my framework. >I don't have it where it will work with multiple tables yet (something I >will do one of these days), but it takes a huge amount of the repetitive >work off of me. Removing the need for all this repetitive coding, the "plumbing" as I call it, is exactly what my framework does. >And no, I don't try to use it for every project. But where a project is >database-intensive, it suits my purposes. All my applications are database-intensive, which is why I use a framework which is centred around the database. -- Tony Marston http://www.tonymarston.net http://www.radicore.org
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-04-18 07:59 -0400 |
| Message-ID | <jmmabk$67a$1@dont-email.me> |
| In reply to | #5557 |
On 4/18/2012 4:33 AM, Tony Marston wrote: > "Jerry Stuckle" wrote in message news:jmk2lu$hgn$1@dont-email.me... >> >> On 4/17/2012 8:49 AM, Thomas 'PointedEars' Lahn wrote: >>> Denis McMahon wrote: >>> >>>> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote: >>>>> If you used a proper framework ... >>>> >>>> ... then you'd have all the junk and baggage that comes along with that >>>> framework, including any security flaws in the framework. >>>> >>>> Not saying that frameworks are inherently bad, but they're not >>>> automatically the solution either. >>> >>> TINSTAAFL. If you want complete flexibility of the application as the OP >>> wants, you have to have an abstraction layer in your application, >>> i.e. it >>> has to be built on a framework (some people really should reflect on the >>> term "framework" and its etymology). Abstraction layers come at a price: >>> Increased overall complexity of the application and decreased >>> efficiency for >>> tasks that do not require as much flexibility. >>> >> >> Yup, and when you use a framework you force the application to match >> the framework, instead of allowing the application to meet the >> client's needs. >> >> It may work - but then it may not, also. > > The client's needs are met by screens/reports which have the right > layout and which perform the right functions. My framework does not > stand in the way of that at all. When user transactions are initially > generated they have default screens and default behaviour, but these can > be customised to whatever level of sophistication you want. > The client's needs are met by the APPLICATION. This is much more than the screens and the layouts. But then if all you do are trivial database applications, then I can see where something like that can help. However, your example of over 200 tables and 350 relationships is a perfect example of how bloated such code can become. >>> Whether that framework was written by you or someone else is another >>> matter. >>> Chances are that a framework written by someone else has already gained >>> enough adoption in the global software community that its flaws – >>> including >>> security flaws – are more quickly detected and fixed than in a framework >>> that you have written yourself. On the other hand, chances are that a >>> framework you have written yourself can be better adjusted *by you* >>> to do >>> what you want than a framework written by someone else, especially if >>> you >>> created it for the same project in which you are using it. >>> >> >> So? Good programming practices and test cases will eliminate more >> security flaws than many of the "frameworks" out there. Have you seen >> some of the crap code which has been written "by committee"? Not all >> of it, but a lot of the donations are from people who don't really >> understand what they're doing - or at least don't write code like they >> know what they're doing. >> >>> Inevitably all frameworks become bloated if functionality for >>> flexibility >>> keeps being added to them. It would appear that there is a point where a >>> framework author should stop improving it and start something new for >>> a new >>> project, maybe based on old code (but sometimes a rewrite is less >>> expensive >>> and turns out to be better). IOW, it is a good idea if you built >>> frameworks >>> with modularity in mind and use them only *as needed* (not simply for >>> the >>> sake of using them, like trying to appear cool to the crowd). >>> >>> >>> PointedEars >> >> If a framework attempts to be "all things to all people", then that's >> quite true. But the same is true of *any* code. >> >> However, a limited framework with limited goals doesn't necessarily >> have to be the case. >> >> For instance, in my case - I have a framework which builds PHP classes >> to interface to a database. It generates a lot of usable code for >> those classes, including form handling. > > So you framework generates "a lot" of code, does it? My framework > generates very small amounts of code which call shared functions or > which inherit code from abstract classes. > Yup, for instance, it generates all the set and get methods for the applicable class, as well as database access code (insert/update/delete for single rows and single rows and lists of multiple rows for SELECT). (Most of the access code is in parent classes). It also generates the code necessary to validate a field. Some stock fields (like "must be integer") have predefined validation functions. Others, like passwords where the rules may change, allow the validation to be handled by a regex, function call or similar. It also has the ability to generate forms html to display (read/write or read only). And this is all one function. If I need a different layout for a different page, it's easy to copy/paste a new function and redo the output. It also has a function to populate the object from $_GET or $_POST values (with validation). >> However, since each class is pretty much independent, I can easily >> change a class without affecting the rest of the program. > > So can I with my framework. > >> I don't have it where it will work with multiple tables yet (something >> I will do one of these days), but it takes a huge amount of the >> repetitive work off of me. > > Removing the need for all this repetitive coding, the "plumbing" as I > call it, is exactly what my framework does. > Not if it only generates a tiny bit of code. >> And no, I don't try to use it for every project. But where a project >> is database-intensive, it suits my purposes. > > All my applications are database-intensive, which is why I use a > framework which is centred around the database. > Ah, that explains it, then. Database access is easy (although many people can still screw that up). Most of my applications need to do real work. But I'm also not so stupid as to think that my frameworks is good for everyone. It works for me. But I don't try to foist it off on someone else without telling them it's my framework. That is just plain dishonest. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | "Tony Marston" <tony@NOSPAM.demon.co.uk> |
|---|---|
| Date | 2012-04-19 09:56 +0100 |
| Message-ID | <vrQjr.221592$o93.153449@fx05.am4> |
| In reply to | #5558 |
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message news:jmmabk$67a$1@dont-email.me... > On 4/18/2012 4:33 AM, Tony Marston wrote: >> "Jerry Stuckle" wrote in message news:jmk2lu$hgn$1@dont-email.me... >>> >>> On 4/17/2012 8:49 AM, Thomas 'PointedEars' Lahn wrote: >>>> Denis McMahon wrote: >>>> >>>>> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote: >>>>>> If you used a proper framework ... >>>>> >>>>> ... then you'd have all the junk and baggage that comes along with >>>>> that >>>>> framework, including any security flaws in the framework. >>>>> >>>>> Not saying that frameworks are inherently bad, but they're not >>>>> automatically the solution either. >>>> >>>> TINSTAAFL. If you want complete flexibility of the application as the >>>> OP >>>> wants, you have to have an abstraction layer in your application, >>>> i.e. it >>>> has to be built on a framework (some people really should reflect on >>>> the >>>> term "framework" and its etymology). Abstraction layers come at a >>>> price: >>>> Increased overall complexity of the application and decreased >>>> efficiency for >>>> tasks that do not require as much flexibility. >>>> >>> >>> Yup, and when you use a framework you force the application to match >>> the framework, instead of allowing the application to meet the >>> client's needs. >>> >>> It may work - but then it may not, also. >> >> The client's needs are met by screens/reports which have the right >> layout and which perform the right functions. My framework does not >> stand in the way of that at all. When user transactions are initially >> generated they have default screens and default behaviour, but these can >> be customised to whatever level of sophistication you want. >> > > The client's needs are met by the APPLICATION. This is much more than the > screens and the layouts. But then if all you do are trivial database > applications, then I can see where something like that can help. An application is nothing more than a collection of individual components, where each component does a "unit of work" from the user's point of view. A small application has a small number of components, while a large application has a large number of components. > However, your example of over 200 tables and 350 relationships is a > perfect example of how bloated such code can become. The term "bloat" implies having things which are not used, and I can assure you that every database table has a purpose and is used in one or more transactions. If a database table ever became redundant then I would remove it. My databases are based on the designs in Len Silverston's Data Model Resource book. So far I have implemented the PARTY, PRODUCT, ORDER, INVENTORY, SHIPMENT, INVOICE, REQUEST and WORK-EFFORT databases. If you bother to read his book you wil see that every table serves a purpose. >>>> Whether that framework was written by you or someone else is another >>>> matter. >>>> Chances are that a framework written by someone else has already gained >>>> enough adoption in the global software community that its flaws - >>>> including >>>> security flaws - are more quickly detected and fixed than in a >>>> framework >>>> that you have written yourself. On the other hand, chances are that a >>>> framework you have written yourself can be better adjusted *by you* >>>> to do >>>> what you want than a framework written by someone else, especially if >>>> you >>>> created it for the same project in which you are using it. >>>> >>> >>> So? Good programming practices and test cases will eliminate more >>> security flaws than many of the "frameworks" out there. Have you seen >>> some of the crap code which has been written "by committee"? Not all >>> of it, but a lot of the donations are from people who don't really >>> understand what they're doing - or at least don't write code like they >>> know what they're doing. >>> >>>> Inevitably all frameworks become bloated if functionality for >>>> flexibility >>>> keeps being added to them. It would appear that there is a point where >>>> a >>>> framework author should stop improving it and start something new for >>>> a new >>>> project, maybe based on old code (but sometimes a rewrite is less >>>> expensive >>>> and turns out to be better). IOW, it is a good idea if you built >>>> frameworks >>>> with modularity in mind and use them only *as needed* (not simply for >>>> the >>>> sake of using them, like trying to appear cool to the crowd). >>>> >>>> >>>> PointedEars >>> >>> If a framework attempts to be "all things to all people", then that's >>> quite true. But the same is true of *any* code. >>> >>> However, a limited framework with limited goals doesn't necessarily >>> have to be the case. >>> >>> For instance, in my case - I have a framework which builds PHP classes >>> to interface to a database. It generates a lot of usable code for >>> those classes, including form handling. >> >> So you framework generates "a lot" of code, does it? My framework >> generates very small amounts of code which call shared functions or >> which inherit code from abstract classes. >> > > Yup, for instance, it generates all the set and get methods for the > applicable class, as well as database access code (insert/update/delete > for single rows and single rows and lists of multiple rows for SELECT). > (Most of the access code is in parent classes). My framework does not bother generating set and get methods as they are inefficient. Data goes in and comes out as an array. My framework does not generate any database access code as that is already provided by my Data Access Object (DAO). I have one for MySQL, one for PostgreSQL, one for Oracle and another for SQL Server. I can switch from one to another simply by changing a single line in a config file. > It also generates the code necessary to validate a field. Some stock > fields (like "must be integer") have predefined validation functions. My framework does not generate any code to perform basic field validation as that is performed by a validation class which I wrote years ago. > Others, like passwords where the rules may change, allow the validation > to be handled by a regex, function call or similar. In my framework any password rues - such as minimum length, the number of uppercase characters, the number of lowercase characters, the number of digits - is controlled from a database record. Each customer can therefore change the rules without me having to change any code. > It also has the ability to generate forms html to display (read/write or > read only). And this is all one function. If I need a different layout > for a different page, it's easy to copy/paste a new function and redo the > output. Copy/Paste? That produces duplicate code, not sharable code, and even you should know that duplicate code violates the DRY principle. > It also has a function to populate the object from $_GET or $_POST values > (with validation). I don't need a whole function to do that when a single line will do:- $result = $object->insertRecord($_POST); This means that the same line will work on any object regardless of which class it came from. That is what polymorphism is all about. >>> However, since each class is pretty much independent, I can easily >>> change a class without affecting the rest of the program. >> >> So can I with my framework. >> >>> I don't have it where it will work with multiple tables yet (something >>> I will do one of these days), but it takes a huge amount of the >>> repetitive work off of me. >> >> Removing the need for all this repetitive coding, the "plumbing" as I >> call it, is exactly what my framework does. >> > > Not if it only generates a tiny bit of code. You are missing the point as usual. My framework need only generate a small amount of code as everything else, especially all the standard plumbing, is included from standard pre-written functions. >>> And no, I don't try to use it for every project. But where a project >>> is database-intensive, it suits my purposes. >> >> All my applications are database-intensive, which is why I use a >> framework which is centred around the database. >> > > Ah, that explains it, then. Database access is easy (although many people > can still screw that up). Most of my applications need to do real work. My framework takes care of all the standard database access, and getting data in and out of the screen, plus basic data validation. As for the "real work" as you call - or the "payload" as I call it - that is done by adding whatever code is necessary in the relevant class to implement each business rule. The point is that when using my framework the programmer has to spend little or no time on the standard plumbing, which leaves him with much more time to spend on the payload. > But I'm also not so stupid as to think that my frameworks is good for > everyone. It works for me. But I don't try to foist it off on someone > else without telling them it's my framework. That is just plain > dishonest. I never said that my framework is the perfect solution for everyone. If you a writing a simple website then it's not good, but if you are writing a database application then it's better than most. I was never dishonest about the Radicore framework. I never said it was written by someone else. I even include a link to the radicore website in my signature. If *your* framework is so good, then why don't you release it as open source so that we call all have a laugh? -- Tony Marston http://www.tonymarston.net http://www.radicore.org
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-04-19 08:29 -0400 |
| Message-ID | <jmp0gb$d8$1@dont-email.me> |
| In reply to | #5570 |
On 4/19/2012 4:56 AM, Tony Marston wrote: > "Jerry Stuckle"<jstucklex@attglobal.net> wrote in message > news:jmmabk$67a$1@dont-email.me... >> On 4/18/2012 4:33 AM, Tony Marston wrote: >>> "Jerry Stuckle" wrote in message news:jmk2lu$hgn$1@dont-email.me... >>>> >>>> On 4/17/2012 8:49 AM, Thomas 'PointedEars' Lahn wrote: >>>>> Denis McMahon wrote: >>>>> >>>>>> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote: >>>>>>> If you used a proper framework ... >>>>>> >>>>>> ... then you'd have all the junk and baggage that comes along with >>>>>> that >>>>>> framework, including any security flaws in the framework. >>>>>> >>>>>> Not saying that frameworks are inherently bad, but they're not >>>>>> automatically the solution either. >>>>> >>>>> TINSTAAFL. If you want complete flexibility of the application as the >>>>> OP >>>>> wants, you have to have an abstraction layer in your application, >>>>> i.e. it >>>>> has to be built on a framework (some people really should reflect on >>>>> the >>>>> term "framework" and its etymology). Abstraction layers come at a >>>>> price: >>>>> Increased overall complexity of the application and decreased >>>>> efficiency for >>>>> tasks that do not require as much flexibility. >>>>> >>>> >>>> Yup, and when you use a framework you force the application to match >>>> the framework, instead of allowing the application to meet the >>>> client's needs. >>>> >>>> It may work - but then it may not, also. >>> >>> The client's needs are met by screens/reports which have the right >>> layout and which perform the right functions. My framework does not >>> stand in the way of that at all. When user transactions are initially >>> generated they have default screens and default behaviour, but these can >>> be customised to whatever level of sophistication you want. >>> >> >> The client's needs are met by the APPLICATION. This is much more than the >> screens and the layouts. But then if all you do are trivial database >> applications, then I can see where something like that can help. > > An application is nothing more than a collection of individual components, > where each component does a "unit of work" from the user's point of view. A > small application has a small number of components, while a large > application has a large number of components. > I can understand how someone like you who does such simple stuff things that way. But then you've never worked on something even moderately complex. A large application is much more complex than just having "a large number of components". >> However, your example of over 200 tables and 350 relationships is a >> perfect example of how bloated such code can become. > > The term "bloat" implies having things which are not used, and I can assure > you that every database table has a purpose and is used in one or more > transactions. If a database table ever became redundant then I would remove > it. > Not at all. "Bloat" also refers to applications which are overly large for what needs to be done. > My databases are based on the designs in Len Silverston's Data Model > Resource book. So far I have implemented the PARTY, PRODUCT, ORDER, > INVENTORY, SHIPMENT, INVOICE, REQUEST and WORK-EFFORT databases. If you > bother to read his book you wil see that every table serves a purpose. > Yes, that works fine for simple applications. But then you've already said that's all you do. You've never worked on anything even moderately complex. >>>>> Whether that framework was written by you or someone else is another >>>>> matter. >>>>> Chances are that a framework written by someone else has already gained >>>>> enough adoption in the global software community that its flaws - >>>>> including >>>>> security flaws - are more quickly detected and fixed than in a >>>>> framework >>>>> that you have written yourself. On the other hand, chances are that a >>>>> framework you have written yourself can be better adjusted *by you* >>>>> to do >>>>> what you want than a framework written by someone else, especially if >>>>> you >>>>> created it for the same project in which you are using it. >>>>> >>>> >>>> So? Good programming practices and test cases will eliminate more >>>> security flaws than many of the "frameworks" out there. Have you seen >>>> some of the crap code which has been written "by committee"? Not all >>>> of it, but a lot of the donations are from people who don't really >>>> understand what they're doing - or at least don't write code like they >>>> know what they're doing. >>>> >>>>> Inevitably all frameworks become bloated if functionality for >>>>> flexibility >>>>> keeps being added to them. It would appear that there is a point where >>>>> a >>>>> framework author should stop improving it and start something new for >>>>> a new >>>>> project, maybe based on old code (but sometimes a rewrite is less >>>>> expensive >>>>> and turns out to be better). IOW, it is a good idea if you built >>>>> frameworks >>>>> with modularity in mind and use them only *as needed* (not simply for >>>>> the >>>>> sake of using them, like trying to appear cool to the crowd). >>>>> >>>>> >>>>> PointedEars >>>> >>>> If a framework attempts to be "all things to all people", then that's >>>> quite true. But the same is true of *any* code. >>>> >>>> However, a limited framework with limited goals doesn't necessarily >>>> have to be the case. >>>> >>>> For instance, in my case - I have a framework which builds PHP classes >>>> to interface to a database. It generates a lot of usable code for >>>> those classes, including form handling. >>> >>> So you framework generates "a lot" of code, does it? My framework >>> generates very small amounts of code which call shared functions or >>> which inherit code from abstract classes. >>> >> >> Yup, for instance, it generates all the set and get methods for the >> applicable class, as well as database access code (insert/update/delete >> for single rows and single rows and lists of multiple rows for SELECT). >> (Most of the access code is in parent classes). > > My framework does not bother generating set and get methods as they are > inefficient. Data goes in and comes out as an array. > Yea, that's why your code is crap. You obviously know nothing about proper OO coding techniques. And that means in order to change one item in the object the user has to build an array for the whole thing? Bloat... Bloat... Bloat... > My framework does not generate any database access code as that is already > provided by my Data Access Object (DAO). I have one for MySQL, one for > PostgreSQL, one for Oracle and another for SQL Server. I can switch from one > to another simply by changing a single line in a config file. > Yes, you always waste a lot of time retrieving all columns, whether they are needed or not. And you update all columns, whether you need to or not. Bloatware. >> It also generates the code necessary to validate a field. Some stock >> fields (like "must be integer") have predefined validation functions. > > My framework does not generate any code to perform basic field validation as > that is performed by a validation class which I wrote years ago. > More bloat. And tell me how your class handles a rule such as "8-16 characters, must have both upper and lower case and at least one digit". Or how about the bloat of calling a class to verify the input is an integer when a simple one line statement works. More bloat. >> Others, like passwords where the rules may change, allow the validation >> to be handled by a regex, function call or similar. > > In my framework any password rues - such as minimum length, the number of > uppercase characters, the number of lowercase characters, the number of > digits - is controlled from a database record. Each customer can therefore > change the rules without me having to change any code. > More bloat. And unnecessary. >> It also has the ability to generate forms html to display (read/write or >> read only). And this is all one function. If I need a different layout >> for a different page, it's easy to copy/paste a new function and redo the >> output. > > Copy/Paste? That produces duplicate code, not sharable code, and even you > should know that duplicate code violates the DRY principle. > You obviously don't understand the DRY principle. Just because you copy/paste does not mean it's duplicate code. Once the code has been modified to do something else, it is no longer duplicate. >> It also has a function to populate the object from $_GET or $_POST values >> (with validation). > > I don't need a whole function to do that when a single line will do:- > $result = $object->insertRecord($_POST); > So what is insertRecord($_POST) then, if it's not a function? Once again you show your ignorance. Don't even know what a function is! > This means that the same line will work on any object regardless of which > class it came from. That is what polymorphism is all about. > Nope, that's not at all what polymorphism is about. But you obviously don't understand polymorphism, either. >>>> However, since each class is pretty much independent, I can easily >>>> change a class without affecting the rest of the program. >>> >>> So can I with my framework. >>> >>>> I don't have it where it will work with multiple tables yet (something >>>> I will do one of these days), but it takes a huge amount of the >>>> repetitive work off of me. >>> >>> Removing the need for all this repetitive coding, the "plumbing" as I >>> call it, is exactly what my framework does. >>> >> >> Not if it only generates a tiny bit of code. > > You are missing the point as usual. My framework need only generate a small > amount of code as everything else, especially all the standard plumbing, is > included from standard pre-written functions. > No, I'm missing nothing. But you've clearly shown just how crappy your code is. >>>> And no, I don't try to use it for every project. But where a project >>>> is database-intensive, it suits my purposes. >>> >>> All my applications are database-intensive, which is why I use a >>> framework which is centred around the database. >>> >> >> Ah, that explains it, then. Database access is easy (although many people >> can still screw that up). Most of my applications need to do real work. > > My framework takes care of all the standard database access, and getting > data in and out of the screen, plus basic data validation. As for the "real > work" as you call - or the "payload" as I call it - that is done by adding > whatever code is necessary in the relevant class to implement each business > rule. The point is that when using my framework the programmer has to spend > little or no time on the standard plumbing, which leaves him with much more > time to spend on the payload. > Yup, you've never done any applications which require real work, as you once again have shown. >> But I'm also not so stupid as to think that my frameworks is good for >> everyone. It works for me. But I don't try to foist it off on someone >> else without telling them it's my framework. That is just plain >> dishonest. > > I never said that my framework is the perfect solution for everyone. If you > a writing a simple website then it's not good, but if you are writing a > database application then it's better than most. > Hmmm, you sure seemed to indicate that when you first started pushing this piece of horse hockey. > I was never dishonest about the Radicore framework. I never said it was > written by someone else. I even include a link to the radicore website in my > signature. > And you never said it was written by you, and that you were nowhere near an unbiased user. The fact you are pushing your own product without telling people you have a vested interest is dishonest. The fact you have a link to it in your sig is immaterial - lots of people have links in their sigs to all kinds of things. But then I can see why you don't want to tell people it's your product. I wouldn't want to admit to having created that piece of horse hockey, either. > If *your* framework is so good, then why don't you release it as open source > so that we call all have a laugh? > For a lot of reasons. Mainly because I'm not interested in the hassles of having to support it for a bunch of people who want all kinds of other features. I created it for my projects, and it serves those projects well. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | "Tony Marston" <TonyMarston@hotmail.com> |
|---|---|
| Date | 2012-04-20 09:27 +0100 |
| Message-ID | <O59kr.204502$Hp5.179745@fx12.am4> |
| In reply to | #5573 |
"Jerry Stuckle" wrote in message news:jmp0gb$d8$1@dont-email.me... > >On 4/19/2012 4:56 AM, Tony Marston wrote: >> "Jerry Stuckle"<jstucklex@attglobal.net> wrote in message >> news:jmmabk$67a$1@dont-email.me... >>> On 4/18/2012 4:33 AM, Tony Marston wrote: >>>> "Jerry Stuckle" wrote in message news:jmk2lu$hgn$1@dont-email.me... >>>>> >>>>> On 4/17/2012 8:49 AM, Thomas 'PointedEars' Lahn wrote: >>>>>> Denis McMahon wrote: >>>>>> >>>>>>> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote: >>>>>>>> If you used a proper framework ... >>>>>>> >>>>>>> ... then you'd have all the junk and baggage that comes along with >>>>>>> that >>>>>>> framework, including any security flaws in the framework. >>>>>>> >>>>>>> Not saying that frameworks are inherently bad, but they're not >>>>>>> automatically the solution either. >>>>>> >>>>>> TINSTAAFL. If you want complete flexibility of the application as the >>>>>> OP >>>>>> wants, you have to have an abstraction layer in your application, >>>>>> i.e. it >>>>>> has to be built on a framework (some people really should reflect on >>>>>> the >>>>>> term "framework" and its etymology). Abstraction layers come at a >>>>>> price: >>>>>> Increased overall complexity of the application and decreased >>>>>> efficiency for >>>>>> tasks that do not require as much flexibility. >>>>>> >>>>> >>>>> Yup, and when you use a framework you force the application to match >>>>> the framework, instead of allowing the application to meet the >>>>> client's needs. >>>>> >>>>> It may work - but then it may not, also. >>>> >>>> The client's needs are met by screens/reports which have the right >>>> layout and which perform the right functions. My framework does not >>>> stand in the way of that at all. When user transactions are initially >>>> generated they have default screens and default behaviour, but these >>>> can >>>> be customised to whatever level of sophistication you want. >>>> >>> >>> The client's needs are met by the APPLICATION. This is much more than >>> the >>> screens and the layouts. But then if all you do are trivial database >>> applications, then I can see where something like that can help. >> >> An application is nothing more than a collection of individual >> components, >> where each component does a "unit of work" from the user's point of view. >> A >> small application has a small number of components, while a large >> application has a large number of components. >> > >I can understand how someone like you who does such simple stuff things >that way. But then you've never worked on something even moderately >complex. Building an entire ERP system with 1700 transactions is much more than "simple". I work on business applications for corporations, not toy systems for hobbyists. >A large application is much more complex than just having "a large number >of components". I disagree. An application which uses 200 database tables is more complex than one which uses only 2, and the more tables you have the more maintenance screens you require. >>> However, your example of over 200 tables and 350 relationships is a >>> perfect example of how bloated such code can become. >> >> The term "bloat" implies having things which are not used, and I can >> assure >> you that every database table has a purpose and is used in one or more >> transactions. If a database table ever became redundant then I would >> remove >> it. >> > >Not at all. "Bloat" also refers to applications which are overly large for >what needs to be done. My applications are not overly large. While I have a large number of small transactions each of which does one thing, this is not "bloat", it is following the Single Responsibility Principle. >> My databases are based on the designs in Len Silverston's Data Model >> Resource book. So far I have implemented the PARTY, PRODUCT, ORDER, >> INVENTORY, SHIPMENT, INVOICE, REQUEST and WORK-EFFORT databases. If you >> bother to read his book you wil see that every table serves a purpose. >> > >Yes, that works fine for simple applications. But then you've already said >that's all you do. You've never worked on anything even moderately >complex. I would like to see *YOU* design and build an ERP application basedon those databases and then tell me it's simple! >>>>>> Whether that framework was written by you or someone else is another >>>>>> matter. >>>>>> Chances are that a framework written by someone else has already >>>>>> gained >>>>>> enough adoption in the global software community that its flaws - >>>>>> including >>>>>> security flaws - are more quickly detected and fixed than in a >>>>>> framework >>>>>> that you have written yourself. On the other hand, chances are that a >>>>>> framework you have written yourself can be better adjusted *by you* >>>>>> to do >>>>>> what you want than a framework written by someone else, especially if >>>>>> you >>>>>> created it for the same project in which you are using it. >>>>>> >>>>> >>>>> So? Good programming practices and test cases will eliminate more >>>>> security flaws than many of the "frameworks" out there. Have you seen >>>>> some of the crap code which has been written "by committee"? Not all >>>>> of it, but a lot of the donations are from people who don't really >>>>> understand what they're doing - or at least don't write code like they >>>>> know what they're doing. >>>>> >>>>>> Inevitably all frameworks become bloated if functionality for >>>>>> flexibility >>>>>> keeps being added to them. It would appear that there is a point >>>>>> where >>>>>> a >>>>>> framework author should stop improving it and start something new for >>>>>> a new >>>>>> project, maybe based on old code (but sometimes a rewrite is less >>>>>> expensive >>>>>> and turns out to be better). IOW, it is a good idea if you built >>>>>> frameworks >>>>>> with modularity in mind and use them only *as needed* (not simply for >>>>>> the >>>>>> sake of using them, like trying to appear cool to the crowd). >>>>>> >>>>>> >>>>>> PointedEars >>>>> >>>>> If a framework attempts to be "all things to all people", then that's >>>>> quite true. But the same is true of *any* code. >>>>> >>>>> However, a limited framework with limited goals doesn't necessarily >>>>> have to be the case. >>>>> >>>>> For instance, in my case - I have a framework which builds PHP classes >>>>> to interface to a database. It generates a lot of usable code for >>>>> those classes, including form handling. >>>> >>>> So you framework generates "a lot" of code, does it? My framework >>>> generates very small amounts of code which call shared functions or >>>> which inherit code from abstract classes. >>>> >>> >>> Yup, for instance, it generates all the set and get methods for the >>> applicable class, as well as database access code (insert/update/delete >>> for single rows and single rows and lists of multiple rows for SELECT). >>> (Most of the access code is in parent classes). >> >> My framework does not bother generating set and get methods as they are >> inefficient. Data goes in and comes out as an array. >> > >Yea, that's why your code is crap. You obviously know nothing about proper >OO coding techniques. And that means in order to change one item in the >object the user has to build an array for the whole thing? Bloat... >Bloat... Bloat... You obviously don't know what "proper OO" actually means. And where did I say that in order to change one item in the object the user has to build an array for the whole thing? You are reading things which I did not write. >> My framework does not generate any database access code as that is >> already >> provided by my Data Access Object (DAO). I have one for MySQL, one for >> PostgreSQL, one for Oracle and another for SQL Server. I can switch from >> one >> to another simply by changing a single line in a config file. >> > >Yes, you always waste a lot of time retrieving all columns, whether they >are needed or not. And you update all columns, whether you need to or not. >Bloatware. You are jumping to the wrong conclusion AGAIN! The default is to read all columns simply because by default all columns are displayed on the screen. The defaults can be changed. >>> It also generates the code necessary to validate a field. Some stock >>> fields (like "must be integer") have predefined validation functions. >> >> My framework does not generate any code to perform basic field validation >> as >> that is performed by a validation class which I wrote years ago. >> > >More bloat. And tell me how your class handles a rule such as "8-16 >characters, must have both upper and lower case and at least one digit". Easy peasy. I just set these values in the database: min_length = 8 max_length = 16 upper_case = 1 lower_case = 1 num_digits = 1 >Or how about the bloat of calling a class to verify the input is an integer >when a simple one line statement works. More bloat. I have a validation class which is capable of validating every data type. This means that I do not have to write the line of code which tests that a piece of input is an integer. Not having to write that line is not bloat. >>> Others, like passwords where the rules may change, allow the >>> validation >>> to be handled by a regex, function call or similar. >> >> In my framework any password rues - such as minimum length, the number of >> uppercase characters, the number of lowercase characters, the number of >> digits - is controlled from a database record. Each customer can >> therefore >> change the rules without me having to change any code. >> > >More bloat. And unnecessary. It is necessary if I want to allow the customer to change the password validation rules without having to write any code. Not having to write code is not bloat. >>> It also has the ability to generate forms html to display (read/write or >>> read only). And this is all one function. If I need a different layout >>> for a different page, it's easy to copy/paste a new function and redo >>> the >>> output. >> >> Copy/Paste? That produces duplicate code, not sharable code, and even you >> should know that duplicate code violates the DRY principle. >> > >You obviously don't understand the DRY principle. Just because you >copy/paste does not mean it's duplicate code. Once the code has been >modified to do something else, it is no longer duplicate. If you were really clever you wouldn't have to copy/paste/modify, you would have a reusable module. In my MVC implementation I have a fixed set of controllers, and each controller is reusable. Can you say the same in your framework? >>> It also has a function to populate the object from $_GET or $_POST >>> values >>> (with validation). >> >> I don't need a whole function to do that when a single line will do:- >> $result = $object->insertRecord($_POST); >> > >So what is insertRecord($_POST) then, if it's not a function? Once again >you show your ignorance. Don't even know what a function is! What I'm saying is that I don't have a function which splits the $_POST array into its component parts so I can then use a setter on each component, I simply inject the entire $_POST array in a single operation without the need to split it down into its component parts. >> This means that the same line will work on any object regardless of which >> class it came from. That is what polymorphism is all about. >> > >Nope, that's not at all what polymorphism is about. But you obviously >don't understand polymorphism, either. The definition of polymorphism which I use is "same method, different implementation". What definition do you use? >>>>> However, since each class is pretty much independent, I can easily >>>>> change a class without affecting the rest of the program. >>>> >>>> So can I with my framework. >>>> >>>>> I don't have it where it will work with multiple tables yet (something >>>>> I will do one of these days), but it takes a huge amount of the >>>>> repetitive work off of me. >>>> >>>> Removing the need for all this repetitive coding, the "plumbing" as I >>>> call it, is exactly what my framework does. >>>> >>> >>> Not if it only generates a tiny bit of code. >> >> You are missing the point as usual. My framework need only generate a >> small >> amount of code as everything else, especially all the standard plumbing, >> is >> included from standard pre-written functions. >> > >No, I'm missing nothing. But you've clearly shown just how crappy your >code is. Just because it's different from yours does not make it crap. >>>>> And no, I don't try to use it for every project. But where a project >>>>> is database-intensive, it suits my purposes. >>>> >>>> All my applications are database-intensive, which is why I use a >>>> framework which is centred around the database. >>>> >>> >>> Ah, that explains it, then. Database access is easy (although many >>> people >>> can still screw that up). Most of my applications need to do real work. >> >> My framework takes care of all the standard database access, and getting >> data in and out of the screen, plus basic data validation. As for the >> "real >> work" as you call - or the "payload" as I call it - that is done by >> adding >> whatever code is necessary in the relevant class to implement each >> business >> rule. The point is that when using my framework the programmer has to >> spend >> little or no time on the standard plumbing, which leaves him with much >> more >> time to spend on the payload. >> > >Yup, you've never done any applications which require real work, as you >once again have shown. Then you obviously have not experienced the complicated things which need to be done in an ERP application. >>> But I'm also not so stupid as to think that my frameworks is good for >>> everyone. It works for me. But I don't try to foist it off on someone >>> else without telling them it's my framework. That is just plain >>> dishonest. >> >> I never said that my framework is the perfect solution for everyone. If >> you >> a writing a simple website then it's not good, but if you are writing a >> database application then it's better than most. >> > >Hmmm, you sure seemed to indicate that when you first started pushing this >piece of horse hockey. That may have been the impression that you got, but you have indicated time and time again that your mind works in mysterious ways. >> I was never dishonest about the Radicore framework. I never said it was >> written by someone else. I even include a link to the radicore website in >> my >> signature. >> > >And you never said it was written by you, and that you were nowhere near an >unbiased user. The fact you are pushing your own product without telling >people you have a vested interest is dishonest. The fact you have a link >to it in your sig is immaterial - lots of people have links in their sigs >to all kinds of things. > >But then I can see why you don't want to tell people it's your product. I >wouldn't want to admit to having created that piece of horse hockey, >either. You're the expert in horse hockey judging by the amount you write in these posts. >> If *your* framework is so good, then why don't you release it as open >> source >> so that we call all have a laugh? >> > >For a lot of reasons. Mainly because I'm not interested in the hassles of >having to support it for a bunch of people who want all kinds of other >features. I created it for my projects, and it serves those projects well. What you really mean is that you are too ashamed to have it reviewed by your peers, and that you are incapable of writing code which can be used by others. -- Tony Marston http://www.tonymarston.net http://www.radicore.org
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-04-20 07:47 -0400 |
| Message-ID | <jmrice$n8h$1@dont-email.me> |
| In reply to | #5584 |
On 4/20/2012 4:27 AM, Tony Marston wrote: > "Jerry Stuckle" wrote in message news:jmp0gb$d8$1@dont-email.me... >> >> On 4/19/2012 4:56 AM, Tony Marston wrote: >>> "Jerry Stuckle"<jstucklex@attglobal.net> wrote in message >>> news:jmmabk$67a$1@dont-email.me... >>>> On 4/18/2012 4:33 AM, Tony Marston wrote: >>>>> "Jerry Stuckle" wrote in message news:jmk2lu$hgn$1@dont-email.me... >>>>>> >>>>>> On 4/17/2012 8:49 AM, Thomas 'PointedEars' Lahn wrote: >>>>>>> Denis McMahon wrote: >>>>>>> >>>>>>>> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote: >>>>>>>>> If you used a proper framework ... >>>>>>>> >>>>>>>> ... then you'd have all the junk and baggage that comes along with >>>>>>>> that >>>>>>>> framework, including any security flaws in the framework. >>>>>>>> >>>>>>>> Not saying that frameworks are inherently bad, but they're not >>>>>>>> automatically the solution either. >>>>>>> >>>>>>> TINSTAAFL. If you want complete flexibility of the application as >>>>>>> the >>>>>>> OP >>>>>>> wants, you have to have an abstraction layer in your application, >>>>>>> i.e. it >>>>>>> has to be built on a framework (some people really should reflect on >>>>>>> the >>>>>>> term "framework" and its etymology). Abstraction layers come at a >>>>>>> price: >>>>>>> Increased overall complexity of the application and decreased >>>>>>> efficiency for >>>>>>> tasks that do not require as much flexibility. >>>>>>> >>>>>> >>>>>> Yup, and when you use a framework you force the application to match >>>>>> the framework, instead of allowing the application to meet the >>>>>> client's needs. >>>>>> >>>>>> It may work - but then it may not, also. >>>>> >>>>> The client's needs are met by screens/reports which have the right >>>>> layout and which perform the right functions. My framework does not >>>>> stand in the way of that at all. When user transactions are initially >>>>> generated they have default screens and default behaviour, but >>>>> these can >>>>> be customised to whatever level of sophistication you want. >>>>> >>>> >>>> The client's needs are met by the APPLICATION. This is much more >>>> than the >>>> screens and the layouts. But then if all you do are trivial database >>>> applications, then I can see where something like that can help. >>> >>> An application is nothing more than a collection of individual >>> components, >>> where each component does a "unit of work" from the user's point of >>> view. A >>> small application has a small number of components, while a large >>> application has a large number of components. >>> >> >> I can understand how someone like you who does such simple stuff >> things that way. But then you've never worked on something even >> moderately complex. > > Building an entire ERP system with 1700 transactions is much more than > "simple". I work on business applications for corporations, not toy > systems for hobbyists. > Building a *decent* ERP is complex. SAP, for instance, has a good one. They have several hundred programmers working on it constantly. What you call an "ERP" is nothing like that. >> A large application is much more complex than just having "a large >> number of components". > > I disagree. An application which uses 200 database tables is more > complex than one which uses only 2, and the more tables you have the > more maintenance screens you require. > That's because you've never worked on a complex application. Your claim of an ERP is proof of that. All you do is database stuff. There's nothing complex about that. >>>> However, your example of over 200 tables and 350 relationships is a >>>> perfect example of how bloated such code can become. >>> >>> The term "bloat" implies having things which are not used, and I can >>> assure >>> you that every database table has a purpose and is used in one or more >>> transactions. If a database table ever became redundant then I would >>> remove >>> it. >>> >> >> Not at all. "Bloat" also refers to applications which are overly large >> for what needs to be done. > > My applications are not overly large. While I have a large number of > small transactions each of which does one thing, this is not "bloat", it > is following the Single Responsibility Principle. > > Nope, they aren't, because your applications are just for database access. But they sure sound like they're bloated. >> My databases are based on the designs in Len Silverston's Data Model >>> Resource book. So far I have implemented the PARTY, PRODUCT, ORDER, >>> INVENTORY, SHIPMENT, INVOICE, REQUEST and WORK-EFFORT databases. If you >>> bother to read his book you wil see that every table serves a purpose. >>> >> >> Yes, that works fine for simple applications. But then you've already >> said that's all you do. You've never worked on anything even >> moderately complex. > > I would like to see *YOU* design and build an ERP application basedon > those databases and then tell me it's simple! > I'd like to see YOU create a REAL ERP application! All you did was build database access to multiple tables. ERP is much more than that. >>>>>>> Whether that framework was written by you or someone else is another >>>>>>> matter. >>>>>>> Chances are that a framework written by someone else has already >>>>>>> gained >>>>>>> enough adoption in the global software community that its flaws - >>>>>>> including >>>>>>> security flaws - are more quickly detected and fixed than in a >>>>>>> framework >>>>>>> that you have written yourself. On the other hand, chances are >>>>>>> that a >>>>>>> framework you have written yourself can be better adjusted *by you* >>>>>>> to do >>>>>>> what you want than a framework written by someone else, >>>>>>> especially if >>>>>>> you >>>>>>> created it for the same project in which you are using it. >>>>>>> >>>>>> >>>>>> So? Good programming practices and test cases will eliminate more >>>>>> security flaws than many of the "frameworks" out there. Have you seen >>>>>> some of the crap code which has been written "by committee"? Not all >>>>>> of it, but a lot of the donations are from people who don't really >>>>>> understand what they're doing - or at least don't write code like >>>>>> they >>>>>> know what they're doing. >>>>>> >>>>>>> Inevitably all frameworks become bloated if functionality for >>>>>>> flexibility >>>>>>> keeps being added to them. It would appear that there is a point >>>>>>> where >>>>>>> a >>>>>>> framework author should stop improving it and start something new >>>>>>> for >>>>>>> a new >>>>>>> project, maybe based on old code (but sometimes a rewrite is less >>>>>>> expensive >>>>>>> and turns out to be better). IOW, it is a good idea if you built >>>>>>> frameworks >>>>>>> with modularity in mind and use them only *as needed* (not simply >>>>>>> for >>>>>>> the >>>>>>> sake of using them, like trying to appear cool to the crowd). >>>>>>> >>>>>>> >>>>>>> PointedEars >>>>>> >>>>>> If a framework attempts to be "all things to all people", then that's >>>>>> quite true. But the same is true of *any* code. >>>>>> >>>>>> However, a limited framework with limited goals doesn't necessarily >>>>>> have to be the case. >>>>>> >>>>>> For instance, in my case - I have a framework which builds PHP >>>>>> classes >>>>>> to interface to a database. It generates a lot of usable code for >>>>>> those classes, including form handling. >>>>> >>>>> So you framework generates "a lot" of code, does it? My framework >>>>> generates very small amounts of code which call shared functions or >>>>> which inherit code from abstract classes. >>>>> >>>> >>>> Yup, for instance, it generates all the set and get methods for the >>>> applicable class, as well as database access code (insert/update/delete >>>> for single rows and single rows and lists of multiple rows for SELECT). >>>> (Most of the access code is in parent classes). >>> >>> My framework does not bother generating set and get methods as they are >>> inefficient. Data goes in and comes out as an array. >>> >> >> Yea, that's why your code is crap. You obviously know nothing about >> proper OO coding techniques. And that means in order to change one >> item in the object the user has to build an array for the whole thing? >> Bloat... Bloat... Bloat... > > You obviously don't know what "proper OO" actually means. And where did > I say that in order to change one item in the object the user has to > build an array for the whole thing? You are reading things which I did > not write. > Oh, I sure do. You said you don't have SET/GET functions. You said you set the values with an array. It's exactly what you said. >>> My framework does not generate any database access code as that is >>> already >>> provided by my Data Access Object (DAO). I have one for MySQL, one for >>> PostgreSQL, one for Oracle and another for SQL Server. I can switch >>> from one >>> to another simply by changing a single line in a config file. >>> >> >> Yes, you always waste a lot of time retrieving all columns, whether >> they are needed or not. And you update all columns, whether you need >> to or not. Bloatware. > > You are jumping to the wrong conclusion AGAIN! The default is to read > all columns simply because by default all columns are displayed on the > screen. The defaults can be changed. > Ah, so you have to write code to change those defaults. Once again not what you claimed earlier. >>>> It also generates the code necessary to validate a field. Some stock >>>> fields (like "must be integer") have predefined validation functions. >>> >>> My framework does not generate any code to perform basic field >>> validation as >>> that is performed by a validation class which I wrote years ago. >>> >> >> More bloat. And tell me how your class handles a rule such as "8-16 >> characters, must have both upper and lower case and at least one digit". > > Easy peasy. I just set these values in the database: > min_length = 8 > max_length = 16 > upper_case = 1 > lower_case = 1 > num_digits = 1 > Bloatware. The code has to needlessly query the database, parse the results then apply them to the password, when a regex would do the job simply. Bloat, bloat, bloat. >> Or how about the bloat of calling a class to verify the input is an >> integer when a simple one line statement works. More bloat. > > I have a validation class which is capable of validating every data > type. This means that I do not have to write the line of code which > tests that a piece of input is an integer. Not having to write that line > is not bloat. > Again, bloatware, when a simple function call like intval() will do it. You've added an additional and unnecessary layer of complexity to the application. >>>> Others, like passwords where the rules may change, allow the validation >>>> to be handled by a regex, function call or similar. >>> >>> In my framework any password rues - such as minimum length, the >>> number of >>> uppercase characters, the number of lowercase characters, the number of >>> digits - is controlled from a database record. Each customer can >>> therefore >>> change the rules without me having to change any code. >>> >> >> More bloat. And unnecessary. > > It is necessary if I want to allow the customer to change the password > validation rules without having to write any code. Not having to write > code is not bloat. > More bloat. And unnecessary. How often does the customer want to change the password rules? In about 35 years of programming for clients, I've never had that happen. And what about the existing passwords which don't match the new rules? Why stop with the password? Why not let the customer change the window layout, for instance? Or add tables and columns to the database? Your code is just bloatware and adds an unnecessary layer of complexity to the code. >>>> It also has the ability to generate forms html to display >>>> (read/write or >>>> read only). And this is all one function. If I need a different layout >>>> for a different page, it's easy to copy/paste a new function and >>>> redo the >>>> output. >>> >>> Copy/Paste? That produces duplicate code, not sharable code, and even >>> you >>> should know that duplicate code violates the DRY principle. >>> >> >> You obviously don't understand the DRY principle. Just because you >> copy/paste does not mean it's duplicate code. Once the code has been >> modified to do something else, it is no longer duplicate. > > If you were really clever you wouldn't have to copy/paste/modify, you > would have a reusable module. In my MVC implementation I have a fixed > set of controllers, and each controller is reusable. Can you say the > same in your framework? > Doesn't make any difference. How do you handle displaying the same information two entirely different ways on two different windows? Mine is simple and straightforward. It is also easy to maintain. >>>> It also has a function to populate the object from $_GET or $_POST >>>> values >>>> (with validation). >>> >>> I don't need a whole function to do that when a single line will do:- >>> $result = $object->insertRecord($_POST); >>> >> >> So what is insertRecord($_POST) then, if it's not a function? Once >> again you show your ignorance. Don't even know what a function is! > > What I'm saying is that I don't have a function which splits the $_POST > array into its component parts so I can then use a setter on each > component, I simply inject the entire $_POST array in a single operation > without the need to split it down into its component parts. > So you do have a function which does the work. That's not what you said earlier. I never said I had to split it down into parts, either. I have a member function which handles the input. But I guess that's just too much for you to understand. >>> This means that the same line will work on any object regardless of >>> which >>> class it came from. That is what polymorphism is all about. >>> >> >> Nope, that's not at all what polymorphism is about. But you obviously >> don't understand polymorphism, either. > > The definition of polymorphism which I use is "same method, different > implementation". What definition do you use? > You've got a *partial* definition. Polymorphism is only applicable when the two classes have a parent/child hierarchy, and the child class has a method of the same name (and in some languages, the same parameter list) as the parent. When there is no parent/child relationship (as in the case of two different database tables), there is no polymorphism. >>>>>> However, since each class is pretty much independent, I can easily >>>>>> change a class without affecting the rest of the program. >>>>> >>>>> So can I with my framework. >>>>> >>>>>> I don't have it where it will work with multiple tables yet >>>>>> (something >>>>>> I will do one of these days), but it takes a huge amount of the >>>>>> repetitive work off of me. >>>>> >>>>> Removing the need for all this repetitive coding, the "plumbing" as I >>>>> call it, is exactly what my framework does. >>>>> >>>> >>>> Not if it only generates a tiny bit of code. >>> >>> You are missing the point as usual. My framework need only generate a >>> small >>> amount of code as everything else, especially all the standard >>> plumbing, is >>> included from standard pre-written functions. >>> >> >> No, I'm missing nothing. But you've clearly shown just how crappy your >> code is. > > Just because it's different from yours does not make it crap. > It's not because it's different that it's crap. It's crap because you've shown here it's crap. >>>>>> And no, I don't try to use it for every project. But where a project >>>>>> is database-intensive, it suits my purposes. >>>>> >>>>> All my applications are database-intensive, which is why I use a >>>>> framework which is centred around the database. >>>>> >>>> >>>> Ah, that explains it, then. Database access is easy (although many >>>> people >>>> can still screw that up). Most of my applications need to do real work. >>> >>> My framework takes care of all the standard database access, and getting >>> data in and out of the screen, plus basic data validation. As for the >>> "real >>> work" as you call - or the "payload" as I call it - that is done by >>> adding >>> whatever code is necessary in the relevant class to implement each >>> business >>> rule. The point is that when using my framework the programmer has to >>> spend >>> little or no time on the standard plumbing, which leaves him with >>> much more >>> time to spend on the payload. >>> >> >> Yup, you've never done any applications which require real work, as >> you once again have shown. > > Then you obviously have not experienced the complicated things which > need to be done in an ERP application. > Obviously neither have you. What you have is not a real ERP application. I suspect your customer would do as well with an Excel spreadsheet. And I wonder what your customer would think if he knew you were taking credit for his hard work in building his business. >>>> But I'm also not so stupid as to think that my frameworks is good for >>>> everyone. It works for me. But I don't try to foist it off on someone >>>> else without telling them it's my framework. That is just plain >>>> dishonest. >>> >>> I never said that my framework is the perfect solution for everyone. >>> If you >>> a writing a simple website then it's not good, but if you are writing a >>> database application then it's better than most. >>> >> >> Hmmm, you sure seemed to indicate that when you first started pushing >> this piece of horse hockey. > > That may have been the impression that you got, but you have indicated > time and time again that your mind works in mysterious ways. > Yea, I live in the real world and have real world experience. Unlike you, who seems to live in some alternative universe where you can make up any rules you want and can ignore those you don't like. You can call a simple database application an ERP and take all the credit for your client's hard work. >>> I was never dishonest about the Radicore framework. I never said it was >>> written by someone else. I even include a link to the radicore >>> website in my >>> signature. >>> >> >> And you never said it was written by you, and that you were nowhere >> near an unbiased user. The fact you are pushing your own product >> without telling people you have a vested interest is dishonest. The >> fact you have a link to it in your sig is immaterial - lots of people >> have links in their sigs to all kinds of things. >> >> But then I can see why you don't want to tell people it's your >> product. I wouldn't want to admit to having created that piece of >> horse hockey, either. > > You're the expert in horse hockey judging by the amount you write in > these posts. > Nope, I know how to program properly. You've obviously never worked in a corporate environment, for instance, where you have multiple programmers and have to learn good programming techniques. >>> If *your* framework is so good, then why don't you release it as open >>> source >>> so that we call all have a laugh? >>> >> >> For a lot of reasons. Mainly because I'm not interested in the hassles >> of having to support it for a bunch of people who want all kinds of >> other features. I created it for my projects, and it serves those >> projects well. > > What you really mean is that you are too ashamed to have it reviewed by > your peers, and that you are incapable of writing code which can be used > by others. > Not at all. I meant exactly what I said. Unlike you, I don't need my ego stroked. But my code is reviewed by others quite often. Most projects I work on are collaborative. But then I work with programmers who know what they're doing, also. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | "Tony Marston" <TonyMarston@hotmail.com> |
|---|---|
| Date | 2012-04-21 12:22 +0100 |
| Message-ID | <WLwkr.107545$4z7.10617@fx08.am4> |
| In reply to | #5592 |
"Jerry Stuckle" wrote in message news:jmrice$n8h$1@dont-email.me... > >On 4/20/2012 4:27 AM, Tony Marston wrote: >> "Jerry Stuckle" wrote in message news:jmp0gb$d8$1@dont-email.me... >>> >>> On 4/19/2012 4:56 AM, Tony Marston wrote: >>>> "Jerry Stuckle"<jstucklex@attglobal.net> wrote in message >>>> news:jmmabk$67a$1@dont-email.me... >>>>> On 4/18/2012 4:33 AM, Tony Marston wrote: >>>>>> "Jerry Stuckle" wrote in message news:jmk2lu$hgn$1@dont-email.me... >>>>>>> >>>>>>> On 4/17/2012 8:49 AM, Thomas 'PointedEars' Lahn wrote: >>>>>>>> Denis McMahon wrote: >>>>>>>> >>>>>>>>> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote: >>>>>>>>>> If you used a proper framework ... >>>>>>>>> >>>>>>>>> ... then you'd have all the junk and baggage that comes along with >>>>>>>>> that >>>>>>>>> framework, including any security flaws in the framework. >>>>>>>>> >>>>>>>>> Not saying that frameworks are inherently bad, but they're not >>>>>>>>> automatically the solution either. >>>>>>>> >>>>>>>> TINSTAAFL. If you want complete flexibility of the application as >>>>>>>> the >>>>>>>> OP >>>>>>>> wants, you have to have an abstraction layer in your application, >>>>>>>> i.e. it >>>>>>>> has to be built on a framework (some people really should reflect >>>>>>>> on >>>>>>>> the >>>>>>>> term "framework" and its etymology). Abstraction layers come at a >>>>>>>> price: >>>>>>>> Increased overall complexity of the application and decreased >>>>>>>> efficiency for >>>>>>>> tasks that do not require as much flexibility. >>>>>>>> >>>>>>> >>>>>>> Yup, and when you use a framework you force the application to match >>>>>>> the framework, instead of allowing the application to meet the >>>>>>> client's needs. >>>>>>> >>>>>>> It may work - but then it may not, also. >>>>>> >>>>>> The client's needs are met by screens/reports which have the right >>>>>> layout and which perform the right functions. My framework does not >>>>>> stand in the way of that at all. When user transactions are initially >>>>>> generated they have default screens and default behaviour, but >>>>>> these can >>>>>> be customised to whatever level of sophistication you want. >>>>>> >>>>> >>>>> The client's needs are met by the APPLICATION. This is much more >>>>> than the >>>>> screens and the layouts. But then if all you do are trivial database >>>>> applications, then I can see where something like that can help. >>>> >>>> An application is nothing more than a collection of individual >>>> components, >>>> where each component does a "unit of work" from the user's point of >>>> view. A >>>> small application has a small number of components, while a large >>>> application has a large number of components. >>>> >>> >>> I can understand how someone like you who does such simple stuff >>> things that way. But then you've never worked on something even >>> moderately complex. >> >> Building an entire ERP system with 1700 transactions is much more than >> "simple". I work on business applications for corporations, not toy >> systems for hobbyists. >> > >Building a *decent* ERP is complex. SAP, for instance, has a good one. >They have several hundred programmers working on it constantly. That is because they have made it more complex than it need be, and they are obviously not using a framework which does all the grunt work for them. >What you call an "ERP" is nothing like that. My definition of ERP is the same as that found in wikipedia at http://en.wikipedia.org/wiki/Enterprise_resource_planning. Note that an ERP system need not contain all of those modules, just two or more would be sufficient. >>> A large application is much more complex than just having "a large >>> number of components". >> >> I disagree. An application which uses 200 database tables is more >> complex than one which uses only 2, and the more tables you have the >> more maintenance screens you require. >> > >That's because you've never worked on a complex application. Your claim of >an ERP is proof of that. You obviously don't know what features are available in my ERP system. >All you do is database stuff. There's nothing complex about that. Correct. There is nothing complex about writing code which moves data between the user interface and the database. That is why I developed the Radicore framework, to take care of all that simple "plumbing" stuff for me. My valuable time is spent on writing the code which deals with the business rules, the "payload" as I call it, some of which are more complex than others >>>>> However, your example of over 200 tables and 350 relationships is a >>>>> perfect example of how bloated such code can become. >>>> >>>> The term "bloat" implies having things which are not used, and I can >>>> assure >>>> you that every database table has a purpose and is used in one or more >>>> transactions. If a database table ever became redundant then I would >>>> remove >>>> it. >>>> >>> >>> Not at all. "Bloat" also refers to applications which are overly large >>> for what needs to be done. >> >> My applications are not overly large. While I have a large number of >> small transactions each of which does one thing, this is not "bloat", it >> is following the Single Responsibility Principle. >> >> > >Nope, they aren't, because your applications are just for database access. They are not "just" for basic database access, they are for applying complex business rules as well. The "basic" functionality is provided by the framework while the business rules are provided by the programmer. >But they sure sound like they're bloated. The term "bloat" has nothing to do with the number of database tables. Provided that the database has been properly normalised (you *DO* know what the term "properly normalised" means, don't you?) and every table is used somewhere then there is no "bloat" whatsoever. In my book the term "bloat" is covered by unnecessary code, and I would say that any application which you write which contains 3M LOC has much more bloat than anything which I write. >>> My databases are based on the designs in Len Silverston's Data Model >>>> Resource book. So far I have implemented the PARTY, PRODUCT, ORDER, >>>> INVENTORY, SHIPMENT, INVOICE, REQUEST and WORK-EFFORT databases. If you >>>> bother to read his book you wil see that every table serves a purpose. >>>> >>> >>> Yes, that works fine for simple applications. But then you've already >>> said that's all you do. You've never worked on anything even >>> moderately complex. >> >> I would like to see *YOU* design and build an ERP application basedon >> those databases and then tell me it's simple! >> > >I'd like to see YOU create a REAL ERP application! All you did was build >database access to multiple tables. ERP is much more than that. I know that. It also includes the application of business rules when something changes state. An example would be: "when a sales order is authorised it must be converted into an invoice, a PDF version of that invoice must be created and emailed to the customer. The invoice must also be in the language and currency of the customer." <snip> >>>>>> So you framework generates "a lot" of code, does it? My framework >>>>>> generates very small amounts of code which call shared functions or >>>>>> which inherit code from abstract classes. >>>>>> >>>>> >>>>> Yup, for instance, it generates all the set and get methods for the >>>>> applicable class, as well as database access code >>>>> (insert/update/delete >>>>> for single rows and single rows and lists of multiple rows for >>>>> SELECT). >>>>> (Most of the access code is in parent classes). >>>> >>>> My framework does not bother generating set and get methods as they are >>>> inefficient. Data goes in and comes out as an array. >>>> >>> >>> Yea, that's why your code is crap. You obviously know nothing about >>> proper OO coding techniques. And that means in order to change one >>> item in the object the user has to build an array for the whole thing? >>> Bloat... Bloat... Bloat... >> >> You obviously don't know what "proper OO" actually means. And where did >> I say that in order to change one item in the object the user has to >> build an array for the whole thing? You are reading things which I did >> not write. >> > >Oh, I sure do. You said you don't have SET/GET functions. You said you >set the values with an array. It's exactly what you said. But I don't have to insert any code to create that array as it is already provided for me in the form of $_GET or $_POST. When data comes in from the database it appears as a single variable which is an array of rows and columns. >>>> My framework does not generate any database access code as that is >>>> already >>>> provided by my Data Access Object (DAO). I have one for MySQL, one for >>>> PostgreSQL, one for Oracle and another for SQL Server. I can switch >>>> from one >>>> to another simply by changing a single line in a config file. >>>> >>> >>> Yes, you always waste a lot of time retrieving all columns, whether >>> they are needed or not. And you update all columns, whether you need >>> to or not. Bloatware. >> >> You are jumping to the wrong conclusion AGAIN! The default is to read >> all columns simply because by default all columns are displayed on the >> screen. The defaults can be changed. >> > >Ah, so you have to write code to change those defaults. Once again not >what you claimed earlier. Any person with more than two brain cells to rub together knows that if the default behaviour is not what you want then you have to write code to change those defaults. I have never claimed otherwise. My framework generates working transactions based on a lot of default behaviour, and in a lot of cases the default behaviour is good enough. When it isn't you can change it. >>>>> It also generates the code necessary to validate a field. Some stock >>>>> fields (like "must be integer") have predefined validation functions. >>>> >>>> My framework does not generate any code to perform basic field >>>> validation as >>>> that is performed by a validation class which I wrote years ago. >>>> >>> >>> More bloat. And tell me how your class handles a rule such as "8-16 >>> characters, must have both upper and lower case and at least one digit". >> >> Easy peasy. I just set these values in the database: >> min_length = 8 >> max_length = 16 >> upper_case = 1 >> lower_case = 1 >> num_digits = 1 >> > >Bloatware. The code has to needlessly query the database, parse the >results then apply them to the password, when a regex would do the job >simply. But where do you store the regex? In thin air? Different customers have different rules, so each customer can specify the rules that they want on their copy of the database. That is not bloat, it is sensible design. >Bloat, bloat, bloat. > > >>> Or how about the bloat of calling a class to verify the input is an >>> integer when a simple one line statement works. More bloat. >> >> I have a validation class which is capable of validating every data >> type. This means that I do not have to write the line of code which >> tests that a piece of input is an integer. Not having to write that line >> is not bloat. >> > >Again, bloatware, when a simple function call like intval() will do it. >You've added an additional and unnecessary layer of complexity to the >application. You are missing the point AGAIN. In your applications you have to write code to call the intval() function. In my applications I don't have to write any validation code because I wrote a general purpose validation class many years ago, and it deals with that level of validation automatically. Again you are writing code to do something which my framework does automatically. And you have the nerve to say that my methods are crap! >>>>> Others, like passwords where the rules may change, allow the >>>>> validation >>>>> to be handled by a regex, function call or similar. >>>> >>>> In my framework any password rues - such as minimum length, the >>>> number of >>>> uppercase characters, the number of lowercase characters, the number of >>>> digits - is controlled from a database record. Each customer can >>>> therefore >>>> change the rules without me having to change any code. >>>> >>> >>> More bloat. And unnecessary. >> >> It is necessary if I want to allow the customer to change the password >> validation rules without having to write any code. Not having to write >> code is not bloat. >> > >More bloat. And unnecessary. How often does the customer want to change >the password rules? In about 35 years of programming for clients, I've >never had that happen. And what about the existing passwords which don't >match the new rules? A customer may or may not want to change the rules after the software has been installed, but as my software is used by many different customers each one may want a different set of rules when it is first installed. I can apply whatever rules a customer wants simply by changing his copy of the database, and NOT by changing any code. >Why stop with the password? Why not let the customer change the window >layout, for instance? Or add tables and columns to the database? Now you're going off at a tangent. I should quit while you're behind. >Your code is just bloatware and adds an unnecessary layer of complexity to >the code. > >>>>> It also has the ability to generate forms html to display >>>>> (read/write or >>>>> read only). And this is all one function. If I need a different layout >>>>> for a different page, it's easy to copy/paste a new function and >>>>> redo the >>>>> output. >>>> >>>> Copy/Paste? That produces duplicate code, not sharable code, and even >>>> you >>>> should know that duplicate code violates the DRY principle. >>>> >>> >>> You obviously don't understand the DRY principle. Just because you >>> copy/paste does not mean it's duplicate code. Once the code has been >>> modified to do something else, it is no longer duplicate. >> >> If you were really clever you wouldn't have to copy/paste/modify, you >> would have a reusable module. In my MVC implementation I have a fixed >> set of controllers, and each controller is reusable. Can you say the >> same in your framework? >> > >Doesn't make any difference. How do you handle displaying the same >information two entirely different ways on two different windows? Mine is >simple and straightforward. It is also easy to maintain. So is mine. >>>>> It also has a function to populate the object from $_GET or $_POST >>>>> values >>>>> (with validation). >>>> >>>> I don't need a whole function to do that when a single line will do:- >>>> $result = $object->insertRecord($_POST); >>>> >>> >>> So what is insertRecord($_POST) then, if it's not a function? Once >>> again you show your ignorance. Don't even know what a function is! >> >> What I'm saying is that I don't have a function which splits the $_POST >> array into its component parts so I can then use a setter on each >> component, I simply inject the entire $_POST array in a single operation >> without the need to split it down into its component parts. >> > >So you do have a function which does the work. That's not what you said >earlier. Read what I wrote. I do *NOT* have any function which splits the input array, be it the $_GET array, the $_POST array, or whatever, into its component parts. All database data exists in the database table object as an array of rows and columns. >I never said I had to split it down into parts, either. I have a member >function which handles the input. But I guess that's just too much for you >to understand. I beg to differ. You specifically wrote that you have getters and setters for each individual column/field. I do not have code which splits an array into its component parts as I can access any component part while it is still sitting in the array. >>>> This means that the same line will work on any object regardless of >>>> which >>>> class it came from. That is what polymorphism is all about. >>>> >>> >>> Nope, that's not at all what polymorphism is about. But you obviously >>> don't understand polymorphism, either. >> >> The definition of polymorphism which I use is "same method, different >> implementation". What definition do you use? >> > >You've got a *partial* definition. Polymorphism is only applicable when >the two classes have a parent/child hierarchy, and the child class has a >method of the same name (and in some languages, the same parameter list) as >the parent. The definition of polymorphism does NOT state that the classes have to exist in a parent/child hierarchy, only that they have the same method signature. Having said that, it is usually the case that the two classes ARE related. >When there is no parent/child relationship (as in the case of two different >database tables), there is no polymorphism. Then you obviously haven't used an abstract table class which is inherited by every concrete table class. All my concrete table classes have instant access to all the methods and properties which are defined just once in the abstract class. >>>>>>> However, since each class is pretty much independent, I can easily >>>>>>> change a class without affecting the rest of the program. >>>>>> >>>>>> So can I with my framework. >>>>>> >>>>>>> I don't have it where it will work with multiple tables yet >>>>>>> (something >>>>>>> I will do one of these days), but it takes a huge amount of the >>>>>>> repetitive work off of me. >>>>>> >>>>>> Removing the need for all this repetitive coding, the "plumbing" as I >>>>>> call it, is exactly what my framework does. >>>>>> >>>>> >>>>> Not if it only generates a tiny bit of code. >>>> >>>> You are missing the point as usual. My framework need only generate a >>>> small >>>> amount of code as everything else, especially all the standard >>>> plumbing, is >>>> included from standard pre-written functions. >>>> >>> >>> No, I'm missing nothing. But you've clearly shown just how crappy your >>> code is. >> >> Just because it's different from yours does not make it crap. >> > >It's not because it's different that it's crap. It's crap because you've >shown here it's crap. Only in your tiny mind. >>>>>>> And no, I don't try to use it for every project. But where a project >>>>>>> is database-intensive, it suits my purposes. >>>>>> >>>>>> All my applications are database-intensive, which is why I use a >>>>>> framework which is centred around the database. >>>>>> >>>>> >>>>> Ah, that explains it, then. Database access is easy (although many >>>>> people >>>>> can still screw that up). Most of my applications need to do real >>>>> work. >>>> >>>> My framework takes care of all the standard database access, and >>>> getting >>>> data in and out of the screen, plus basic data validation. As for the >>>> "real >>>> work" as you call - or the "payload" as I call it - that is done by >>>> adding >>>> whatever code is necessary in the relevant class to implement each >>>> business >>>> rule. The point is that when using my framework the programmer has to >>>> spend >>>> little or no time on the standard plumbing, which leaves him with >>>> much more >>>> time to spend on the payload. >>>> >>> >>> Yup, you've never done any applications which require real work, as >>> you once again have shown. >> >> Then you obviously have not experienced the complicated things which >> need to be done in an ERP application. >> > >Obviously neither have you. What you have is not a real ERP application. I >suspect your customer would do as well with an Excel spreadsheet. It is real enough for my paying customers, and it is THEIR opinion that counts, not yours. >And I wonder what your customer would think if he knew you were taking >credit for his hard work in building his business. The comment that my software helped that particular customer in that way was actually made by one of the directors of that company. >>>>> But I'm also not so stupid as to think that my frameworks is good for >>>>> everyone. It works for me. But I don't try to foist it off on someone >>>>> else without telling them it's my framework. That is just plain >>>>> dishonest. >>>> >>>> I never said that my framework is the perfect solution for everyone. >>>> If you >>>> a writing a simple website then it's not good, but if you are writing a >>>> database application then it's better than most. >>>> >>> >>> Hmmm, you sure seemed to indicate that when you first started pushing >>> this piece of horse hockey. >> >> That may have been the impression that you got, but you have indicated >> time and time again that your mind works in mysterious ways. >> > >Yea, I live in the real world and have real world experience. Unlike you, >who seems to live in some alternative universe where you can make up any >rules you want and can ignore those you don't like. You can call a simple >database application an ERP and take all the credit for your client's hard >work. It is much more than a simple database application which does nothing more than move data between the user interface and the database. It processes a large number of business rules, and it is the number and complexity of these business rules which decides whether an application is actually complex or not. >>>> I was never dishonest about the Radicore framework. I never said it was >>>> written by someone else. I even include a link to the radicore >>>> website in my >>>> signature. >>>> >>> >>> And you never said it was written by you, and that you were nowhere >>> near an unbiased user. The fact you are pushing your own product >>> without telling people you have a vested interest is dishonest. The >>> fact you have a link to it in your sig is immaterial - lots of people >>> have links in their sigs to all kinds of things. >>> >>> But then I can see why you don't want to tell people it's your >>> product. I wouldn't want to admit to having created that piece of >>> horse hockey, either. >> >> You're the expert in horse hockey judging by the amount you write in >> these posts. >> > >Nope, I know how to program properly. You've obviously never worked in a >corporate environment, for instance, where you have multiple programmers >and have to learn good programming techniques. I worked in several software houses for many years, and I dealt with many different projects for many different customers. I was also project leader on a good number of those projects. I also wrote the framework used in one of those software houses as well as setting the development standards. >>>> If *your* framework is so good, then why don't you release it as open >>>> source >>>> so that we call all have a laugh? >>>> >>> >>> For a lot of reasons. Mainly because I'm not interested in the hassles >>> of having to support it for a bunch of people who want all kinds of >>> other features. I created it for my projects, and it serves those >>> projects well. >> >> What you really mean is that you are too ashamed to have it reviewed by >> your peers, and that you are incapable of writing code which can be used >> by others. >> > >Not at all. I meant exactly what I said. Yes, you can't be bothered to release it as it is only useful for your own personal toy projects. >Unlike you, I don't need my ego stroked. That's not the impression I get from reading your comments in this post. You seem to think that YOUR way is the ONLY way, and anybody who dares to disagree with you is a stupid moron. I disagree with everything you say, and as for being a moron, 99% of the emails which I receive on the subject on my work are nothing but complimentary. >But my code is reviewed by others quite often. Most projects I work on are >collaborative. But then I work with programmers who know what they're >doing, also. I'd hate to on a team of programmers who all think like you as they would all be unproductive and full of silly ideas. -- Tony Marston http://www.tonymarston.net http://www.radicore.org
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-04-21 10:19 -0400 |
| Message-ID | <jmufmh$peq$1@dont-email.me> |
| In reply to | #5625 |
On 4/21/2012 7:22 AM, Tony Marston wrote: > "Jerry Stuckle" wrote in message news:jmrice$n8h$1@dont-email.me... >> >> On 4/20/2012 4:27 AM, Tony Marston wrote: >>> "Jerry Stuckle" wrote in message news:jmp0gb$d8$1@dont-email.me... >>>> >>>> On 4/19/2012 4:56 AM, Tony Marston wrote: >>>>> "Jerry Stuckle"<jstucklex@attglobal.net> wrote in message >>>>> news:jmmabk$67a$1@dont-email.me... >>>>>> On 4/18/2012 4:33 AM, Tony Marston wrote: >>>>>>> "Jerry Stuckle" wrote in message news:jmk2lu$hgn$1@dont-email.me... >>>>>>>> >>>>>>>> On 4/17/2012 8:49 AM, Thomas 'PointedEars' Lahn wrote: >>>>>>>>> Denis McMahon wrote: >>>>>>>>> >>>>>>>>>> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote: >>>>>>>>>>> If you used a proper framework ... >>>>>>>>>> >>>>>>>>>> ... then you'd have all the junk and baggage that comes along >>>>>>>>>> with >>>>>>>>>> that >>>>>>>>>> framework, including any security flaws in the framework. >>>>>>>>>> >>>>>>>>>> Not saying that frameworks are inherently bad, but they're not >>>>>>>>>> automatically the solution either. >>>>>>>>> >>>>>>>>> TINSTAAFL. If you want complete flexibility of the application as >>>>>>>>> the >>>>>>>>> OP >>>>>>>>> wants, you have to have an abstraction layer in your application, >>>>>>>>> i.e. it >>>>>>>>> has to be built on a framework (some people really should >>>>>>>>> reflect on >>>>>>>>> the >>>>>>>>> term "framework" and its etymology). Abstraction layers come at a >>>>>>>>> price: >>>>>>>>> Increased overall complexity of the application and decreased >>>>>>>>> efficiency for >>>>>>>>> tasks that do not require as much flexibility. >>>>>>>>> >>>>>>>> >>>>>>>> Yup, and when you use a framework you force the application to >>>>>>>> match >>>>>>>> the framework, instead of allowing the application to meet the >>>>>>>> client's needs. >>>>>>>> >>>>>>>> It may work - but then it may not, also. >>>>>>> >>>>>>> The client's needs are met by screens/reports which have the right >>>>>>> layout and which perform the right functions. My framework does not >>>>>>> stand in the way of that at all. When user transactions are >>>>>>> initially >>>>>>> generated they have default screens and default behaviour, but >>>>>>> these can >>>>>>> be customised to whatever level of sophistication you want. >>>>>>> >>>>>> >>>>>> The client's needs are met by the APPLICATION. This is much more >>>>>> than the >>>>>> screens and the layouts. But then if all you do are trivial database >>>>>> applications, then I can see where something like that can help. >>>>> >>>>> An application is nothing more than a collection of individual >>>>> components, >>>>> where each component does a "unit of work" from the user's point of >>>>> view. A >>>>> small application has a small number of components, while a large >>>>> application has a large number of components. >>>>> >>>> >>>> I can understand how someone like you who does such simple stuff >>>> things that way. But then you've never worked on something even >>>> moderately complex. >>> >>> Building an entire ERP system with 1700 transactions is much more than >>> "simple". I work on business applications for corporations, not toy >>> systems for hobbyists. >>> >> >> Building a *decent* ERP is complex. SAP, for instance, has a good one. >> They have several hundred programmers working on it constantly. > > That is because they have made it more complex than it need be, and they > are obviously not using a framework which does all the grunt work for them. > No, that's because they build an ERP, not an order entry/tracking system and call it an ERP. >> What you call an "ERP" is nothing like that. > > My definition of ERP is the same as that found in wikipedia at > http://en.wikipedia.org/wiki/Enterprise_resource_planning. > No, you're is nothing like that. > Note that an ERP system need not contain all of those modules, just two > or more would be sufficient. > Yours doesn't even contain that. "Mr. Editor, here's my novel for publication. It's only 3 pages long because my readers have a short attention span. But I'm calling it a novel anyway". Calling an order entry/tracking system an ERP doesn't make it an ERP. >>>> A large application is much more complex than just having "a large >>>> number of components". >>> >>> I disagree. An application which uses 200 database tables is more >>> complex than one which uses only 2, and the more tables you have the >>> more maintenance screens you require. >>> >> >> That's because you've never worked on a complex application. Your >> claim of an ERP is proof of that. > > You obviously don't know what features are available in my ERP system. > You've told me - it's an order entry/tracking system. >> All you do is database stuff. There's nothing complex about that. > > Correct. There is nothing complex about writing code which moves data > between the user interface and the database. That is why I developed the > Radicore framework, to take care of all that simple "plumbing" stuff for > me. My valuable time is spent on writing the code which deals with the > business rules, the "payload" as I call it, some of which are more > complex than others > And nothing you've done in your entire life is even moderately complex. You wouldn't know where to begin. >>>>>> However, your example of over 200 tables and 350 relationships is a >>>>>> perfect example of how bloated such code can become. >>>>> >>>>> The term "bloat" implies having things which are not used, and I can >>>>> assure >>>>> you that every database table has a purpose and is used in one or more >>>>> transactions. If a database table ever became redundant then I would >>>>> remove >>>>> it. >>>>> >>>> >>>> Not at all. "Bloat" also refers to applications which are overly large >>>> for what needs to be done. >>> >>> My applications are not overly large. While I have a large number of >>> small transactions each of which does one thing, this is not "bloat", it >>> is following the Single Responsibility Principle. >>> >>> >> >> Nope, they aren't, because your applications are just for database >> access. > > They are not "just" for basic database access, they are for applying > complex business rules as well. The "basic" functionality is provided by > the framework while the business rules are provided by the programmer. > To you a "complex business rule" is "the customer ordered something so we need to ship it". You've have no idea what a complex system is. All you do is database access. >> But they sure sound like they're bloated. > > The term "bloat" has nothing to do with the number of database tables. > Provided that the database has been properly normalised (you *DO* know > what the term "properly normalised" means, don't you?) and every table > is used somewhere then there is no "bloat" whatsoever. > It does when you've got way more than you need. And not if it's *properly* normalized. However, I highly doubt your 200+ tables are "properly normalized". Bloat also covers unnecessary crap like your "password validation". > In my book the term "bloat" is covered by unnecessary code, and I would > say that any application which you write which contains 3M LOC has much > more bloat than anything which I write. > Like your password validation routine. And let's see you write an OS in less than 3M LOC. But then you've never done anything more than database access anyway, so you have no idea. >>>> My databases are based on the designs in Len Silverston's Data Model >>>>> Resource book. So far I have implemented the PARTY, PRODUCT, ORDER, >>>>> INVENTORY, SHIPMENT, INVOICE, REQUEST and WORK-EFFORT databases. If >>>>> you >>>>> bother to read his book you wil see that every table serves a purpose. >>>>> >>>> >>>> Yes, that works fine for simple applications. But then you've already >>>> said that's all you do. You've never worked on anything even >>>> moderately complex. >>> >>> I would like to see *YOU* design and build an ERP application basedon >>> those databases and then tell me it's simple! >>> >> >> I'd like to see YOU create a REAL ERP application! All you did was >> build database access to multiple tables. ERP is much more than that. > > I know that. It also includes the application of business rules when > something changes state. An example would be: "when a sales order is > authorised it must be converted into an invoice, a PDF version of that > invoice must be created and emailed to the customer. The invoice must > also be in the language and currency of the customer." > What you're describing is an order entry/tracking system, not an ERP. and multi-language is not at all a big thing to a competent programmer. I can see why you're making something big out of it, though. > <snip> >>>>>>> So you framework generates "a lot" of code, does it? My framework >>>>>>> generates very small amounts of code which call shared functions or >>>>>>> which inherit code from abstract classes. >>>>>>> >>>>>> >>>>>> Yup, for instance, it generates all the set and get methods for the >>>>>> applicable class, as well as database access code >>>>>> (insert/update/delete >>>>>> for single rows and single rows and lists of multiple rows for >>>>>> SELECT). >>>>>> (Most of the access code is in parent classes). >>>>> >>>>> My framework does not bother generating set and get methods as they >>>>> are >>>>> inefficient. Data goes in and comes out as an array. >>>>> >>>> >>>> Yea, that's why your code is crap. You obviously know nothing about >>>> proper OO coding techniques. And that means in order to change one >>>> item in the object the user has to build an array for the whole thing? >>>> Bloat... Bloat... Bloat... >>> >>> You obviously don't know what "proper OO" actually means. And where did >>> I say that in order to change one item in the object the user has to >>> build an array for the whole thing? You are reading things which I did >>> not write. >>> >> >> Oh, I sure do. You said you don't have SET/GET functions. You said you >> set the values with an array. It's exactly what you said. > > But I don't have to insert any code to create that array as it is > already provided for me in the form of $_GET or $_POST. > > When data comes in from the database it appears as a single variable > which is an array of rows and columns. > And you completely miss the question. How do you change a single property in the object without building the array? From the number of times you have ducked the question, my only assumption can be the program can't change a single property in the object. >>>>> My framework does not generate any database access code as that is >>>>> already >>>>> provided by my Data Access Object (DAO). I have one for MySQL, one for >>>>> PostgreSQL, one for Oracle and another for SQL Server. I can switch >>>>> from one >>>>> to another simply by changing a single line in a config file. >>>>> >>>> >>>> Yes, you always waste a lot of time retrieving all columns, whether >>>> they are needed or not. And you update all columns, whether you need >>>> to or not. Bloatware. >>> >>> You are jumping to the wrong conclusion AGAIN! The default is to read >>> all columns simply because by default all columns are displayed on the >>> screen. The defaults can be changed. >>> >> >> Ah, so you have to write code to change those defaults. Once again not >> what you claimed earlier. > > Any person with more than two brain cells to rub together knows that if > the default behaviour is not what you want then you have to write code > to change those defaults. I have never claimed otherwise. My framework > generates working transactions based on a lot of default behaviour, and > in a lot of cases the default behaviour is good enough. When it isn't > you can change it. > That's not what you claimed earlier. Read back at what you said. But then you're good at back-pedaling. And you're doing it again. >>>>>> It also generates the code necessary to validate a field. Some stock >>>>>> fields (like "must be integer") have predefined validation functions. >>>>> >>>>> My framework does not generate any code to perform basic field >>>>> validation as >>>>> that is performed by a validation class which I wrote years ago. >>>>> >>>> >>>> More bloat. And tell me how your class handles a rule such as "8-16 >>>> characters, must have both upper and lower case and at least one >>>> digit". >>> >>> Easy peasy. I just set these values in the database: >>> min_length = 8 >>> max_length = 16 >>> upper_case = 1 >>> lower_case = 1 >>> num_digits = 1 >>> >> >> Bloatware. The code has to needlessly query the database, parse the >> results then apply them to the password, when a regex would do the job >> simply. > > But where do you store the regex? In thin air? Different customers have > different rules, so each customer can specify the rules that they want > on their copy of the database. That is not bloat, it is sensible design. > Nope, it's in the code. Another customer wants another rule? Change the regex. And if you want to be anal about it (you're good at that, also), put it in a function in a separate file. Your way is plain bloat. >> Bloat, bloat, bloat. >> >> >>>> Or how about the bloat of calling a class to verify the input is an >>>> integer when a simple one line statement works. More bloat. >>> >>> I have a validation class which is capable of validating every data >>> type. This means that I do not have to write the line of code which >>> tests that a piece of input is an integer. Not having to write that line >>> is not bloat. >>> >> >> Again, bloatware, when a simple function call like intval() will do >> it. You've added an additional and unnecessary layer of complexity to >> the application. > > You are missing the point AGAIN. In your applications you have to write > code to call the intval() function. In my applications I don't have to > write any validation code because I wrote a general purpose validation > class many years ago, and it deals with that level of validation > automatically. > More bloat. No, the intval() function call is inherent to the set() function. I have to write nothing. And I don't have the bloat of a "general validation class". More bloat. > Again you are writing code to do something which my framework does > automatically. And you have the nerve to say that my methods are crap! > Nope, my framework automatically handles simple rules based on datatypes. If I need more complex rules, they are easy to enter. >>>>>> Others, like passwords where the rules may change, allow the >>>>>> validation >>>>>> to be handled by a regex, function call or similar. >>>>> >>>>> In my framework any password rues - such as minimum length, the >>>>> number of >>>>> uppercase characters, the number of lowercase characters, the >>>>> number of >>>>> digits - is controlled from a database record. Each customer can >>>>> therefore >>>>> change the rules without me having to change any code. >>>>> >>>> >>>> More bloat. And unnecessary. >>> >>> It is necessary if I want to allow the customer to change the password >>> validation rules without having to write any code. Not having to write >>> code is not bloat. >>> >> >> More bloat. And unnecessary. How often does the customer want to >> change the password rules? In about 35 years of programming for >> clients, I've never had that happen. And what about the existing >> passwords which don't match the new rules? > > A customer may or may not want to change the rules after the software > has been installed, but as my software is used by many different > customers each one may want a different set of rules when it is first > installed. I can apply whatever rules a customer wants simply by > changing his copy of the database, and NOT by changing any code. > Changing one line of code is not a problem. Your way is pure bloat. It's interesting that this feature you think is slicker than snot on a doorknob hasn't been implemented by any other systems I'm aware of - including mainframe applications. The rest of the world knows bloat when they see it. >> Why stop with the password? Why not let the customer change the window >> layout, for instance? Or add tables and columns to the database? > > Now you're going off at a tangent. I should quit while you're behind. > Nope, you brought up the subject of allowing the customer to change the rules. This is just an extension of the same subject. After all, CMS's allow customer's to change the screen layout to suit them; CMS's don't force all customers to use the same screen layout. There are many more systems which allow the user to change the page layout than there are the password. The rest of the world knows bloat when they see it. I guess that's all the bloat you're capable of, though. Even a simple CMS would be beyond your capabilities. >> Your code is just bloatware and adds an unnecessary layer of >> complexity to the code. >> >>>>>> It also has the ability to generate forms html to display >>>>>> (read/write or >>>>>> read only). And this is all one function. If I need a different >>>>>> layout >>>>>> for a different page, it's easy to copy/paste a new function and >>>>>> redo the >>>>>> output. >>>>> >>>>> Copy/Paste? That produces duplicate code, not sharable code, and even >>>>> you >>>>> should know that duplicate code violates the DRY principle. >>>>> >>>> >>>> You obviously don't understand the DRY principle. Just because you >>>> copy/paste does not mean it's duplicate code. Once the code has been >>>> modified to do something else, it is no longer duplicate. >>> >>> If you were really clever you wouldn't have to copy/paste/modify, you >>> would have a reusable module. In my MVC implementation I have a fixed >>> set of controllers, and each controller is reusable. Can you say the >>> same in your framework? >>> >> >> Doesn't make any difference. How do you handle displaying the same >> information two entirely different ways on two different windows? Mine >> is simple and straightforward. It is also easy to maintain. > > So is mine. > Yes? So how do you display the same data in different formats then? >>>>>> It also has a function to populate the object from $_GET or $_POST >>>>>> values >>>>>> (with validation). >>>>> >>>>> I don't need a whole function to do that when a single line will do:- >>>>> $result = $object->insertRecord($_POST); >>>>> >>>> >>>> So what is insertRecord($_POST) then, if it's not a function? Once >>>> again you show your ignorance. Don't even know what a function is! >>> >>> What I'm saying is that I don't have a function which splits the $_POST >>> array into its component parts so I can then use a setter on each >>> component, I simply inject the entire $_POST array in a single operation >>> without the need to split it down into its component parts. >>> >> >> So you do have a function which does the work. That's not what you >> said earlier. > > Read what I wrote. I do *NOT* have any function which splits the input > array, be it the $_GET array, the $_POST array, or whatever, into its > component parts. All database data exists in the database table object > as an array of rows and columns. > I never said you had a function which splits the input array. I know English is not your first language, but you really should learn to read. >> I never said I had to split it down into parts, either. I have a >> member function which handles the input. But I guess that's just too >> much for you to understand. > > I beg to differ. You specifically wrote that you have getters and > setters for each individual column/field. I do not have code which > splits an array into its component parts as I can access any component > part while it is still sitting in the array. > That's right. That's an implicit part of OO (encapsulation). I didn't say it was the ONLY thing I did - I also said that I had functions to display and handle forms (where do you thing $_GET and $_POST come from, anyway?). But unlike you, I can get or set a single property, also, as needed. Something I do all the time. >>>>> This means that the same line will work on any object regardless of >>>>> which >>>>> class it came from. That is what polymorphism is all about. >>>>> >>>> >>>> Nope, that's not at all what polymorphism is about. But you obviously >>>> don't understand polymorphism, either. >>> >>> The definition of polymorphism which I use is "same method, different >>> implementation". What definition do you use? >>> >> >> You've got a *partial* definition. Polymorphism is only applicable >> when the two classes have a parent/child hierarchy, and the child >> class has a method of the same name (and in some languages, the same >> parameter list) as the parent. > > The definition of polymorphism does NOT state that the classes have to > exist in a parent/child hierarchy, only that they have the same method > signature. Having said that, it is usually the case that the two classes > ARE related. > Once again you show you have no knowledge of OO. Polymorphism cannot exist without inheritance - which requires a parent/child hierarchy. In most languages the method signature must also be the same (in fact I don't know of any language which doesn't), but that's not a requirement of polymorphism (unlike the parent/child relationship). >> When there is no parent/child relationship (as in the case of two >> different database tables), there is no polymorphism. > > Then you obviously haven't used an abstract table class which is > inherited by every concrete table class. All my concrete table classes > have instant access to all the methods and properties which are defined > just once in the abstract class. > I've used them much longer than you've even known they existed. When you have a class derived from the abstract class, there is a parent/child relationship. But there is no such relationship between two classes derived from the same one. >>>>>>>> However, since each class is pretty much independent, I can easily >>>>>>>> change a class without affecting the rest of the program. >>>>>>> >>>>>>> So can I with my framework. >>>>>>> >>>>>>>> I don't have it where it will work with multiple tables yet >>>>>>>> (something >>>>>>>> I will do one of these days), but it takes a huge amount of the >>>>>>>> repetitive work off of me. >>>>>>> >>>>>>> Removing the need for all this repetitive coding, the "plumbing" >>>>>>> as I >>>>>>> call it, is exactly what my framework does. >>>>>>> >>>>>> >>>>>> Not if it only generates a tiny bit of code. >>>>> >>>>> You are missing the point as usual. My framework need only generate a >>>>> small >>>>> amount of code as everything else, especially all the standard >>>>> plumbing, is >>>>> included from standard pre-written functions. >>>>> >>>> >>>> No, I'm missing nothing. But you've clearly shown just how crappy your >>>> code is. >>> >>> Just because it's different from yours does not make it crap. >>> >> >> It's not because it's different that it's crap. It's crap because >> you've shown here it's crap. > > Only in your tiny mind. > So you wish, anyway. >>>>>>>> And no, I don't try to use it for every project. But where a >>>>>>>> project >>>>>>>> is database-intensive, it suits my purposes. >>>>>>> >>>>>>> All my applications are database-intensive, which is why I use a >>>>>>> framework which is centred around the database. >>>>>>> >>>>>> >>>>>> Ah, that explains it, then. Database access is easy (although many >>>>>> people >>>>>> can still screw that up). Most of my applications need to do real >>>>>> work. >>>>> >>>>> My framework takes care of all the standard database access, and >>>>> getting >>>>> data in and out of the screen, plus basic data validation. As for the >>>>> "real >>>>> work" as you call - or the "payload" as I call it - that is done by >>>>> adding >>>>> whatever code is necessary in the relevant class to implement each >>>>> business >>>>> rule. The point is that when using my framework the programmer has to >>>>> spend >>>>> little or no time on the standard plumbing, which leaves him with >>>>> much more >>>>> time to spend on the payload. >>>>> >>>> >>>> Yup, you've never done any applications which require real work, as >>>> you once again have shown. >>> >>> Then you obviously have not experienced the complicated things which >>> need to be done in an ERP application. >>> >> >> Obviously neither have you. What you have is not a real ERP >> application. I suspect your customer would do as well with an Excel >> spreadsheet. > > It is real enough for my paying customers, and it is THEIR opinion that > counts, not yours. > And it shows just how little you understand ERP systems. Just because you call it an ERP doesn't mean it is an ERP. But it shows the rest of the world how ignorant you are. All you have is a simple order entry/tracking system, not an ERP. >> And I wonder what your customer would think if he knew you were taking >> credit for his hard work in building his business. > > The comment that my software helped that particular customer in that way > was actually made by one of the directors of that company. > And I wonder what your customer would think if he knew you were taking credit for his hard work in building his business. >>>>>> But I'm also not so stupid as to think that my frameworks is good for >>>>>> everyone. It works for me. But I don't try to foist it off on someone >>>>>> else without telling them it's my framework. That is just plain >>>>>> dishonest. >>>>> >>>>> I never said that my framework is the perfect solution for everyone. >>>>> If you >>>>> a writing a simple website then it's not good, but if you are >>>>> writing a >>>>> database application then it's better than most. >>>>> >>>> >>>> Hmmm, you sure seemed to indicate that when you first started pushing >>>> this piece of horse hockey. >>> >>> That may have been the impression that you got, but you have indicated >>> time and time again that your mind works in mysterious ways. >>> >> >> Yea, I live in the real world and have real world experience. Unlike >> you, who seems to live in some alternative universe where you can make >> up any rules you want and can ignore those you don't like. You can >> call a simple database application an ERP and take all the credit for >> your client's hard work. > > It is much more than a simple database application which does nothing > more than move data between the user interface and the database. It > processes a large number of business rules, and it is the number and > complexity of these business rules which decides whether an application > is actually complex or not. > In your world, yes. But then all you've ever done are database applications. You've never worked on anything even moderately complex, by your own admission. >>>>> I was never dishonest about the Radicore framework. I never said it >>>>> was >>>>> written by someone else. I even include a link to the radicore >>>>> website in my >>>>> signature. >>>>> >>>> >>>> And you never said it was written by you, and that you were nowhere >>>> near an unbiased user. The fact you are pushing your own product >>>> without telling people you have a vested interest is dishonest. The >>>> fact you have a link to it in your sig is immaterial - lots of people >>>> have links in their sigs to all kinds of things. >>>> >>>> But then I can see why you don't want to tell people it's your >>>> product. I wouldn't want to admit to having created that piece of >>>> horse hockey, either. >>> >>> You're the expert in horse hockey judging by the amount you write in >>> these posts. >>> >> >> Nope, I know how to program properly. You've obviously never worked in >> a corporate environment, for instance, where you have multiple >> programmers and have to learn good programming techniques. > > I worked in several software houses for many years, and I dealt with > many different projects for many different customers. I was also project > leader on a good number of those projects. I also wrote the framework > used in one of those software houses as well as setting the development > standards. > Were all of those simple database applications also? I suspect so, because that's all you've ever done. But then I can see why you weren't able to keep a job with any of those software houses. >>>>> If *your* framework is so good, then why don't you release it as open >>>>> source >>>>> so that we call all have a laugh? >>>>> >>>> >>>> For a lot of reasons. Mainly because I'm not interested in the hassles >>>> of having to support it for a bunch of people who want all kinds of >>>> other features. I created it for my projects, and it serves those >>>> projects well. >>> >>> What you really mean is that you are too ashamed to have it reviewed by >>> your peers, and that you are incapable of writing code which can be used >>> by others. >>> >> >> Not at all. I meant exactly what I said. > > Yes, you can't be bothered to release it as it is only useful for your > own personal toy projects. > Nope. I just don't want to have to answer a bunch of anal questions by the likes of you. I have better things to do with my time. >> Unlike you, I don't need my ego stroked. > > That's not the impression I get from reading your comments in this post. > You seem to think that YOUR way is the ONLY way, and anybody who dares > to disagree with you is a stupid moron. I disagree with everything you > say, and as for being a moron, 99% of the emails which I receive on the > subject on my work are nothing but complimentary. > Nope. I didn't say my way was the only way. I said my way works, does not contain bloatware and follows recognized OO practices. All you can claim is yours works. And knowing how the rest of the world feels about the ability of PHP programmers, it's not surprising. I've seen some pretty crappy code get high marks because people don't know any better. >> But my code is reviewed by others quite often. Most projects I work on >> are collaborative. But then I work with programmers who know what >> they're doing, also. > > I'd hate to on a team of programmers who all think like you as they > would all be unproductive and full of silly ideas. > We work quite well together and create a lot of GOOD code. Unlike the crap you put put. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
Page 1 of 5 [1] 2 3 4 5 Next page →
Back to top | Article view | comp.lang.php
csiph-web