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 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | "Peter H. Coffin" <hellsop@ninehells.com> |
|---|---|
| Date | 2012-04-14 08:53 -0500 |
| Message-ID | <slrnjoj0b7.4ci.hellsop@nibelheim.ninehells.com> |
| In reply to | #5508 |
On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote:
>
> "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).
Wow.... All that. All Charles *really* needed to do was actually specify
what column names he was fetching and 90% of the work he wants to
eliminate GOES AWAY AUTOMATICALLY.
--
Give a man a fish and you feed him for a day; give him a freshly-charged
Electric Eel and chances are he won't bother you for anything ever
again.
-- Tanuki
[toc] | [prev] | [next] | [standalone]
| From | "Tony Marston" <tony@NOSPAM.demon.co.uk> |
|---|---|
| Date | 2012-04-15 08:33 +0100 |
| Message-ID | <oRuir.84310$H11.42340@fx23.am4> |
| In reply to | #5524 |
"Peter H. Coffin" <hellsop@ninehells.com> wrote in message news:slrnjoj0b7.4ci.hellsop@nibelheim.ninehells.com... > On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote: >> >> "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). > > Wow.... All that. All Charles *really* needed to do was actually specify > what column names he was fetching and 90% of the work he wants to > eliminate GOES AWAY AUTOMATICALLY. Bt what if he has already built built a script (which should be several scripts by the way, one each for LIST, ADD, ENQUIRE, UPDATE, DELETE and SEARCH) then he changes the table's structure? Myabe by adding a field, removing a field, or changing a field's size or type? In a non-framework world you have to modify every script which references that table - you have to change the screen definition, you have to change the validation rules, and you have to change the code which communicates with the database. With a framework like Radicore - which was specifically built for database applications and not websites - all of that grunt work is eliminated. It saves time, and time is money. If you have ever built an applicaton which has evolved over the years to incorporate over 200 databases tables, 350 relationships and 1700 screens then you would appreciate such a time-saving feature. If, on the other hand, you have never built an application which has more than a dozen dinky little tables then you are unlikely to be using any sort of framework at all. -- Tony Marston http://www.tonymarston.net http://www.radicore.org > -- > Give a man a fish and you feed him for a day; give him a freshly-charged > Electric Eel and chances are he won't bother you for anything ever > again. > -- Tanuki
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-04-15 08:51 -0400 |
| Message-ID | <jmeg9a$5pt$2@dont-email.me> |
| In reply to | #5525 |
On 4/15/2012 3:33 AM, Tony Marston wrote: > "Peter H. Coffin"<hellsop@ninehells.com> wrote in message > news:slrnjoj0b7.4ci.hellsop@nibelheim.ninehells.com... >> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote: >>> >>> "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). >> >> Wow.... All that. All Charles *really* needed to do was actually specify >> what column names he was fetching and 90% of the work he wants to >> eliminate GOES AWAY AUTOMATICALLY. > > Bt what if he has already built built a script (which should be several > scripts by the way, one each for LIST, ADD, ENQUIRE, UPDATE, DELETE and > SEARCH) then he changes the table's structure? Myabe by adding a field, > removing a field, or changing a field's size or type? In a non-framework > world you have to modify every script which references that table - you have > to change the screen definition, you have to change the validation rules, > and you have to change the code which communicates with the database. With a > framework like Radicore - which was specifically built for database > applications and not websites - all of that grunt work is eliminated. It > saves time, and time is money. > Not at all true. Ever heard of include(), for instance? And why does he need separate scripts for LIST, ADD, etc.? > If you have ever built an applicaton which has evolved over the years to > incorporate over 200 databases tables, 350 relationships and 1700 screens > then you would appreciate such a time-saving feature. If, on the other hand, > you have never built an application which has more than a dozen dinky little > tables then you are unlikely to be using any sort of framework at all. > A medium sized application. But you don't need a framework. A good design does wonders. -- ================== 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-16 09:31 +0100 |
| Message-ID | <cNQir.139600$bA2.91936@fx20.am4> |
| In reply to | #5527 |
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message news:jmeg9a$5pt$2@dont-email.me... > On 4/15/2012 3:33 AM, Tony Marston wrote: >> "Peter H. Coffin"<hellsop@ninehells.com> wrote in message >> news:slrnjoj0b7.4ci.hellsop@nibelheim.ninehells.com... >>> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote: >>>> >>>> "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). >>> >>> Wow.... All that. All Charles *really* needed to do was actually specify >>> what column names he was fetching and 90% of the work he wants to >>> eliminate GOES AWAY AUTOMATICALLY. >> >> Bt what if he has already built built a script (which should be several >> scripts by the way, one each for LIST, ADD, ENQUIRE, UPDATE, DELETE and >> SEARCH) then he changes the table's structure? Myabe by adding a field, >> removing a field, or changing a field's size or type? In a non-framework >> world you have to modify every script which references that table - you >> have >> to change the screen definition, you have to change the validation rules, >> and you have to change the code which communicates with the database. >> With a >> framework like Radicore - which was specifically built for database >> applications and not websites - all of that grunt work is eliminated. It >> saves time, and time is money. >> > > Not at all true. Ever heard of include(), for instance? And why does he > need separate scripts for LIST, ADD, etc.? Because each of the LIST, ADD, ENQUIRE, UPDATE, DELETE and SEARCH functions has a different screen structure, different behaviour, and may need different security considerations - somebody may be able to access the LIST, ENQUIRE and SEARCH screens, but not the ADD, UPDATE and DELETE screens. It is much easier to control access if they are separate functions/transactions. Instead of having code inside a huge function you have a database-driven Role Based Access Control (RBAC) system built into your framework which allows you to turn access ON or OFF at the function level simply by updating the database. Another advantage of this method is that if you don't have access to a function then it can be edited out of the display of menu buttons. >> If you have ever built an applicaton which has evolved over the years to >> incorporate over 200 databases tables, 350 relationships and 1700 screens >> then you would appreciate such a time-saving feature. If, on the other >> hand, >> you have never built an application which has more than a dozen dinky >> little >> tables then you are unlikely to be using any sort of framework at all. >> > > A medium sized application. But you don't need a framework. A good > design does wonders. It may be medium to you, but not to many others. A proper framework will provide a lot, if not all, of the "plumbing" code for you, so the idea of writing an application with several hundreds of tables and thousands of transactions WITHOUT a framework where you have to write all that plumbing code yourself just strikes me as dumb. An efficient programmer aims to spend less time on the "plumbing" code and more time on the "payload". -- Tony Marston http://www.tonymarston.net http://www.radicore.org > -- > ================== > Remove the "x" from my email address > Jerry Stuckle > JDS Computer Training Corp. > jstucklex@attglobal.net > ==================
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-04-16 08:33 -0400 |
| Message-ID | <jmh3iq$f4m$1@dont-email.me> |
| In reply to | #5540 |
On 4/16/2012 4:31 AM, Tony Marston wrote: > "Jerry Stuckle"<jstucklex@attglobal.net> wrote in message > news:jmeg9a$5pt$2@dont-email.me... >> On 4/15/2012 3:33 AM, Tony Marston wrote: >>> "Peter H. Coffin"<hellsop@ninehells.com> wrote in message >>> news:slrnjoj0b7.4ci.hellsop@nibelheim.ninehells.com... >>>> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote: >>>>> >>>>> "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). >>>> >>>> Wow.... All that. All Charles *really* needed to do was actually specify >>>> what column names he was fetching and 90% of the work he wants to >>>> eliminate GOES AWAY AUTOMATICALLY. >>> >>> Bt what if he has already built built a script (which should be several >>> scripts by the way, one each for LIST, ADD, ENQUIRE, UPDATE, DELETE and >>> SEARCH) then he changes the table's structure? Myabe by adding a field, >>> removing a field, or changing a field's size or type? In a non-framework >>> world you have to modify every script which references that table - you >>> have >>> to change the screen definition, you have to change the validation rules, >>> and you have to change the code which communicates with the database. >>> With a >>> framework like Radicore - which was specifically built for database >>> applications and not websites - all of that grunt work is eliminated. It >>> saves time, and time is money. >>> >> >> Not at all true. Ever heard of include(), for instance? And why does he >> need separate scripts for LIST, ADD, etc.? > > Because each of the LIST, ADD, ENQUIRE, UPDATE, DELETE and SEARCH functions > has a different screen structure, different behaviour, and may need > different security considerations - somebody may be able to access the LIST, > ENQUIRE and SEARCH screens, but not the ADD, UPDATE and DELETE screens. It > is much easier to control access if they are separate > functions/transactions. Instead of having code inside a huge function you > have a database-driven Role Based Access Control (RBAC) system built into > your framework which allows you to turn access ON or OFF at the function > level simply by updating the database. Another advantage of this method is > that if you don't have access to a function then it can be edited out of the > display of menu buttons. > So? None of this requires different scripts. Security can easily be handled via a function call, and the only differences between LIST and UPDATE are whether the fields are read/write or not. Again, easily handled in one script. And all of this can easily be handled in a class, for instance. I know you believe frameworks are slicker than snot on a doorknob, but they are not at all the only way to go. And in many cases there are better ways. >>> If you have ever built an applicaton which has evolved over the years to >>> incorporate over 200 databases tables, 350 relationships and 1700 screens >>> then you would appreciate such a time-saving feature. If, on the other >>> hand, >>> you have never built an application which has more than a dozen dinky >>> little >>> tables then you are unlikely to be using any sort of framework at all. >>> >> >> A medium sized application. But you don't need a framework. A good >> design does wonders. > > It may be medium to you, but not to many others. A proper framework will > provide a glot, if not all, of the "plumbing" code for you, so the idea of > writing an application with several hundreds of tables and thousands of > transactions WITHOUT a framework where you have to write all that plumbing > code yourself just strikes me as dumb. An efficient programmer aims to spend > less time on the "plumbing" code and more time on the "payload". > Yes, there are a lot of people here who don't know what a large application is. But then if the application has "evolved" like you indicate, I suspect it is highly inefficient in how it works. Such is what happens when things "evolve" instead of being properly redesigned when necessary. Frameworks encourage such "evolution". But I wouldn't even think of using a framework for something like that. I would use OO techniques. With the right stuff in your personal libraries, a lot of the work is already done. -- ================== 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-16 15:11 +0100 |
| Message-ID | <oMVir.126156$8i.19574@fx19.am4> |
| In reply to | #5542 |
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message news:jmh3iq$f4m$1@dont-email.me... > On 4/16/2012 4:31 AM, Tony Marston wrote: >> "Jerry Stuckle"<jstucklex@attglobal.net> wrote in message >> news:jmeg9a$5pt$2@dont-email.me... >>> On 4/15/2012 3:33 AM, Tony Marston wrote: >>>> "Peter H. Coffin"<hellsop@ninehells.com> wrote in message >>>> news:slrnjoj0b7.4ci.hellsop@nibelheim.ninehells.com... >>>>> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote: >>>>>> >>>>>> "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). >>>>> >>>>> Wow.... All that. All Charles *really* needed to do was actually >>>>> specify >>>>> what column names he was fetching and 90% of the work he wants to >>>>> eliminate GOES AWAY AUTOMATICALLY. >>>> >>>> Bt what if he has already built built a script (which should be several >>>> scripts by the way, one each for LIST, ADD, ENQUIRE, UPDATE, DELETE and >>>> SEARCH) then he changes the table's structure? Myabe by adding a field, >>>> removing a field, or changing a field's size or type? In a >>>> non-framework >>>> world you have to modify every script which references that table - you >>>> have >>>> to change the screen definition, you have to change the validation >>>> rules, >>>> and you have to change the code which communicates with the database. >>>> With a >>>> framework like Radicore - which was specifically built for database >>>> applications and not websites - all of that grunt work is eliminated. >>>> It >>>> saves time, and time is money. >>>> >>> >>> Not at all true. Ever heard of include(), for instance? And why does >>> he >>> need separate scripts for LIST, ADD, etc.? >> >> Because each of the LIST, ADD, ENQUIRE, UPDATE, DELETE and SEARCH >> functions >> has a different screen structure, different behaviour, and may need >> different security considerations - somebody may be able to access the >> LIST, >> ENQUIRE and SEARCH screens, but not the ADD, UPDATE and DELETE screens. >> It >> is much easier to control access if they are separate >> functions/transactions. Instead of having code inside a huge function you >> have a database-driven Role Based Access Control (RBAC) system built into >> your framework which allows you to turn access ON or OFF at the function >> level simply by updating the database. Another advantage of this method >> is >> that if you don't have access to a function then it can be edited out of >> the >> display of menu buttons. >> > > So? None of this requires different scripts. Each screen should have its own script, and a LIST screen which shows summary data for many rows going across the page with column labels across the top is different from a detail screen (ADD, ENQUIRE, UPDATE, DELETE and SEARCH) which shows details for a single row going down the page with labels on the left and values on the right. This break is even more essential when there is simply too many fields for each row in a LIST screen. > Security can easily be handled via a function call, I have worked with such complications in the past, and I know from experience that having a single script which can perform several functions, then trying to make one or more of those functions inaccessible to the current user is a maintenance nightmare. You have to avoid calling code that shouldn't be executed, and avoid not calling code which should be executed. It is far simpler to split each function into a smaller dedicated script and have the framework decide whether to call the script or not than it is to call a script and afterwards decide that it's not actually allowed. > and the only differences between LIST and UPDATE are whether the fields > are read/write or not. Again, easily handled in one script. And all of > this can easily be handled in a class, for instance. I have been developing database applications in different langages for several decades, and in my experience having a single LIST screen which can also be used for ADD, ENQUIRE, UPDATE, DELETE and SEARCH only works for simple applications such as PhpMyAdmin. For real world applications used in the enterprise they require something more sophisticated, which is where your approach falls short. > I know you believe frameworks are slicker than snot on a doorknob, but > they are not at all the only way to go. And in many cases there are > better ways. > >>>> If you have ever built an applicaton which has evolved over the years >>>> to >>>> incorporate over 200 databases tables, 350 relationships and 1700 >>>> screens >>>> then you would appreciate such a time-saving feature. If, on the other >>>> hand, >>>> you have never built an application which has more than a dozen dinky >>>> little >>>> tables then you are unlikely to be using any sort of framework at all. >>>> >>> >>> A medium sized application. But you don't need a framework. A good >>> design does wonders. >> >> It may be medium to you, but not to many others. A proper framework will >> provide a glot, if not all, of the "plumbing" code for you, so the idea >> of >> writing an application with several hundreds of tables and thousands of >> transactions WITHOUT a framework where you have to write all that >> plumbing >> code yourself just strikes me as dumb. An efficient programmer aims to >> spend >> less time on the "plumbing" code and more time on the "payload". >> > > Yes, there are a lot of people here who don't know what a large > application is. But then if the application has "evolved" like you > indicate, I suspect it is highly inefficient in how it works. Such is > what happens when things "evolve" instead of being properly redesigned > when necessary. Frameworks encourage such "evolution". > > But I wouldn't even think of using a framework for something like that. I > would use OO techniques. With the right stuff in your personal libraries, > a lot of the work is already done. OO techniques on their own are insufficient. You can't get away from having to write enormous amounts of "plumbing" code if you don't use a framework. Using libraries is not much of a time saver as you still have to write the code to call the library functions. A framework is more than a collection of libraries as it also provides a series of runnable tools which help generate user transactions. Radicore is such a framework as you can start with nothing more than a database schema, and using the data dictionary you can generate the classes and transaction scripts to view and maintain a table in minutes without having to write a line of PHP, HTML or SQL. Can you do that with your libraries? -- Tony Marston http://www.tonymarston.net http://www.radicore.org > -- > ================== > Remove the "x" from my email address > Jerry Stuckle > JDS Computer Training Corp. > jstucklex@attglobal.net > ==================
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-04-16 11:18 -0400 |
| Message-ID | <jmhd8m$6jr$1@dont-email.me> |
| In reply to | #5544 |
On 4/16/2012 10:11 AM, Tony Marston wrote: > "Jerry Stuckle"<jstucklex@attglobal.net> wrote in message > news:jmh3iq$f4m$1@dont-email.me... >> On 4/16/2012 4:31 AM, Tony Marston wrote: >>> "Jerry Stuckle"<jstucklex@attglobal.net> wrote in message >>> news:jmeg9a$5pt$2@dont-email.me... >>>> On 4/15/2012 3:33 AM, Tony Marston wrote: >>>>> "Peter H. Coffin"<hellsop@ninehells.com> wrote in message >>>>> news:slrnjoj0b7.4ci.hellsop@nibelheim.ninehells.com... >>>>>> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote: >>>>>>> >>>>>>> "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). >>>>>> >>>>>> Wow.... All that. All Charles *really* needed to do was actually >>>>>> specify >>>>>> what column names he was fetching and 90% of the work he wants to >>>>>> eliminate GOES AWAY AUTOMATICALLY. >>>>> >>>>> Bt what if he has already built built a script (which should be several >>>>> scripts by the way, one each for LIST, ADD, ENQUIRE, UPDATE, DELETE and >>>>> SEARCH) then he changes the table's structure? Myabe by adding a field, >>>>> removing a field, or changing a field's size or type? In a >>>>> non-framework >>>>> world you have to modify every script which references that table - you >>>>> have >>>>> to change the screen definition, you have to change the validation >>>>> rules, >>>>> and you have to change the code which communicates with the database. >>>>> With a >>>>> framework like Radicore - which was specifically built for database >>>>> applications and not websites - all of that grunt work is eliminated. >>>>> It >>>>> saves time, and time is money. >>>>> >>>> >>>> Not at all true. Ever heard of include(), for instance? And why does >>>> he >>>> need separate scripts for LIST, ADD, etc.? >>> >>> Because each of the LIST, ADD, ENQUIRE, UPDATE, DELETE and SEARCH >>> functions >>> has a different screen structure, different behaviour, and may need >>> different security considerations - somebody may be able to access the >>> LIST, >>> ENQUIRE and SEARCH screens, but not the ADD, UPDATE and DELETE screens. >>> It >>> is much easier to control access if they are separate >>> functions/transactions. Instead of having code inside a huge function you >>> have a database-driven Role Based Access Control (RBAC) system built into >>> your framework which allows you to turn access ON or OFF at the function >>> level simply by updating the database. Another advantage of this method >>> is >>> that if you don't have access to a function then it can be edited out of >>> the >>> display of menu buttons. >>> >> >> So? None of this requires different scripts. > > Each screen should have its own script, and a LIST screen which shows > summary data for many rows going across the page with column labels across > the top is different from a detail screen (ADD, ENQUIRE, UPDATE, DELETE and > SEARCH) which shows details for a single row going down the page with labels > on the left and values on the right. This break is even more essential when > there is simply too many fields for each row in a LIST screen. > Why? Because your framework demands it be so? >> Security can easily be handled via a function call, > > I have worked with such complications in the past, and I know from > experience that having a single script which can perform several functions, > then trying to make one or more of those functions inaccessible to the > current user is a maintenance nightmare. You have to avoid calling code that > shouldn't be executed, and avoid not calling code which should be executed. > It is far simpler to split each function into a smaller dedicated script and > have the framework decide whether to call the script or not than it is to > call a script and afterwards decide that it's not actually allowed. > I have too. It works great. And much easier to maintain than similar code in multiple scripts. >> and the only differences between LIST and UPDATE are whether the fields >> are read/write or not. Again, easily handled in one script. And all of >> this can easily be handled in a class, for instance. > > I have been developing database applications in different langages for > several decades, and in my experience having a single LIST screen which can > also be used for ADD, ENQUIRE, UPDATE, DELETE and SEARCH only works for > simple applications such as PhpMyAdmin. For real world applications used in > the enterprise they require something more sophisticated, which is where > your approach falls short. > I have also. I first learned how to do it when working with CICS at IBM, then later graduated to C++ programming. Classes do wonders in such an environment. >> I know you believe frameworks are slicker than snot on a doorknob, but >> they are not at all the only way to go. And in many cases there are >> better ways. >> >>>>> If you have ever built an applicaton which has evolved over the years >>>>> to >>>>> incorporate over 200 databases tables, 350 relationships and 1700 >>>>> screens >>>>> then you would appreciate such a time-saving feature. If, on the other >>>>> hand, >>>>> you have never built an application which has more than a dozen dinky >>>>> little >>>>> tables then you are unlikely to be using any sort of framework at all. >>>>> >>>> >>>> A medium sized application. But you don't need a framework. A good >>>> design does wonders. >>> >>> It may be medium to you, but not to many others. A proper framework will >>> provide a glot, if not all, of the "plumbing" code for you, so the idea >>> of >>> writing an application with several hundreds of tables and thousands of >>> transactions WITHOUT a framework where you have to write all that >>> plumbing >>> code yourself just strikes me as dumb. An efficient programmer aims to >>> spend >>> less time on the "plumbing" code and more time on the "payload". >>> >> >> Yes, there are a lot of people here who don't know what a large >> application is. But then if the application has "evolved" like you >> indicate, I suspect it is highly inefficient in how it works. Such is >> what happens when things "evolve" instead of being properly redesigned >> when necessary. Frameworks encourage such "evolution". >> >> But I wouldn't even think of using a framework for something like that. I >> would use OO techniques. With the right stuff in your personal libraries, >> a lot of the work is already done. > > OO techniques on their own are insufficient. You can't get away from having > to write enormous amounts of "plumbing" code if you don't use a framework. > Using libraries is not much of a time saver as you still have to write the > code to call the library functions. A framework is more than a collection of > libraries as it also provides a series of runnable tools which help generate > user transactions. Radicore is such a framework as you can start with > nothing more than a database schema, and using the data dictionary you can > generate the classes and transaction scripts to view and maintain a table in > minutes without having to write a line of PHP, HTML or SQL. Can you do that > with your libraries? > They are in many cased much better than frameworks. There isn't that much "plumbing" code. And you still have to write the code to fit into the framework. The biggest problem with frameworks when the needs fall outside of the frameworks capabilities - and quite frankly, most of the programming I do is that way. But then there is that tendency to make the problem fit the framework - instead of the solution fitting the problem. As for generating all that code - my libraries do a lot of it. But no, I can't do it without writing any code, and neither can you. How do you validate your input, for instance? Or control the layout? For instance, I have one commercial product I'm working on right now where the User table had a bunch of fields. Not all fields will be needed by all users. Which fields are used are found in a second table. Can your framework display and validate fields from the first table based on rows in the second table? Without writing a single line of PHP code? -- ================== 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-17 09:18 +0100 |
| Message-ID | <7I9jr.212617$sE1.169738@fx22.am4> |
| In reply to | #5545 |
"Jerry Stuckle" wrote in message news:jmhd8m$6jr$1@dont-email.me... > >On 4/16/2012 10:11 AM, Tony Marston wrote: >> "Jerry Stuckle"<jstucklex@attglobal.net> wrote in message >> news:jmh3iq$f4m$1@dont-email.me... >>> On 4/16/2012 4:31 AM, Tony Marston wrote: >>>> "Jerry Stuckle"<jstucklex@attglobal.net> wrote in message >>>> news:jmeg9a$5pt$2@dont-email.me... >>>>> On 4/15/2012 3:33 AM, Tony Marston wrote: >>>>>> "Peter H. Coffin"<hellsop@ninehells.com> wrote in message >>>>>> news:slrnjoj0b7.4ci.hellsop@nibelheim.ninehells.com... >>>>>>> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote: >>>>>>>> >>>>>>>> "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). >>>>>>> >>>>>>> Wow.... All that. All Charles *really* needed to do was actually >>>>>>> specify >>>>>>> what column names he was fetching and 90% of the work he wants to >>>>>>> eliminate GOES AWAY AUTOMATICALLY. >>>>>> >>>>>> But what if he has already built built a script (which should be >>>>>> several >>>>>> scripts by the way, one each for LIST, ADD, ENQUIRE, UPDATE, DELETE >>>>>> and >>>>>> SEARCH) then he changes the table's structure? Maybe by adding a >>>>>> field, >>>>>> removing a field, or changing a field's size or type? In a >>>>>> non-framework >>>>>> world you have to modify every script which references that table - >>>>>> you >>>>>> have >>>>>> to change the screen definition, you have to change the validation >>>>>> rules, >>>>>> and you have to change the code which communicates with the database. >>>>>> With a >>>>>> framework like Radicore - which was specifically built for database >>>>>> applications and not websites - all of that grunt work is eliminated. >>>>>> It >>>>>> saves time, and time is money. >>>>>> >>>>> >>>>> Not at all true. Ever heard of include(), for instance? And why does >>>>> he >>>>> need separate scripts for LIST, ADD, etc.? >>>> >>>> Because each of the LIST, ADD, ENQUIRE, UPDATE, DELETE and SEARCH >>>> functions >>>> has a different screen structure, different behaviour, and may need >>>> different security considerations - somebody may be able to access the >>>> LIST, >>>> ENQUIRE and SEARCH screens, but not the ADD, UPDATE and DELETE screens. >>>> It >>>> is much easier to control access if they are separate >>>> functions/transactions. Instead of having code inside a huge function >>>> you >>>> have a database-driven Role Based Access Control (RBAC) system built >>>> into >>>> your framework which allows you to turn access ON or OFF at the >>>> function >>>> level simply by updating the database. Another advantage of this method >>>> is >>>> that if you don't have access to a function then it can be edited out >>>> of >>>> the >>>> display of menu buttons. >>>> >>> >>> So? None of this requires different scripts. >> >> Each screen should have its own script, and a LIST screen which shows >> summary data for many rows going across the page with column labels >> across >> the top is different from a detail screen (ADD, ENQUIRE, UPDATE, DELETE >> and >> SEARCH) which shows details for a single row going down the page with >> labels >> on the left and values on the right. This break is even more essential >> when >> there is simply too many fields for each row in a LIST screen. >> > >Why? Because your framework demands it be so? No, that is the way I have built applications since the 1980s when I was working for a software house. The other developers found it easier to write and maintain programs which had a single screen and function instead of programs which had multiple screens/functions. And the users liked it that way as well. >>> Security can easily be handled via a function call, >> >> I have worked with such complications in the past, and I know from >> experience that having a single script which can perform several >> functions, >> then trying to make one or more of those functions inaccessible to the >> current user is a maintenance nightmare. You have to avoid calling code >> that >> shouldn't be executed, and avoid not calling code which should be >> executed. >> It is far simpler to split each function into a smaller dedicated script >> and >> have the framework decide whether to call the script or not than it is to >> call a script and afterwards decide that it's not actually allowed. >> > >I have too. It works great. And much easier to maintain than similar code >in multiple scripts. I disagree. Having a script that performs a single function is easier to maintain than a script which can perform multiple functions as you have to keep track of what function the user has selected, then ensure that the right code does get executed while the wrong code does not. I and my fellow developers have been through that scenario, which is why we all prefer the single-function-per-script approach. >>> and the only differences between LIST and UPDATE are whether the fields >>> are read/write or not. Again, easily handled in one script. And all of >>> this can easily be handled in a class, for instance. >> >> I have been developing database applications in different languages for >> several decades, and in my experience having a single LIST screen which >> can >> also be used for ADD, ENQUIRE, UPDATE, DELETE and SEARCH only works for >> simple applications such as PhpMyAdmin. For real world applications used >> in >> the enterprise they require something more sophisticated, which is where >> your approach falls short. >> > >I have also. I first learned how to do it when working with CICS at IBM, >then later graduated to C++ programming. Classes do wonders in such an >environment. Classes by themselves are not a solution, it is the code within them, and how they are strung together, which provides the solution. I'm afraid that an application which has a single screen to perform the list, add, enquire, update, delete and search functions is no better than a general-purpose admin like phpMyadmin, and that is simply not good enough for sophisticated users with sophisticated needs. >>> I know you believe frameworks are slicker than snot on a doorknob, but >>> they are not at all the only way to go. And in many cases there are >>> better ways. >>> >>>>>> If you have ever built an application which has evolved over the >>>>>> years >>>>>> to >>>>>> incorporate over 200 databases tables, 350 relationships and 1700 >>>>>> screens >>>>>> then you would appreciate such a time-saving feature. If, on the >>>>>> other >>>>>> hand, >>>>>> you have never built an application which has more than a dozen dinky >>>>>> little >>>>>> tables then you are unlikely to be using any sort of framework at >>>>>> all. >>>>>> >>>>> >>>>> A medium sized application. But you don't need a framework. A good >>>>> design does wonders. >>>> >>>> It may be medium to you, but not to many others. A proper framework >>>> will >>>> provide a lot, if not all, of the "plumbing" code for you, so the idea >>>> of >>>> writing an application with several hundreds of tables and thousands of >>>> transactions WITHOUT a framework where you have to write all that >>>> plumbing >>>> code yourself just strikes me as dumb. An efficient programmer aims to >>>> spend >>>> less time on the "plumbing" code and more time on the "payload". >>>> >>> >>> Yes, there are a lot of people here who don't know what a large >>> application is. But then if the application has "evolved" like you >>> indicate, I suspect it is highly inefficient in how it works. Such is >>> what happens when things "evolve" instead of being properly redesigned >>> when necessary. Frameworks encourage such "evolution". >>> >>> But I wouldn't even think of using a framework for something like that. >>> I >>> would use OO techniques. With the right stuff in your personal >>> libraries, >>> a lot of the work is already done. >> >> OO techniques on their own are insufficient. You can't get away from >> having >> to write enormous amounts of "plumbing" code if you don't use a >> framework. >> Using libraries is not much of a time saver as you still have to write >> the >> code to call the library functions. A framework is more than a collection >> of >> libraries as it also provides a series of runnable tools which help >> generate >> user transactions. Radicore is such a framework as you can start with >> nothing more than a database schema, and using the data dictionary you >> can >> generate the classes and transaction scripts to view and maintain a table >> in >> minutes without having to write a line of PHP, HTML or SQL. Can you do >> that >> with your libraries? >> > >They are in many cased much better than frameworks. There isn't that much >"plumbing" code. And you still have to write the code to fit into the >framework. When using the Radicore framework it provides all the plumbing code for you, you only have to add code to deal with business rules which go beyond what Radicore provides as standard. >The biggest problem with frameworks when the needs fall outside of the >frameworks capabilities - and quite frankly, most of the programming I do >is that way. But then there is that tendency to make the problem fit the >framework - instead of the solution fitting the problem. I write database applications, and I created the Radicore framework to help me build such applications, and it works much better than anything else I have seen. I can build these applications much faster than I could in the 1980s when using COBOL, and faster than I could in the 1990s when using UNIFACE. It removes a lot of the grunt work by providing as much of the plumbing as possible, which leaves me more time to spend on the payload, the code which delivers value to the customer. >As for generating all that code - my libraries do a lot of it. But no, I >can't do it without writing any code, and neither can you. How do you >validate your input, for instance? Or control the layout? Basic validation, such as dealing with NOT NULL fields, or checking that date fields contain dates and numeric fields contain numbers, etc, is all performed automatically by the framework. I don't have to write any code at all to perform basic data validation. Screen layouts are controlled by a simple screen structure script which is generated automatically when the transaction is generated from a pattern. It is very easy to modify this script to move fields around, or drop them from the screen altogether. >For instance, I have one commercial product I'm working on right now where >the User table had a bunch of fields. Not all fields will be needed by all >users. Which fields are used are found in a second table. Can your >framework display and validate fields from the first table based on rows in >the second table? Without writing a single line of PHP code? Yes. As well as having a database table which allows access to individual transactions, I have another database table which modifies the access to individual fields within a transaction. A normally modifiable field can be changed to read-only, or it can be removed from the screen (for that user) altogether. All security, whether it's access to individual transactions, or fields within transactions, is controlled by updating database tables using the screens provided, not by writing code. -- Tony Marston http://www.tonymarston.net http://www.radicore.org
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-04-17 06:07 -0400 |
| Message-ID | <jmjfdk$vmp$1@dont-email.me> |
| In reply to | #5551 |
On 4/17/2012 4:18 AM, Tony Marston wrote: > "Jerry Stuckle" wrote in message news:jmhd8m$6jr$1@dont-email.me... >> >> On 4/16/2012 10:11 AM, Tony Marston wrote: >>> "Jerry Stuckle"<jstucklex@attglobal.net> wrote in message >>> news:jmh3iq$f4m$1@dont-email.me... >>>> On 4/16/2012 4:31 AM, Tony Marston wrote: >>>>> "Jerry Stuckle"<jstucklex@attglobal.net> wrote in message >>>>> news:jmeg9a$5pt$2@dont-email.me... >>>>>> On 4/15/2012 3:33 AM, Tony Marston wrote: >>>>>>> "Peter H. Coffin"<hellsop@ninehells.com> wrote in message >>>>>>> news:slrnjoj0b7.4ci.hellsop@nibelheim.ninehells.com... >>>>>>>> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote: >>>>>>>>> >>>>>>>>> "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). >>>>>>>> >>>>>>>> Wow.... All that. All Charles *really* needed to do was actually >>>>>>>> specify >>>>>>>> what column names he was fetching and 90% of the work he wants to >>>>>>>> eliminate GOES AWAY AUTOMATICALLY. >>>>>>> >>>>>>> But what if he has already built built a script (which should be >>>>>>> several >>>>>>> scripts by the way, one each for LIST, ADD, ENQUIRE, UPDATE, >>>>>>> DELETE and >>>>>>> SEARCH) then he changes the table's structure? Maybe by adding a >>>>>>> field, >>>>>>> removing a field, or changing a field's size or type? In a >>>>>>> non-framework >>>>>>> world you have to modify every script which references that table >>>>>>> - you >>>>>>> have >>>>>>> to change the screen definition, you have to change the validation >>>>>>> rules, >>>>>>> and you have to change the code which communicates with the >>>>>>> database. >>>>>>> With a >>>>>>> framework like Radicore - which was specifically built for database >>>>>>> applications and not websites - all of that grunt work is >>>>>>> eliminated. >>>>>>> It >>>>>>> saves time, and time is money. >>>>>>> >>>>>> >>>>>> Not at all true. Ever heard of include(), for instance? And why does >>>>>> he >>>>>> need separate scripts for LIST, ADD, etc.? >>>>> >>>>> Because each of the LIST, ADD, ENQUIRE, UPDATE, DELETE and SEARCH >>>>> functions >>>>> has a different screen structure, different behaviour, and may need >>>>> different security considerations - somebody may be able to access the >>>>> LIST, >>>>> ENQUIRE and SEARCH screens, but not the ADD, UPDATE and DELETE >>>>> screens. >>>>> It >>>>> is much easier to control access if they are separate >>>>> functions/transactions. Instead of having code inside a huge >>>>> function you >>>>> have a database-driven Role Based Access Control (RBAC) system >>>>> built into >>>>> your framework which allows you to turn access ON or OFF at the >>>>> function >>>>> level simply by updating the database. Another advantage of this >>>>> method >>>>> is >>>>> that if you don't have access to a function then it can be edited >>>>> out of >>>>> the >>>>> display of menu buttons. >>>>> >>>> >>>> So? None of this requires different scripts. >>> >>> Each screen should have its own script, and a LIST screen which shows >>> summary data for many rows going across the page with column labels >>> across >>> the top is different from a detail screen (ADD, ENQUIRE, UPDATE, >>> DELETE and >>> SEARCH) which shows details for a single row going down the page with >>> labels >>> on the left and values on the right. This break is even more >>> essential when >>> there is simply too many fields for each row in a LIST screen. >>> >> >> Why? Because your framework demands it be so? > > No, that is the way I have built applications since the 1980s when I was > working for a software house. The other developers found it easier to > write and maintain programs which had a single screen and function > instead of programs which had multiple screens/functions. And the users > liked it that way as well. > You've been doing it that badly all this time? >>>> Security can easily be handled via a function call, >>> >>> I have worked with such complications in the past, and I know from >>> experience that having a single script which can perform several >>> functions, >>> then trying to make one or more of those functions inaccessible to the >>> current user is a maintenance nightmare. You have to avoid calling >>> code that >>> shouldn't be executed, and avoid not calling code which should be >>> executed. >>> It is far simpler to split each function into a smaller dedicated >>> script and >>> have the framework decide whether to call the script or not than it >>> is to >>> call a script and afterwards decide that it's not actually allowed. >>> >> >> I have too. It works great. And much easier to maintain than similar >> code in multiple scripts. > > I disagree. Having a script that performs a single function is easier to > maintain than a script which can perform multiple functions as you have > to keep track of what function the user has selected, then ensure that > the right code does get executed while the wrong code does not. I and my > fellow developers have been through that scenario, which is why we all > prefer the single-function-per-script approach. > Yup, you have a script which displays a single form. What can be simpler? And if you and your developers thing it's easier to spread what is effectively duplicate code across several scripts, then I see why you need a framework. >>>> and the only differences between LIST and UPDATE are whether the fields >>>> are read/write or not. Again, easily handled in one script. And all of >>>> this can easily be handled in a class, for instance. >>> >>> I have been developing database applications in different languages for >>> several decades, and in my experience having a single LIST screen >>> which can >>> also be used for ADD, ENQUIRE, UPDATE, DELETE and SEARCH only works for >>> simple applications such as PhpMyAdmin. For real world applications >>> used in >>> the enterprise they require something more sophisticated, which is where >>> your approach falls short. >>> >> >> I have also. I first learned how to do it when working with CICS at >> IBM, then later graduated to C++ programming. Classes do wonders in >> such an environment. > > Classes by themselves are not a solution, it is the code within them, > and how they are strung together, which provides the solution. I'm > afraid that an application which has a single screen to perform the > list, add, enquire, update, delete and search functions is no better > than a general-purpose admin like phpMyadmin, and that is simply not > good enough for sophisticated users with sophisticated needs. > Yup, which all comes back to good design. But I didn't say it was a single screen which does all that - I said it was a single script which performs it. And the more sophisticated the application becomes, the more important it is to not duplicate your code in multiple scripts (and the less appropriate a framework becomes). I'm not against frameworks in general. They are ok for simple applications. >>>> I know you believe frameworks are slicker than snot on a doorknob, but >>>> they are not at all the only way to go. And in many cases there are >>>> better ways. >>>> >>>>>>> If you have ever built an application which has evolved over the >>>>>>> years >>>>>>> to >>>>>>> incorporate over 200 databases tables, 350 relationships and 1700 >>>>>>> screens >>>>>>> then you would appreciate such a time-saving feature. If, on the >>>>>>> other >>>>>>> hand, >>>>>>> you have never built an application which has more than a dozen >>>>>>> dinky >>>>>>> little >>>>>>> tables then you are unlikely to be using any sort of framework at >>>>>>> all. >>>>>>> >>>>>> >>>>>> A medium sized application. But you don't need a framework. A good >>>>>> design does wonders. >>>>> >>>>> It may be medium to you, but not to many others. A proper framework >>>>> will >>>>> provide a lot, if not all, of the "plumbing" code for you, so the idea >>>>> of >>>>> writing an application with several hundreds of tables and >>>>> thousands of >>>>> transactions WITHOUT a framework where you have to write all that >>>>> plumbing >>>>> code yourself just strikes me as dumb. An efficient programmer aims to >>>>> spend >>>>> less time on the "plumbing" code and more time on the "payload". >>>>> >>>> >>>> Yes, there are a lot of people here who don't know what a large >>>> application is. But then if the application has "evolved" like you >>>> indicate, I suspect it is highly inefficient in how it works. Such is >>>> what happens when things "evolve" instead of being properly redesigned >>>> when necessary. Frameworks encourage such "evolution". >>>> >>>> But I wouldn't even think of using a framework for something like >>>> that. I >>>> would use OO techniques. With the right stuff in your personal >>>> libraries, >>>> a lot of the work is already done. >>> >>> OO techniques on their own are insufficient. You can't get away from >>> having >>> to write enormous amounts of "plumbing" code if you don't use a >>> framework. >>> Using libraries is not much of a time saver as you still have to >>> write the >>> code to call the library functions. A framework is more than a >>> collection of >>> libraries as it also provides a series of runnable tools which help >>> generate >>> user transactions. Radicore is such a framework as you can start with >>> nothing more than a database schema, and using the data dictionary >>> you can >>> generate the classes and transaction scripts to view and maintain a >>> table in >>> minutes without having to write a line of PHP, HTML or SQL. Can you >>> do that >>> with your libraries? >>> >> >> They are in many cased much better than frameworks. There isn't that >> much "plumbing" code. And you still have to write the code to fit into >> the framework. > > When using the Radicore framework it provides all the plumbing code for > you, you only have to add code to deal with business rules which go > beyond what Radicore provides as standard. > Ah, so you DO have to write PHP code, then. >> The biggest problem with frameworks when the needs fall outside of the >> frameworks capabilities - and quite frankly, most of the programming I >> do is that way. But then there is that tendency to make the problem >> fit the framework - instead of the solution fitting the problem. > > I write database applications, and I created the Radicore framework to > help me build such applications, and it works much better than anything > else I have seen. I can build these applications much faster than I > could in the 1980s when using COBOL, and faster than I could in the > 1990s when using UNIFACE. It removes a lot of the grunt work by > providing as much of the plumbing as possible, which leaves me more time > to spend on the payload, the code which delivers value to the customer. > Ah, now I see why you think Radicore is slicker than snot on a doorknob. But then creators always think their (whatever) is the best thing in the world and applicable to every situation in the universe. I can build PHP code a lot faster than I could COBOL in the 70's or FORTRAN in the 60's. But I can say the same for C++, also. >> As for generating all that code - my libraries do a lot of it. But no, >> I can't do it without writing any code, and neither can you. How do >> you validate your input, for instance? Or control the layout? > > Basic validation, such as dealing with NOT NULL fields, or checking that > date fields contain dates and numeric fields contain numbers, etc, is > all performed automatically by the framework. I don't have to write any > code at all to perform basic data validation. Screen layouts are > controlled by a simple screen structure script which is generated > automatically when the transaction is generated from a pattern. It is > very easy to modify this script to move fields around, or drop them from > the screen altogether. > Sure, those are easy. I don't have to do that either with my libraries. But *I* control the screen layout, according to what the customer wants. I don't let a framework tell the customer what the layout will be. But one again are you saying you can do all that without writing any code? >> For instance, I have one commercial product I'm working on right now >> where the User table had a bunch of fields. Not all fields will be >> needed by all users. Which fields are used are found in a second >> table. Can your framework display and validate fields from the first >> table based on rows in the second table? Without writing a single line >> of PHP code? > > Yes. As well as having a database table which allows access to > individual transactions, I have another database table which modifies > the access to individual fields within a transaction. A normally > modifiable field can be changed to read-only, or it can be removed from > the screen (for that user) altogether. > And you can do that without writing any code? And make it dynamic, so when the user changes the contents of the second table the screen changes also? > All security, whether it's access to individual transactions, or fields > within transactions, is controlled by updating database tables using the > screens provided, not by writing code. > And how do you guarantee the entered data are valid? Yes, I know you think your toy is the answer to life, the universe and everything. But it isn't. -- ================== 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:10 +0100 |
| Message-ID | <gGujr.123754$lq1.27093@fx18.am4> |
| In reply to | #5552 |
"Jerry Stuckle" wrote in message news:jmjfdk$vmp$1@dont-email.me... > >On 4/17/2012 4:18 AM, Tony Marston wrote: >> "Jerry Stuckle" wrote in message news:jmhd8m$6jr$1@dont-email.me... >>> >>> On 4/16/2012 10:11 AM, Tony Marston wrote: >>>> "Jerry Stuckle"<jstucklex@attglobal.net> wrote in message >>>> news:jmh3iq$f4m$1@dont-email.me... >>>>> On 4/16/2012 4:31 AM, Tony Marston wrote: >>>>>> "Jerry Stuckle"<jstucklex@attglobal.net> wrote in message >>>>>> news:jmeg9a$5pt$2@dont-email.me... >>>>>>> On 4/15/2012 3:33 AM, Tony Marston wrote: >>>>>>>> "Peter H. Coffin"<hellsop@ninehells.com> wrote in message >>>>>>>> news:slrnjoj0b7.4ci.hellsop@nibelheim.ninehells.com... >>>>>>>>> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote: >>>>>>>>>> >>>>>>>>>> "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). >>>>>>>>> >>>>>>>>> Wow.... All that. All Charles *really* needed to do was actually >>>>>>>>> specify >>>>>>>>> what column names he was fetching and 90% of the work he wants to >>>>>>>>> eliminate GOES AWAY AUTOMATICALLY. >>>>>>>> >>>>>>>> But what if he has already built built a script (which should be >>>>>>>> several >>>>>>>> scripts by the way, one each for LIST, ADD, ENQUIRE, UPDATE, >>>>>>>> DELETE and >>>>>>>> SEARCH) then he changes the table's structure? Maybe by adding a >>>>>>>> field, >>>>>>>> removing a field, or changing a field's size or type? In a >>>>>>>> non-framework >>>>>>>> world you have to modify every script which references that table >>>>>>>> - you >>>>>>>> have >>>>>>>> to change the screen definition, you have to change the validation >>>>>>>> rules, >>>>>>>> and you have to change the code which communicates with the >>>>>>>> database. >>>>>>>> With a >>>>>>>> framework like Radicore - which was specifically built for database >>>>>>>> applications and not websites - all of that grunt work is >>>>>>>> eliminated. >>>>>>>> It >>>>>>>> saves time, and time is money. >>>>>>>> >>>>>>> >>>>>>> Not at all true. Ever heard of include(), for instance? And why does >>>>>>> he >>>>>>> need separate scripts for LIST, ADD, etc.? >>>>>> >>>>>> Because each of the LIST, ADD, ENQUIRE, UPDATE, DELETE and SEARCH >>>>>> functions >>>>>> has a different screen structure, different behaviour, and may need >>>>>> different security considerations - somebody may be able to access >>>>>> the >>>>>> LIST, >>>>>> ENQUIRE and SEARCH screens, but not the ADD, UPDATE and DELETE >>>>>> screens. >>>>>> It >>>>>> is much easier to control access if they are separate >>>>>> functions/transactions. Instead of having code inside a huge >>>>>> function you >>>>>> have a database-driven Role Based Access Control (RBAC) system >>>>>> built into >>>>>> your framework which allows you to turn access ON or OFF at the >>>>>> function >>>>>> level simply by updating the database. Another advantage of this >>>>>> method >>>>>> is >>>>>> that if you don't have access to a function then it can be edited >>>>>> out of >>>>>> the >>>>>> display of menu buttons. >>>>>> >>>>> >>>>> So? None of this requires different scripts. >>>> >>>> Each screen should have its own script, and a LIST screen which shows >>>> summary data for many rows going across the page with column labels >>>> across >>>> the top is different from a detail screen (ADD, ENQUIRE, UPDATE, >>>> DELETE and >>>> SEARCH) which shows details for a single row going down the page with >>>> labels >>>> on the left and values on the right. This break is even more >>>> essential when >>>> there is simply too many fields for each row in a LIST screen. >>>> >>> >>> Why? Because your framework demands it be so? >> >> No, that is the way I have built applications since the 1980s when I was >> working for a software house. The other developers found it easier to >> write and maintain programs which had a single screen and function >> instead of programs which had multiple screens/functions. And the users >> liked it that way as well. >> > >You've been doing it that badly all this time? Not according to my fellow developers and paying customers. >>>>> Security can easily be handled via a function call, >>>> >>>> I have worked with such complications in the past, and I know from >>>> experience that having a single script which can perform several >>>> functions, >>>> then trying to make one or more of those functions inaccessible to the >>>> current user is a maintenance nightmare. You have to avoid calling >>>> code that >>>> shouldn't be executed, and avoid not calling code which should be >>>> executed. >>>> It is far simpler to split each function into a smaller dedicated >>>> script and >>>> have the framework decide whether to call the script or not than it >>>> is to >>>> call a script and afterwards decide that it's not actually allowed. >>>> >>> >>> I have too. It works great. And much easier to maintain than similar >>> code in multiple scripts. >> >> I disagree. Having a script that performs a single function is easier to >> maintain than a script which can perform multiple functions as you have >> to keep track of what function the user has selected, then ensure that >> the right code does get executed while the wrong code does not. I and my >> fellow developers have been through that scenario, which is why we all >> prefer the single-function-per-script approach. >> > >Yup, you have a script which displays a single form. What can be simpler? > >And if you and your developers thing it's easier to spread what is >effectively duplicate code across several scripts, then I see why you need >a framework. The amount of code which is actually generated by my framework is incredibly small. Common code is not duplicated, it is shared, either by being in a function or inherited from an abstract class. In my implementation of MVC I have reusable controllers, reusable views, and each table class can be used by several controller/view combinations. >>>>> and the only differences between LIST and UPDATE are whether the >>>>> fields >>>>> are read/write or not. Again, easily handled in one script. And all of >>>>> this can easily be handled in a class, for instance. >>>> >>>> I have been developing database applications in different languages for >>>> several decades, and in my experience having a single LIST screen >>>> which can >>>> also be used for ADD, ENQUIRE, UPDATE, DELETE and SEARCH only works for >>>> simple applications such as PhpMyAdmin. For real world applications >>>> used in >>>> the enterprise they require something more sophisticated, which is >>>> where >>>> your approach falls short. >>>> >>> >>> I have also. I first learned how to do it when working with CICS at >>> IBM, then later graduated to C++ programming. Classes do wonders in >>> such an environment. >> >> Classes by themselves are not a solution, it is the code within them, >> and how they are strung together, which provides the solution. I'm >> afraid that an application which has a single screen to perform the >> list, add, enquire, update, delete and search functions is no better >> than a general-purpose admin like phpMyadmin, and that is simply not >> good enough for sophisticated users with sophisticated needs. >> > >Yup, which all comes back to good design. > >But I didn't say it was a single screen which does all that - I said it was >a single script which performs it. And the more sophisticated the >application becomes, the more important it is to not duplicate your code in >multiple scripts (and the less appropriate a framework becomes). Lots of small scripts instead of a few large scripts does not equate to duplicated code, at least not in my universe. >I'm not against frameworks in general. They are ok for simple >applications. And even more ok for larger applications. >>>>> I know you believe frameworks are slicker than snot on a doorknob, but >>>>> they are not at all the only way to go. And in many cases there are >>>>> better ways. >>>>> >>>>>>>> If you have ever built an application which has evolved over the >>>>>>>> years >>>>>>>> to >>>>>>>> incorporate over 200 databases tables, 350 relationships and 1700 >>>>>>>> screens >>>>>>>> then you would appreciate such a time-saving feature. If, on the >>>>>>>> other >>>>>>>> hand, >>>>>>>> you have never built an application which has more than a dozen >>>>>>>> dinky >>>>>>>> little >>>>>>>> tables then you are unlikely to be using any sort of framework at >>>>>>>> all. >>>>>>>> >>>>>>> >>>>>>> A medium sized application. But you don't need a framework. A good >>>>>>> design does wonders. >>>>>> >>>>>> It may be medium to you, but not to many others. A proper framework >>>>>> will >>>>>> provide a lot, if not all, of the "plumbing" code for you, so the >>>>>> idea >>>>>> of >>>>>> writing an application with several hundreds of tables and >>>>>> thousands of >>>>>> transactions WITHOUT a framework where you have to write all that >>>>>> plumbing >>>>>> code yourself just strikes me as dumb. An efficient programmer aims >>>>>> to >>>>>> spend >>>>>> less time on the "plumbing" code and more time on the "payload". >>>>>> >>>>> >>>>> Yes, there are a lot of people here who don't know what a large >>>>> application is. But then if the application has "evolved" like you >>>>> indicate, I suspect it is highly inefficient in how it works. Such is >>>>> what happens when things "evolve" instead of being properly redesigned >>>>> when necessary. Frameworks encourage such "evolution". >>>>> >>>>> But I wouldn't even think of using a framework for something like >>>>> that. I >>>>> would use OO techniques. With the right stuff in your personal >>>>> libraries, >>>>> a lot of the work is already done. >>>> >>>> OO techniques on their own are insufficient. You can't get away from >>>> having >>>> to write enormous amounts of "plumbing" code if you don't use a >>>> framework. >>>> Using libraries is not much of a time saver as you still have to >>>> write the >>>> code to call the library functions. A framework is more than a >>>> collection of >>>> libraries as it also provides a series of runnable tools which help >>>> generate >>>> user transactions. Radicore is such a framework as you can start with >>>> nothing more than a database schema, and using the data dictionary >>>> you can >>>> generate the classes and transaction scripts to view and maintain a >>>> table in >>>> minutes without having to write a line of PHP, HTML or SQL. Can you >>>> do that >>>> with your libraries? >>>> >>> >>> They are in many cased much better than frameworks. There isn't that >>> much "plumbing" code. And you still have to write the code to fit into >>> the framework. >> >> When using the Radicore framework it provides all the plumbing code for >> you, you only have to add code to deal with business rules which go >> beyond what Radicore provides as standard. >> > >Ah, so you DO have to write PHP code, then. Only when necessary, and then only for the payload, not the plumbing. >>> The biggest problem with frameworks when the needs fall outside of the >>> frameworks capabilities - and quite frankly, most of the programming I >>> do is that way. But then there is that tendency to make the problem >>> fit the framework - instead of the solution fitting the problem. >> >> I write database applications, and I created the Radicore framework to >> help me build such applications, and it works much better than anything >> else I have seen. I can build these applications much faster than I >> could in the 1980s when using COBOL, and faster than I could in the >> 1990s when using UNIFACE. It removes a lot of the grunt work by >> providing as much of the plumbing as possible, which leaves me more time >> to spend on the payload, the code which delivers value to the customer. >> > >Ah, now I see why you think Radicore is slicker than snot on a doorknob. >But then creators always think their (whatever) is the best thing in the >world and applicable to every situation in the universe. > >I can build PHP code a lot faster than I could COBOL in the 70's or FORTRAN >in the 60's. But I can say the same for C++, also. > >>> As for generating all that code - my libraries do a lot of it. But no, >>> I can't do it without writing any code, and neither can you. How do >>> you validate your input, for instance? Or control the layout? >> >> Basic validation, such as dealing with NOT NULL fields, or checking that >> date fields contain dates and numeric fields contain numbers, etc, is >> all performed automatically by the framework. I don't have to write any >> code at all to perform basic data validation. Screen layouts are >> controlled by a simple screen structure script which is generated >> automatically when the transaction is generated from a pattern. It is >> very easy to modify this script to move fields around, or drop them from >> the screen altogether. >> > >Sure, those are easy. I don't have to do that either with my libraries. >But *I* control the screen layout, according to what the customer wants. I >don't let a framework tell the customer what the layout will be. You obviously haven't learnt to read yet. I said that my framework generates a default screen structure file which is used as a starting point. You can then customise this to your heart's content. >But one again are you saying you can do all that without writing any code? > >>> For instance, I have one commercial product I'm working on right now >>> where the User table had a bunch of fields. Not all fields will be >>> needed by all users. Which fields are used are found in a second >>> table. Can your framework display and validate fields from the first >>> table based on rows in the second table? Without writing a single line >>> of PHP code? >> >> Yes. As well as having a database table which allows access to >> individual transactions, I have another database table which modifies >> the access to individual fields within a transaction. A normally >> modifiable field can be changed to read-only, or it can be removed from >> the screen (for that user) altogether. >> > >And you can do that without writing any code? And make it dynamic, so when >the user changes the contents of the second table the screen changes also? > >> All security, whether it's access to individual transactions, or fields >> within transactions, is controlled by updating database tables using the >> screens provided, not by writing code. >> > >And how do you guarantee the entered data are valid? User data is initially validate by the framework, as I have already explained. Additional validation rules have to be defined by te programmer with code. >Yes, I know you think your toy is the answer to life, the universe and >everything. But it isn't. It works in my universe, but my universe is not centered around Uranus. -- Tony Marston http://www.tonymarston.net http://www.radicore.org
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-04-18 08:09 -0400 |
| Message-ID | <jmmauq$9ke$1@dont-email.me> |
| In reply to | #5556 |
On 4/18/2012 4:10 AM, Tony Marston wrote: > "Jerry Stuckle" wrote in message news:jmjfdk$vmp$1@dont-email.me... >> >> On 4/17/2012 4:18 AM, Tony Marston wrote: >>> "Jerry Stuckle" wrote in message news:jmhd8m$6jr$1@dont-email.me... >>>> >>>> On 4/16/2012 10:11 AM, Tony Marston wrote: >>>>> "Jerry Stuckle"<jstucklex@attglobal.net> wrote in message >>>>> news:jmh3iq$f4m$1@dont-email.me... >>>>>> On 4/16/2012 4:31 AM, Tony Marston wrote: >>>>>>> "Jerry Stuckle"<jstucklex@attglobal.net> wrote in message >>>>>>> news:jmeg9a$5pt$2@dont-email.me... >>>>>>>> On 4/15/2012 3:33 AM, Tony Marston wrote: >>>>>>>>> "Peter H. Coffin"<hellsop@ninehells.com> wrote in message >>>>>>>>> news:slrnjoj0b7.4ci.hellsop@nibelheim.ninehells.com... >>>>>>>>>> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote: >>>>>>>>>>> >>>>>>>>>>> "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). >>>>>>>>>> >>>>>>>>>> Wow.... All that. All Charles *really* needed to do was actually >>>>>>>>>> specify >>>>>>>>>> what column names he was fetching and 90% of the work he wants to >>>>>>>>>> eliminate GOES AWAY AUTOMATICALLY. >>>>>>>>> >>>>>>>>> But what if he has already built built a script (which should be >>>>>>>>> several >>>>>>>>> scripts by the way, one each for LIST, ADD, ENQUIRE, UPDATE, >>>>>>>>> DELETE and >>>>>>>>> SEARCH) then he changes the table's structure? Maybe by adding a >>>>>>>>> field, >>>>>>>>> removing a field, or changing a field's size or type? In a >>>>>>>>> non-framework >>>>>>>>> world you have to modify every script which references that table >>>>>>>>> - you >>>>>>>>> have >>>>>>>>> to change the screen definition, you have to change the validation >>>>>>>>> rules, >>>>>>>>> and you have to change the code which communicates with the >>>>>>>>> database. >>>>>>>>> With a >>>>>>>>> framework like Radicore - which was specifically built for >>>>>>>>> database >>>>>>>>> applications and not websites - all of that grunt work is >>>>>>>>> eliminated. >>>>>>>>> It >>>>>>>>> saves time, and time is money. >>>>>>>>> >>>>>>>> >>>>>>>> Not at all true. Ever heard of include(), for instance? And why >>>>>>>> does >>>>>>>> he >>>>>>>> need separate scripts for LIST, ADD, etc.? >>>>>>> >>>>>>> Because each of the LIST, ADD, ENQUIRE, UPDATE, DELETE and SEARCH >>>>>>> functions >>>>>>> has a different screen structure, different behaviour, and may need >>>>>>> different security considerations - somebody may be able to >>>>>>> access the >>>>>>> LIST, >>>>>>> ENQUIRE and SEARCH screens, but not the ADD, UPDATE and DELETE >>>>>>> screens. >>>>>>> It >>>>>>> is much easier to control access if they are separate >>>>>>> functions/transactions. Instead of having code inside a huge >>>>>>> function you >>>>>>> have a database-driven Role Based Access Control (RBAC) system >>>>>>> built into >>>>>>> your framework which allows you to turn access ON or OFF at the >>>>>>> function >>>>>>> level simply by updating the database. Another advantage of this >>>>>>> method >>>>>>> is >>>>>>> that if you don't have access to a function then it can be edited >>>>>>> out of >>>>>>> the >>>>>>> display of menu buttons. >>>>>>> >>>>>> >>>>>> So? None of this requires different scripts. >>>>> >>>>> Each screen should have its own script, and a LIST screen which shows >>>>> summary data for many rows going across the page with column labels >>>>> across >>>>> the top is different from a detail screen (ADD, ENQUIRE, UPDATE, >>>>> DELETE and >>>>> SEARCH) which shows details for a single row going down the page with >>>>> labels >>>>> on the left and values on the right. This break is even more >>>>> essential when >>>>> there is simply too many fields for each row in a LIST screen. >>>>> >>>> >>>> Why? Because your framework demands it be so? >>> >>> No, that is the way I have built applications since the 1980s when I was >>> working for a software house. The other developers found it easier to >>> write and maintain programs which had a single screen and function >>> instead of programs which had multiple screens/functions. And the users >>> liked it that way as well. >>> >> >> You've been doing it that badly all this time? > > Not according to my fellow developers and paying customers. > First rule is that customers don't know anything about good coding. And your fellow developers could easily be as bad as you. No credibility there. >>>>>> Security can easily be handled via a function call, >>>>> >>>>> I have worked with such complications in the past, and I know from >>>>> experience that having a single script which can perform several >>>>> functions, >>>>> then trying to make one or more of those functions inaccessible to the >>>>> current user is a maintenance nightmare. You have to avoid calling >>>>> code that >>>>> shouldn't be executed, and avoid not calling code which should be >>>>> executed. >>>>> It is far simpler to split each function into a smaller dedicated >>>>> script and >>>>> have the framework decide whether to call the script or not than it >>>>> is to >>>>> call a script and afterwards decide that it's not actually allowed. >>>>> >>>> >>>> I have too. It works great. And much easier to maintain than similar >>>> code in multiple scripts. >>> >>> I disagree. Having a script that performs a single function is easier to >>> maintain than a script which can perform multiple functions as you have >>> to keep track of what function the user has selected, then ensure that >>> the right code does get executed while the wrong code does not. I and my >>> fellow developers have been through that scenario, which is why we all >>> prefer the single-function-per-script approach. >>> >> >> Yup, you have a script which displays a single form. What can be simpler? >> >> And if you and your developers thing it's easier to spread what is >> effectively duplicate code across several scripts, then I see why you >> need a framework. > > The amount of code which is actually generated by my framework is > incredibly small. Common code is not duplicated, it is shared, either by > being in a function or inherited from an abstract class. In my > implementation of MVC I have reusable controllers, reusable views, and > each table class can be used by several controller/view combinations. > And how do you set/get individual fields? That is a large part of the code with mine generates. Other code is for forms generation and handling (two functions - one for generating all forms and one for processing data returned by $_GET/$_POST, WITH validation). And MVC is quite popular amongst some programmers, mainly those writing web apps. But it never really picked up in the business world for many reasons. >>>>>> and the only differences between LIST and UPDATE are whether the >>>>>> fields >>>>>> are read/write or not. Again, easily handled in one script. And >>>>>> all of >>>>>> this can easily be handled in a class, for instance. >>>>> >>>>> I have been developing database applications in different languages >>>>> for >>>>> several decades, and in my experience having a single LIST screen >>>>> which can >>>>> also be used for ADD, ENQUIRE, UPDATE, DELETE and SEARCH only works >>>>> for >>>>> simple applications such as PhpMyAdmin. For real world applications >>>>> used in >>>>> the enterprise they require something more sophisticated, which is >>>>> where >>>>> your approach falls short. >>>>> >>>> >>>> I have also. I first learned how to do it when working with CICS at >>>> IBM, then later graduated to C++ programming. Classes do wonders in >>>> such an environment. >>> >>> Classes by themselves are not a solution, it is the code within them, >>> and how they are strung together, which provides the solution. I'm >>> afraid that an application which has a single screen to perform the >>> list, add, enquire, update, delete and search functions is no better >>> than a general-purpose admin like phpMyadmin, and that is simply not >>> good enough for sophisticated users with sophisticated needs. >>> >> >> Yup, which all comes back to good design. >> >> But I didn't say it was a single screen which does all that - I said >> it was a single script which performs it. And the more sophisticated >> the application becomes, the more important it is to not duplicate >> your code in multiple scripts (and the less appropriate a framework >> becomes). > > Lots of small scripts instead of a few large scripts does not equate to > duplicated code, at least not in my universe. > >> I'm not against frameworks in general. They are ok for simple >> applications. > > And even more ok for larger applications. > You've obviously never been involved with a large application. Try something with > 3M LOC. Or when you have 100+ programmers working on a project for 3+ years. None of those use frameworks because the frameworks don't work. They are fine for simple applications. But your previous example of an application with > 200 tables and 350 relationships shows what can (and usually does) happen. >>>>>> I know you believe frameworks are slicker than snot on a doorknob, >>>>>> but >>>>>> they are not at all the only way to go. And in many cases there are >>>>>> better ways. >>>>>> >>>>>>>>> If you have ever built an application which has evolved over the >>>>>>>>> years >>>>>>>>> to >>>>>>>>> incorporate over 200 databases tables, 350 relationships and 1700 >>>>>>>>> screens >>>>>>>>> then you would appreciate such a time-saving feature. If, on the >>>>>>>>> other >>>>>>>>> hand, >>>>>>>>> you have never built an application which has more than a dozen >>>>>>>>> dinky >>>>>>>>> little >>>>>>>>> tables then you are unlikely to be using any sort of framework at >>>>>>>>> all. >>>>>>>>> >>>>>>>> >>>>>>>> A medium sized application. But you don't need a framework. A good >>>>>>>> design does wonders. >>>>>>> >>>>>>> It may be medium to you, but not to many others. A proper framework >>>>>>> will >>>>>>> provide a lot, if not all, of the "plumbing" code for you, so the >>>>>>> idea >>>>>>> of >>>>>>> writing an application with several hundreds of tables and >>>>>>> thousands of >>>>>>> transactions WITHOUT a framework where you have to write all that >>>>>>> plumbing >>>>>>> code yourself just strikes me as dumb. An efficient programmer >>>>>>> aims to >>>>>>> spend >>>>>>> less time on the "plumbing" code and more time on the "payload". >>>>>>> >>>>>> >>>>>> Yes, there are a lot of people here who don't know what a large >>>>>> application is. But then if the application has "evolved" like you >>>>>> indicate, I suspect it is highly inefficient in how it works. Such is >>>>>> what happens when things "evolve" instead of being properly >>>>>> redesigned >>>>>> when necessary. Frameworks encourage such "evolution". >>>>>> >>>>>> But I wouldn't even think of using a framework for something like >>>>>> that. I >>>>>> would use OO techniques. With the right stuff in your personal >>>>>> libraries, >>>>>> a lot of the work is already done. >>>>> >>>>> OO techniques on their own are insufficient. You can't get away from >>>>> having >>>>> to write enormous amounts of "plumbing" code if you don't use a >>>>> framework. >>>>> Using libraries is not much of a time saver as you still have to >>>>> write the >>>>> code to call the library functions. A framework is more than a >>>>> collection of >>>>> libraries as it also provides a series of runnable tools which help >>>>> generate >>>>> user transactions. Radicore is such a framework as you can start with >>>>> nothing more than a database schema, and using the data dictionary >>>>> you can >>>>> generate the classes and transaction scripts to view and maintain a >>>>> table in >>>>> minutes without having to write a line of PHP, HTML or SQL. Can you >>>>> do that >>>>> with your libraries? >>>>> >>>> >>>> They are in many cased much better than frameworks. There isn't that >>>> much "plumbing" code. And you still have to write the code to fit into >>>> the framework. >>> >>> When using the Radicore framework it provides all the plumbing code for >>> you, you only have to add code to deal with business rules which go >>> beyond what Radicore provides as standard. >>> >> >> Ah, so you DO have to write PHP code, then. > > Only when necessary, and then only for the payload, not the plumbing. > You said earlier you didn't have to write any code. Now the truth comes out. >>>> The biggest problem with frameworks when the needs fall outside of the >>>> frameworks capabilities - and quite frankly, most of the programming I >>>> do is that way. But then there is that tendency to make the problem >>>> fit the framework - instead of the solution fitting the problem. >>> >>> I write database applications, and I created the Radicore framework to >>> help me build such applications, and it works much better than anything >>> else I have seen. I can build these applications much faster than I >>> could in the 1980s when using COBOL, and faster than I could in the >>> 1990s when using UNIFACE. It removes a lot of the grunt work by >>> providing as much of the plumbing as possible, which leaves me more time >>> to spend on the payload, the code which delivers value to the customer. >>> >> >> Ah, now I see why you think Radicore is slicker than snot on a >> doorknob. But then creators always think their (whatever) is the best >> thing in the world and applicable to every situation in the universe. >> >> I can build PHP code a lot faster than I could COBOL in the 70's or >> FORTRAN in the 60's. But I can say the same for C++, also. >> >>>> As for generating all that code - my libraries do a lot of it. But no, >>>> I can't do it without writing any code, and neither can you. How do >>>> you validate your input, for instance? Or control the layout? >>> >>> Basic validation, such as dealing with NOT NULL fields, or checking that >>> date fields contain dates and numeric fields contain numbers, etc, is >>> all performed automatically by the framework. I don't have to write any >>> code at all to perform basic data validation. Screen layouts are >>> controlled by a simple screen structure script which is generated >>> automatically when the transaction is generated from a pattern. It is >>> very easy to modify this script to move fields around, or drop them from >>> the screen altogether. >>> >> >> Sure, those are easy. I don't have to do that either with my >> libraries. But *I* control the screen layout, according to what the >> customer wants. I don't let a framework tell the customer what the >> layout will be. > > You obviously haven't learnt to read yet. I said that my framework > generates a default screen structure file which is used as a starting > point. You can then customise this to your heart's content. > Ah, but you said you could do that without writing any code. Now your back-pedaling quite quickly. >> But one again are you saying you can do all that without writing any >> code? >> >>>> For instance, I have one commercial product I'm working on right now >>>> where the User table had a bunch of fields. Not all fields will be >>>> needed by all users. Which fields are used are found in a second >>>> table. Can your framework display and validate fields from the first >>>> table based on rows in the second table? Without writing a single line >>>> of PHP code? >>> >>> Yes. As well as having a database table which allows access to >>> individual transactions, I have another database table which modifies >>> the access to individual fields within a transaction. A normally >>> modifiable field can be changed to read-only, or it can be removed from >>> the screen (for that user) altogether. >>> >> >> And you can do that without writing any code? And make it dynamic, so >> when the user changes the contents of the second table the screen >> changes also? >> >>> All security, whether it's access to individual transactions, or fields >>> within transactions, is controlled by updating database tables using the >>> screens provided, not by writing code. >>> >> >> And how do you guarantee the entered data are valid? > > User data is initially validate by the framework, as I have already > explained. Additional validation rules have to be defined by te > programmer with code. > And how does it do that? How does it know, for instance, the needed rules for a password? Once again you said you didn't need to write any code. >> Yes, I know you think your toy is the answer to life, the universe and >> everything. But it isn't. > > It works in my universe, but my universe is not centered around Uranus. > That's true. You are in some alternate universe. Hopefully you never get a customer who knows something. -- ================== 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:27 +0100 |
| Message-ID | <f0Qjr.221591$o93.75144@fx05.am4> |
| In reply to | #5559 |
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message news:jmmauq$9ke$1@dont-email.me... > On 4/18/2012 4:10 AM, Tony Marston wrote: >> "Jerry Stuckle" wrote in message news:jmjfdk$vmp$1@dont-email.me... >>> >>> On 4/17/2012 4:18 AM, Tony Marston wrote: >>>> "Jerry Stuckle" wrote in message news:jmhd8m$6jr$1@dont-email.me... >>>>> >>>>> On 4/16/2012 10:11 AM, Tony Marston wrote: >>>>>> "Jerry Stuckle"<jstucklex@attglobal.net> wrote in message >>>>>> news:jmh3iq$f4m$1@dont-email.me... >>>>>>> On 4/16/2012 4:31 AM, Tony Marston wrote: >>>>>>>> "Jerry Stuckle"<jstucklex@attglobal.net> wrote in message >>>>>>>> news:jmeg9a$5pt$2@dont-email.me... >>>>>>>>> On 4/15/2012 3:33 AM, Tony Marston wrote: >>>>>>>>>> "Peter H. Coffin"<hellsop@ninehells.com> wrote in message >>>>>>>>>> news:slrnjoj0b7.4ci.hellsop@nibelheim.ninehells.com... >>>>>>>>>>> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote: >>>>>>>>>>>> >>>>>>>>>>>> "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). >>>>>>>>>>> >>>>>>>>>>> Wow.... All that. All Charles *really* needed to do was actually >>>>>>>>>>> specify >>>>>>>>>>> what column names he was fetching and 90% of the work he wants >>>>>>>>>>> to >>>>>>>>>>> eliminate GOES AWAY AUTOMATICALLY. >>>>>>>>>> >>>>>>>>>> But what if he has already built built a script (which should be >>>>>>>>>> several >>>>>>>>>> scripts by the way, one each for LIST, ADD, ENQUIRE, UPDATE, >>>>>>>>>> DELETE and >>>>>>>>>> SEARCH) then he changes the table's structure? Maybe by adding a >>>>>>>>>> field, >>>>>>>>>> removing a field, or changing a field's size or type? In a >>>>>>>>>> non-framework >>>>>>>>>> world you have to modify every script which references that table >>>>>>>>>> - you >>>>>>>>>> have >>>>>>>>>> to change the screen definition, you have to change the >>>>>>>>>> validation >>>>>>>>>> rules, >>>>>>>>>> and you have to change the code which communicates with the >>>>>>>>>> database. >>>>>>>>>> With a >>>>>>>>>> framework like Radicore - which was specifically built for >>>>>>>>>> database >>>>>>>>>> applications and not websites - all of that grunt work is >>>>>>>>>> eliminated. >>>>>>>>>> It >>>>>>>>>> saves time, and time is money. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Not at all true. Ever heard of include(), for instance? And why >>>>>>>>> does >>>>>>>>> he >>>>>>>>> need separate scripts for LIST, ADD, etc.? >>>>>>>> >>>>>>>> Because each of the LIST, ADD, ENQUIRE, UPDATE, DELETE and SEARCH >>>>>>>> functions >>>>>>>> has a different screen structure, different behaviour, and may need >>>>>>>> different security considerations - somebody may be able to >>>>>>>> access the >>>>>>>> LIST, >>>>>>>> ENQUIRE and SEARCH screens, but not the ADD, UPDATE and DELETE >>>>>>>> screens. >>>>>>>> It >>>>>>>> is much easier to control access if they are separate >>>>>>>> functions/transactions. Instead of having code inside a huge >>>>>>>> function you >>>>>>>> have a database-driven Role Based Access Control (RBAC) system >>>>>>>> built into >>>>>>>> your framework which allows you to turn access ON or OFF at the >>>>>>>> function >>>>>>>> level simply by updating the database. Another advantage of this >>>>>>>> method >>>>>>>> is >>>>>>>> that if you don't have access to a function then it can be edited >>>>>>>> out of >>>>>>>> the >>>>>>>> display of menu buttons. >>>>>>>> >>>>>>> >>>>>>> So? None of this requires different scripts. >>>>>> >>>>>> Each screen should have its own script, and a LIST screen which shows >>>>>> summary data for many rows going across the page with column labels >>>>>> across >>>>>> the top is different from a detail screen (ADD, ENQUIRE, UPDATE, >>>>>> DELETE and >>>>>> SEARCH) which shows details for a single row going down the page with >>>>>> labels >>>>>> on the left and values on the right. This break is even more >>>>>> essential when >>>>>> there is simply too many fields for each row in a LIST screen. >>>>>> >>>>> >>>>> Why? Because your framework demands it be so? >>>> >>>> No, that is the way I have built applications since the 1980s when I >>>> was >>>> working for a software house. The other developers found it easier to >>>> write and maintain programs which had a single screen and function >>>> instead of programs which had multiple screens/functions. And the users >>>> liked it that way as well. >>>> >>> >>> You've been doing it that badly all this time? >> >> Not according to my fellow developers and paying customers. >> > > First rule is that customers don't know anything about good coding. And > your fellow developers could easily be as bad as you. No credibility > there. Delivering code which satisfies the client takes a higher priority than writing code which satisfies other programmers. It is not possible to write code which satisfies EVERY programmer on the plant as they all have different ideas as to what "best practice" actually is. >>>>>>> Security can easily be handled via a function call, >>>>>> >>>>>> I have worked with such complications in the past, and I know from >>>>>> experience that having a single script which can perform several >>>>>> functions, >>>>>> then trying to make one or more of those functions inaccessible to >>>>>> the >>>>>> current user is a maintenance nightmare. You have to avoid calling >>>>>> code that >>>>>> shouldn't be executed, and avoid not calling code which should be >>>>>> executed. >>>>>> It is far simpler to split each function into a smaller dedicated >>>>>> script and >>>>>> have the framework decide whether to call the script or not than it >>>>>> is to >>>>>> call a script and afterwards decide that it's not actually allowed. >>>>>> >>>>> >>>>> I have too. It works great. And much easier to maintain than similar >>>>> code in multiple scripts. >>>> >>>> I disagree. Having a script that performs a single function is easier >>>> to >>>> maintain than a script which can perform multiple functions as you have >>>> to keep track of what function the user has selected, then ensure that >>>> the right code does get executed while the wrong code does not. I and >>>> my >>>> fellow developers have been through that scenario, which is why we all >>>> prefer the single-function-per-script approach. >>>> >>> >>> Yup, you have a script which displays a single form. What can be >>> simpler? >>> >>> And if you and your developers thing it's easier to spread what is >>> effectively duplicate code across several scripts, then I see why you >>> need a framework. >> >> The amount of code which is actually generated by my framework is >> incredibly small. Common code is not duplicated, it is shared, either by >> being in a function or inherited from an abstract class. In my >> implementation of MVC I have reusable controllers, reusable views, and >> each table class can be used by several controller/view combinations. >> > > And how do you set/get individual fields? That is a large part of the > code with mine generates. Other code is for forms generation and handling > (two functions - one for generating all forms and one for processing data > returned by $_GET/$_POST, WITH validation). I don't GET/SET individual fields - everything (by this I mean database data) goes in as an array, and everything comes out as an array. The idea of unpicking the array to inject every value individually strikes me as being inefficient, and therefore bad practice. > And MVC is quite popular amongst some programmers, mainly those writing > web apps. But it never really picked up in the business world for many > reasons. I write business applications, initially for the desktop but now for the web. I have tried many different paradigms in my long career, and I have found the 3-Tier architecture to be the best, so that it what I decided to use for my PHP framework. It just happens that after I wrote it a fellow programmer told me that I had also implemented the MVC pattern. >>>>>>> and the only differences between LIST and UPDATE are whether the >>>>>>> fields >>>>>>> are read/write or not. Again, easily handled in one script. And >>>>>>> all of >>>>>>> this can easily be handled in a class, for instance. >>>>>> >>>>>> I have been developing database applications in different languages >>>>>> for >>>>>> several decades, and in my experience having a single LIST screen >>>>>> which can >>>>>> also be used for ADD, ENQUIRE, UPDATE, DELETE and SEARCH only works >>>>>> for >>>>>> simple applications such as PhpMyAdmin. For real world applications >>>>>> used in >>>>>> the enterprise they require something more sophisticated, which is >>>>>> where >>>>>> your approach falls short. >>>>>> >>>>> >>>>> I have also. I first learned how to do it when working with CICS at >>>>> IBM, then later graduated to C++ programming. Classes do wonders in >>>>> such an environment. >>>> >>>> Classes by themselves are not a solution, it is the code within them, >>>> and how they are strung together, which provides the solution. I'm >>>> afraid that an application which has a single screen to perform the >>>> list, add, enquire, update, delete and search functions is no better >>>> than a general-purpose admin like phpMyadmin, and that is simply not >>>> good enough for sophisticated users with sophisticated needs. >>>> >>> >>> Yup, which all comes back to good design. >>> >>> But I didn't say it was a single screen which does all that - I said >>> it was a single script which performs it. And the more sophisticated >>> the application becomes, the more important it is to not duplicate >>> your code in multiple scripts (and the less appropriate a framework >>> becomes). >> >> Lots of small scripts instead of a few large scripts does not equate to >> duplicated code, at least not in my universe. >> >>> I'm not against frameworks in general. They are ok for simple >>> applications. >> >> And even more ok for larger applications. >> > > You've obviously never been involved with a large application. Try > something with > 3M LOC. Or when you have 100+ programmers working on a > project for 3+ years. 3M LOC is a meaningless figure if that contains a lot of duplicated code. If I achieved exactly the same result, but in only 1M LOC would that make my application smaller? It is what the application does which is important, not how many lines of code it takes to achieve it. > None of those use frameworks because the frameworks don't work. You mean that the frameworks which you have used didn't work. If you write an application with > 3M LOC *WITHOUT* using a framework, even if you have to build it yourself, then you are not an efficient programmer. > They are fine for simple applications. But your previous example of an > application with > 200 tables and 350 relationships shows what can (and > usually does) happen. An application is merely a collecton of individual components, and it is possible for a small application to grow larger simply by adding new components. A framework which helps you build new components quickly, and which provides as much of the plumbing code as possible so that the programmer can spend his valuable time by concentrating on the payload, should be of considerable benefit. >>>>>>> I know you believe frameworks are slicker than snot on a doorknob, >>>>>>> but >>>>>>> they are not at all the only way to go. And in many cases there are >>>>>>> better ways. >>>>>>> >>>>>>>>>> If you have ever built an application which has evolved over the >>>>>>>>>> years >>>>>>>>>> to >>>>>>>>>> incorporate over 200 databases tables, 350 relationships and 1700 >>>>>>>>>> screens >>>>>>>>>> then you would appreciate such a time-saving feature. If, on the >>>>>>>>>> other >>>>>>>>>> hand, >>>>>>>>>> you have never built an application which has more than a dozen >>>>>>>>>> dinky >>>>>>>>>> little >>>>>>>>>> tables then you are unlikely to be using any sort of framework at >>>>>>>>>> all. >>>>>>>>>> >>>>>>>>> >>>>>>>>> A medium sized application. But you don't need a framework. A good >>>>>>>>> design does wonders. >>>>>>>> >>>>>>>> It may be medium to you, but not to many others. A proper framework >>>>>>>> will >>>>>>>> provide a lot, if not all, of the "plumbing" code for you, so the >>>>>>>> idea >>>>>>>> of >>>>>>>> writing an application with several hundreds of tables and >>>>>>>> thousands of >>>>>>>> transactions WITHOUT a framework where you have to write all that >>>>>>>> plumbing >>>>>>>> code yourself just strikes me as dumb. An efficient programmer >>>>>>>> aims to >>>>>>>> spend >>>>>>>> less time on the "plumbing" code and more time on the "payload". >>>>>>>> >>>>>>> >>>>>>> Yes, there are a lot of people here who don't know what a large >>>>>>> application is. But then if the application has "evolved" like you >>>>>>> indicate, I suspect it is highly inefficient in how it works. Such >>>>>>> is >>>>>>> what happens when things "evolve" instead of being properly >>>>>>> redesigned >>>>>>> when necessary. Frameworks encourage such "evolution". >>>>>>> >>>>>>> But I wouldn't even think of using a framework for something like >>>>>>> that. I >>>>>>> would use OO techniques. With the right stuff in your personal >>>>>>> libraries, >>>>>>> a lot of the work is already done. >>>>>> >>>>>> OO techniques on their own are insufficient. You can't get away from >>>>>> having >>>>>> to write enormous amounts of "plumbing" code if you don't use a >>>>>> framework. >>>>>> Using libraries is not much of a time saver as you still have to >>>>>> write the >>>>>> code to call the library functions. A framework is more than a >>>>>> collection of >>>>>> libraries as it also provides a series of runnable tools which help >>>>>> generate >>>>>> user transactions. Radicore is such a framework as you can start with >>>>>> nothing more than a database schema, and using the data dictionary >>>>>> you can >>>>>> generate the classes and transaction scripts to view and maintain a >>>>>> table in >>>>>> minutes without having to write a line of PHP, HTML or SQL. Can you >>>>>> do that >>>>>> with your libraries? >>>>>> >>>>> >>>>> They are in many cased much better than frameworks. There isn't that >>>>> much "plumbing" code. And you still have to write the code to fit into >>>>> the framework. >>>> >>>> When using the Radicore framework it provides all the plumbing code for >>>> you, you only have to add code to deal with business rules which go >>>> beyond what Radicore provides as standard. >>>> >>> >>> Ah, so you DO have to write PHP code, then. >> >> Only when necessary, and then only for the payload, not the plumbing. >> > > You said earlier you didn't have to write any code. Now the truth comes > out. You're not reading what I wrote - I said that my framework generates a runnable but basic transaction with default behaviour. I only need to write any code when I want to change the defaults. >>>>> The biggest problem with frameworks when the needs fall outside of the >>>>> frameworks capabilities - and quite frankly, most of the programming I >>>>> do is that way. But then there is that tendency to make the problem >>>>> fit the framework - instead of the solution fitting the problem. >>>> >>>> I write database applications, and I created the Radicore framework to >>>> help me build such applications, and it works much better than anything >>>> else I have seen. I can build these applications much faster than I >>>> could in the 1980s when using COBOL, and faster than I could in the >>>> 1990s when using UNIFACE. It removes a lot of the grunt work by >>>> providing as much of the plumbing as possible, which leaves me more >>>> time >>>> to spend on the payload, the code which delivers value to the customer. >>>> >>> >>> Ah, now I see why you think Radicore is slicker than snot on a >>> doorknob. But then creators always think their (whatever) is the best >>> thing in the world and applicable to every situation in the universe. >>> >>> I can build PHP code a lot faster than I could COBOL in the 70's or >>> FORTRAN in the 60's. But I can say the same for C++, also. >>> >>>>> As for generating all that code - my libraries do a lot of it. But no, >>>>> I can't do it without writing any code, and neither can you. How do >>>>> you validate your input, for instance? Or control the layout? >>>> >>>> Basic validation, such as dealing with NOT NULL fields, or checking >>>> that >>>> date fields contain dates and numeric fields contain numbers, etc, is >>>> all performed automatically by the framework. I don't have to write any >>>> code at all to perform basic data validation. Screen layouts are >>>> controlled by a simple screen structure script which is generated >>>> automatically when the transaction is generated from a pattern. It is >>>> very easy to modify this script to move fields around, or drop them >>>> from >>>> the screen altogether. >>>> >>> >>> Sure, those are easy. I don't have to do that either with my >>> libraries. But *I* control the screen layout, according to what the >>> customer wants. I don't let a framework tell the customer what the >>> layout will be. >> >> You obviously haven't learnt to read yet. I said that my framework >> generates a default screen structure file which is used as a starting >> point. You can then customise this to your heart's content. >> > > Ah, but you said you could do that without writing any code. Now your > back-pedaling quite quickly. You're not reading what I wrote - I said that my framework generates a runnable but basic transaction with default behaviour. I only need to write any code when I want to change the defaults. >>> But one again are you saying you can do all that without writing any >>> code? >>> >>>>> For instance, I have one commercial product I'm working on right now >>>>> where the User table had a bunch of fields. Not all fields will be >>>>> needed by all users. Which fields are used are found in a second >>>>> table. Can your framework display and validate fields from the first >>>>> table based on rows in the second table? Without writing a single line >>>>> of PHP code? >>>> >>>> Yes. As well as having a database table which allows access to >>>> individual transactions, I have another database table which modifies >>>> the access to individual fields within a transaction. A normally >>>> modifiable field can be changed to read-only, or it can be removed from >>>> the screen (for that user) altogether. >>>> >>> >>> And you can do that without writing any code? And make it dynamic, so >>> when the user changes the contents of the second table the screen >>> changes also? >>> >>>> All security, whether it's access to individual transactions, or fields >>>> within transactions, is controlled by updating database tables using >>>> the >>>> screens provided, not by writing code. >>>> >>> >>> And how do you guarantee the entered data are valid? >> >> User data is initially validate by the framework, as I have already >> explained. Additional validation rules have to be defined by te >> programmer with code. >> > > And how does it do that? How does it know, for instance, the needed rules > for a password? Once again you said you didn't need to write any code. I have one password validation routine which I wrote many years ago. The validation rules - such as minimum length, the number of uppercase characters, the number of lowercase characters, the number of digits - is defined on a database table. Thus the rules can be changed by changing values on a screen and not by writing code. >>> Yes, I know you think your toy is the answer to life, the universe and >>> everything. But it isn't. >> >> It works in my universe, but my universe is not centered around Uranus. >> > > That's true. You are in some alternate universe. Hopefully you never get > a customer who knows something. Really? My biggest customer has been using my ERP application for over 4 years, and it has helped them triple their turnover to £2.5M per year while lowering their costs. > -- > ================== > Remove the "x" from my email address > Jerry Stuckle > JDS Computer Training Corp. > jstucklex@attglobal.net > ==================
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-04-19 08:41 -0400 |
| Message-ID | <jmp154$4tt$1@dont-email.me> |
| In reply to | #5569 |
On 4/19/2012 4:27 AM, Tony Marston wrote: > "Jerry Stuckle"<jstucklex@attglobal.net> wrote in message > news:jmmauq$9ke$1@dont-email.me... >> On 4/18/2012 4:10 AM, Tony Marston wrote: >>> "Jerry Stuckle" wrote in message news:jmjfdk$vmp$1@dont-email.me... >>>> >>>> On 4/17/2012 4:18 AM, Tony Marston wrote: >>>>> "Jerry Stuckle" wrote in message news:jmhd8m$6jr$1@dont-email.me... >>>>>> >>>>>> On 4/16/2012 10:11 AM, Tony Marston wrote: >>>>>>> "Jerry Stuckle"<jstucklex@attglobal.net> wrote in message >>>>>>> news:jmh3iq$f4m$1@dont-email.me... >>>>>>>> On 4/16/2012 4:31 AM, Tony Marston wrote: >>>>>>>>> "Jerry Stuckle"<jstucklex@attglobal.net> wrote in message >>>>>>>>> news:jmeg9a$5pt$2@dont-email.me... >>>>>>>>>> On 4/15/2012 3:33 AM, Tony Marston wrote: >>>>>>>>>>> "Peter H. Coffin"<hellsop@ninehells.com> wrote in message >>>>>>>>>>> news:slrnjoj0b7.4ci.hellsop@nibelheim.ninehells.com... >>>>>>>>>>>> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> "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). >>>>>>>>>>>> >>>>>>>>>>>> Wow.... All that. All Charles *really* needed to do was actually >>>>>>>>>>>> specify >>>>>>>>>>>> what column names he was fetching and 90% of the work he wants >>>>>>>>>>>> to >>>>>>>>>>>> eliminate GOES AWAY AUTOMATICALLY. >>>>>>>>>>> >>>>>>>>>>> But what if he has already built built a script (which should be >>>>>>>>>>> several >>>>>>>>>>> scripts by the way, one each for LIST, ADD, ENQUIRE, UPDATE, >>>>>>>>>>> DELETE and >>>>>>>>>>> SEARCH) then he changes the table's structure? Maybe by adding a >>>>>>>>>>> field, >>>>>>>>>>> removing a field, or changing a field's size or type? In a >>>>>>>>>>> non-framework >>>>>>>>>>> world you have to modify every script which references that table >>>>>>>>>>> - you >>>>>>>>>>> have >>>>>>>>>>> to change the screen definition, you have to change the >>>>>>>>>>> validation >>>>>>>>>>> rules, >>>>>>>>>>> and you have to change the code which communicates with the >>>>>>>>>>> database. >>>>>>>>>>> With a >>>>>>>>>>> framework like Radicore - which was specifically built for >>>>>>>>>>> database >>>>>>>>>>> applications and not websites - all of that grunt work is >>>>>>>>>>> eliminated. >>>>>>>>>>> It >>>>>>>>>>> saves time, and time is money. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Not at all true. Ever heard of include(), for instance? And why >>>>>>>>>> does >>>>>>>>>> he >>>>>>>>>> need separate scripts for LIST, ADD, etc.? >>>>>>>>> >>>>>>>>> Because each of the LIST, ADD, ENQUIRE, UPDATE, DELETE and SEARCH >>>>>>>>> functions >>>>>>>>> has a different screen structure, different behaviour, and may need >>>>>>>>> different security considerations - somebody may be able to >>>>>>>>> access the >>>>>>>>> LIST, >>>>>>>>> ENQUIRE and SEARCH screens, but not the ADD, UPDATE and DELETE >>>>>>>>> screens. >>>>>>>>> It >>>>>>>>> is much easier to control access if they are separate >>>>>>>>> functions/transactions. Instead of having code inside a huge >>>>>>>>> function you >>>>>>>>> have a database-driven Role Based Access Control (RBAC) system >>>>>>>>> built into >>>>>>>>> your framework which allows you to turn access ON or OFF at the >>>>>>>>> function >>>>>>>>> level simply by updating the database. Another advantage of this >>>>>>>>> method >>>>>>>>> is >>>>>>>>> that if you don't have access to a function then it can be edited >>>>>>>>> out of >>>>>>>>> the >>>>>>>>> display of menu buttons. >>>>>>>>> >>>>>>>> >>>>>>>> So? None of this requires different scripts. >>>>>>> >>>>>>> Each screen should have its own script, and a LIST screen which shows >>>>>>> summary data for many rows going across the page with column labels >>>>>>> across >>>>>>> the top is different from a detail screen (ADD, ENQUIRE, UPDATE, >>>>>>> DELETE and >>>>>>> SEARCH) which shows details for a single row going down the page with >>>>>>> labels >>>>>>> on the left and values on the right. This break is even more >>>>>>> essential when >>>>>>> there is simply too many fields for each row in a LIST screen. >>>>>>> >>>>>> >>>>>> Why? Because your framework demands it be so? >>>>> >>>>> No, that is the way I have built applications since the 1980s when I >>>>> was >>>>> working for a software house. The other developers found it easier to >>>>> write and maintain programs which had a single screen and function >>>>> instead of programs which had multiple screens/functions. And the users >>>>> liked it that way as well. >>>>> >>>> >>>> You've been doing it that badly all this time? >>> >>> Not according to my fellow developers and paying customers. >>> >> >> First rule is that customers don't know anything about good coding. And >> your fellow developers could easily be as bad as you. No credibility >> there. > > Delivering code which satisfies the client takes a higher priority than > writing code which satisfies other programmers. It is not possible to write > code which satisfies EVERY programmer on the plant as they all have > different ideas as to what "best practice" actually is. > It is when you're only doing simple stuff. REAL programmers concentrate on making their code MAINTAINABLE. And it IS possible to satisfy multiple programmers. But then you've never worked on anything even slightly complex, so you have no idea. >>>>>>>> Security can easily be handled via a function call, >>>>>>> >>>>>>> I have worked with such complications in the past, and I know from >>>>>>> experience that having a single script which can perform several >>>>>>> functions, >>>>>>> then trying to make one or more of those functions inaccessible to >>>>>>> the >>>>>>> current user is a maintenance nightmare. You have to avoid calling >>>>>>> code that >>>>>>> shouldn't be executed, and avoid not calling code which should be >>>>>>> executed. >>>>>>> It is far simpler to split each function into a smaller dedicated >>>>>>> script and >>>>>>> have the framework decide whether to call the script or not than it >>>>>>> is to >>>>>>> call a script and afterwards decide that it's not actually allowed. >>>>>>> >>>>>> >>>>>> I have too. It works great. And much easier to maintain than similar >>>>>> code in multiple scripts. >>>>> >>>>> I disagree. Having a script that performs a single function is easier >>>>> to >>>>> maintain than a script which can perform multiple functions as you have >>>>> to keep track of what function the user has selected, then ensure that >>>>> the right code does get executed while the wrong code does not. I and >>>>> my >>>>> fellow developers have been through that scenario, which is why we all >>>>> prefer the single-function-per-script approach. >>>>> >>>> >>>> Yup, you have a script which displays a single form. What can be >>>> simpler? >>>> >>>> And if you and your developers thing it's easier to spread what is >>>> effectively duplicate code across several scripts, then I see why you >>>> need a framework. >>> >>> The amount of code which is actually generated by my framework is >>> incredibly small. Common code is not duplicated, it is shared, either by >>> being in a function or inherited from an abstract class. In my >>> implementation of MVC I have reusable controllers, reusable views, and >>> each table class can be used by several controller/view combinations. >>> >> >> And how do you set/get individual fields? That is a large part of the >> code with mine generates. Other code is for forms generation and handling >> (two functions - one for generating all forms and one for processing data >> returned by $_GET/$_POST, WITH validation). > > I don't GET/SET individual fields - everything (by this I mean database > data) goes in as an array, and everything comes out as an array. The idea of > unpicking the array to inject every value individually strikes me as being > inefficient, and therefore bad practice. > Gee, which means you have to build an array for the whole object every time you need to change one property. Which means the rest of the program is also dependent on that object. More bloat. More complexity. >> And MVC is quite popular amongst some programmers, mainly those writing >> web apps. But it never really picked up in the business world for many >> reasons. > > I write business applications, initially for the desktop but now for the > web. I have tried many different paradigms in my long career, and I have > found the 3-Tier architecture to be the best, so that it what I decided to > use for my PHP framework. It just happens that after I wrote it a fellow > programmer told me that I had also implemented the MVC pattern. > It's an OK platform. But not suitable for every application. However, what did your "business applications" do? Room reservations for a hotel? Or another database application? >>>>>>>> and the only differences between LIST and UPDATE are whether the >>>>>>>> fields >>>>>>>> are read/write or not. Again, easily handled in one script. And >>>>>>>> all of >>>>>>>> this can easily be handled in a class, for instance. >>>>>>> >>>>>>> I have been developing database applications in different languages >>>>>>> for >>>>>>> several decades, and in my experience having a single LIST screen >>>>>>> which can >>>>>>> also be used for ADD, ENQUIRE, UPDATE, DELETE and SEARCH only works >>>>>>> for >>>>>>> simple applications such as PhpMyAdmin. For real world applications >>>>>>> used in >>>>>>> the enterprise they require something more sophisticated, which is >>>>>>> where >>>>>>> your approach falls short. >>>>>>> >>>>>> >>>>>> I have also. I first learned how to do it when working with CICS at >>>>>> IBM, then later graduated to C++ programming. Classes do wonders in >>>>>> such an environment. >>>>> >>>>> Classes by themselves are not a solution, it is the code within them, >>>>> and how they are strung together, which provides the solution. I'm >>>>> afraid that an application which has a single screen to perform the >>>>> list, add, enquire, update, delete and search functions is no better >>>>> than a general-purpose admin like phpMyadmin, and that is simply not >>>>> good enough for sophisticated users with sophisticated needs. >>>>> >>>> >>>> Yup, which all comes back to good design. >>>> >>>> But I didn't say it was a single screen which does all that - I said >>>> it was a single script which performs it. And the more sophisticated >>>> the application becomes, the more important it is to not duplicate >>>> your code in multiple scripts (and the less appropriate a framework >>>> becomes). >>> >>> Lots of small scripts instead of a few large scripts does not equate to >>> duplicated code, at least not in my universe. >>> >>>> I'm not against frameworks in general. They are ok for simple >>>> applications. >>> >>> And even more ok for larger applications. >>> >> >> You've obviously never been involved with a large application. Try >> something with> 3M LOC. Or when you have 100+ programmers working on a >> project for 3+ years. > > 3M LOC is a meaningless figure if that contains a lot of duplicated code. If > I achieved exactly the same result, but in only 1M LOC would that make my > application smaller? It is what the application does which is important, not > how many lines of code it takes to achieve it. > You couldn't do an application like this in 1M LOC. But then you've never worked on anything moderately complex, obviously. >> None of those use frameworks because the frameworks don't work. > > You mean that the frameworks which you have used didn't work. If you write > an application with> 3M LOC *WITHOUT* using a framework, even if you have > to build it yourself, then you are not an efficient programmer. > Nope. What kind of framework do you use for an OS, for instance? >> They are fine for simple applications. But your previous example of an >> application with> 200 tables and 350 relationships shows what can (and >> usually does) happen. > > An application is merely a collecton of individual components, and it is > possible for a small application to grow larger simply by adding new > components. A framework which helps you build new components quickly, and > which provides as much of the plumbing code as possible so that the > programmer can spend his valuable time by concentrating on the payload, > should be of considerable benefit. > An overly simplistic statement from someone who's never worked on any even moderately complex application. >>>>>>>> I know you believe frameworks are slicker than snot on a doorknob, >>>>>>>> but >>>>>>>> they are not at all the only way to go. And in many cases there are >>>>>>>> better ways. >>>>>>>> >>>>>>>>>>> If you have ever built an application which has evolved over the >>>>>>>>>>> years >>>>>>>>>>> to >>>>>>>>>>> incorporate over 200 databases tables, 350 relationships and 1700 >>>>>>>>>>> screens >>>>>>>>>>> then you would appreciate such a time-saving feature. If, on the >>>>>>>>>>> other >>>>>>>>>>> hand, >>>>>>>>>>> you have never built an application which has more than a dozen >>>>>>>>>>> dinky >>>>>>>>>>> little >>>>>>>>>>> tables then you are unlikely to be using any sort of framework at >>>>>>>>>>> all. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> A medium sized application. But you don't need a framework. A good >>>>>>>>>> design does wonders. >>>>>>>>> >>>>>>>>> It may be medium to you, but not to many others. A proper framework >>>>>>>>> will >>>>>>>>> provide a lot, if not all, of the "plumbing" code for you, so the >>>>>>>>> idea >>>>>>>>> of >>>>>>>>> writing an application with several hundreds of tables and >>>>>>>>> thousands of >>>>>>>>> transactions WITHOUT a framework where you have to write all that >>>>>>>>> plumbing >>>>>>>>> code yourself just strikes me as dumb. An efficient programmer >>>>>>>>> aims to >>>>>>>>> spend >>>>>>>>> less time on the "plumbing" code and more time on the "payload". >>>>>>>>> >>>>>>>> >>>>>>>> Yes, there are a lot of people here who don't know what a large >>>>>>>> application is. But then if the application has "evolved" like you >>>>>>>> indicate, I suspect it is highly inefficient in how it works. Such >>>>>>>> is >>>>>>>> what happens when things "evolve" instead of being properly >>>>>>>> redesigned >>>>>>>> when necessary. Frameworks encourage such "evolution". >>>>>>>> >>>>>>>> But I wouldn't even think of using a framework for something like >>>>>>>> that. I >>>>>>>> would use OO techniques. With the right stuff in your personal >>>>>>>> libraries, >>>>>>>> a lot of the work is already done. >>>>>>> >>>>>>> OO techniques on their own are insufficient. You can't get away from >>>>>>> having >>>>>>> to write enormous amounts of "plumbing" code if you don't use a >>>>>>> framework. >>>>>>> Using libraries is not much of a time saver as you still have to >>>>>>> write the >>>>>>> code to call the library functions. A framework is more than a >>>>>>> collection of >>>>>>> libraries as it also provides a series of runnable tools which help >>>>>>> generate >>>>>>> user transactions. Radicore is such a framework as you can start with >>>>>>> nothing more than a database schema, and using the data dictionary >>>>>>> you can >>>>>>> generate the classes and transaction scripts to view and maintain a >>>>>>> table in >>>>>>> minutes without having to write a line of PHP, HTML or SQL. Can you >>>>>>> do that >>>>>>> with your libraries? >>>>>>> >>>>>> >>>>>> They are in many cased much better than frameworks. There isn't that >>>>>> much "plumbing" code. And you still have to write the code to fit into >>>>>> the framework. >>>>> >>>>> When using the Radicore framework it provides all the plumbing code for >>>>> you, you only have to add code to deal with business rules which go >>>>> beyond what Radicore provides as standard. >>>>> >>>> >>>> Ah, so you DO have to write PHP code, then. >>> >>> Only when necessary, and then only for the payload, not the plumbing. >>> >> >> You said earlier you didn't have to write any code. Now the truth comes >> out. > > You're not reading what I wrote - I said that my framework generates a > runnable but basic transaction with default behaviour. I only need to write > any code when I want to change the defaults. > Yes, I did. Maybe you need to go back and read what you wrote. And now the truth is out and you have to backpedal. >>>>>> The biggest problem with frameworks when the needs fall outside of the >>>>>> frameworks capabilities - and quite frankly, most of the programming I >>>>>> do is that way. But then there is that tendency to make the problem >>>>>> fit the framework - instead of the solution fitting the problem. >>>>> >>>>> I write database applications, and I created the Radicore framework to >>>>> help me build such applications, and it works much better than anything >>>>> else I have seen. I can build these applications much faster than I >>>>> could in the 1980s when using COBOL, and faster than I could in the >>>>> 1990s when using UNIFACE. It removes a lot of the grunt work by >>>>> providing as much of the plumbing as possible, which leaves me more >>>>> time >>>>> to spend on the payload, the code which delivers value to the customer. >>>>> >>>> >>>> Ah, now I see why you think Radicore is slicker than snot on a >>>> doorknob. But then creators always think their (whatever) is the best >>>> thing in the world and applicable to every situation in the universe. >>>> >>>> I can build PHP code a lot faster than I could COBOL in the 70's or >>>> FORTRAN in the 60's. But I can say the same for C++, also. >>>> >>>>>> As for generating all that code - my libraries do a lot of it. But no, >>>>>> I can't do it without writing any code, and neither can you. How do >>>>>> you validate your input, for instance? Or control the layout? >>>>> >>>>> Basic validation, such as dealing with NOT NULL fields, or checking >>>>> that >>>>> date fields contain dates and numeric fields contain numbers, etc, is >>>>> all performed automatically by the framework. I don't have to write any >>>>> code at all to perform basic data validation. Screen layouts are >>>>> controlled by a simple screen structure script which is generated >>>>> automatically when the transaction is generated from a pattern. It is >>>>> very easy to modify this script to move fields around, or drop them >>>>> from >>>>> the screen altogether. >>>>> >>>> >>>> Sure, those are easy. I don't have to do that either with my >>>> libraries. But *I* control the screen layout, according to what the >>>> customer wants. I don't let a framework tell the customer what the >>>> layout will be. >>> >>> You obviously haven't learnt to read yet. I said that my framework >>> generates a default screen structure file which is used as a starting >>> point. You can then customise this to your heart's content. >>> >> >> Ah, but you said you could do that without writing any code. Now your >> back-pedaling quite quickly. > > You're not reading what I wrote - I said that my framework generates a > runnable but basic transaction with default behaviour. I only need to write > any code when I want to change the defaults. > See above. >>>> But one again are you saying you can do all that without writing any >>>> code? >>>> >>>>>> For instance, I have one commercial product I'm working on right now >>>>>> where the User table had a bunch of fields. Not all fields will be >>>>>> needed by all users. Which fields are used are found in a second >>>>>> table. Can your framework display and validate fields from the first >>>>>> table based on rows in the second table? Without writing a single line >>>>>> of PHP code? >>>>> >>>>> Yes. As well as having a database table which allows access to >>>>> individual transactions, I have another database table which modifies >>>>> the access to individual fields within a transaction. A normally >>>>> modifiable field can be changed to read-only, or it can be removed from >>>>> the screen (for that user) altogether. >>>>> >>>> >>>> And you can do that without writing any code? And make it dynamic, so >>>> when the user changes the contents of the second table the screen >>>> changes also? >>>> >>>>> All security, whether it's access to individual transactions, or fields >>>>> within transactions, is controlled by updating database tables using >>>>> the >>>>> screens provided, not by writing code. >>>>> >>>> >>>> And how do you guarantee the entered data are valid? >>> >>> User data is initially validate by the framework, as I have already >>> explained. Additional validation rules have to be defined by te >>> programmer with code. >>> >> >> And how does it do that? How does it know, for instance, the needed rules >> for a password? Once again you said you didn't need to write any code. > > I have one password validation routine which I wrote many years ago. The > validation rules - such as minimum length, the number of uppercase > characters, the number of lowercase characters, the number of digits - is > defined on a database table. Thus the rules can be changed by changing > values on a screen and not by writing code. > Bloat... How often do you need to change the rules? None of my customers have ever needed to. And what about existing passwords which don't follow the new rules? But again, more bloatware. >>>> Yes, I know you think your toy is the answer to life, the universe and >>>> everything. But it isn't. >>> >>> It works in my universe, but my universe is not centered around Uranus. >>> >> >> That's true. You are in some alternate universe. Hopefully you never get >> a customer who knows something. > > Really? My biggest customer has been using my ERP application for over 4 > years, and it has helped them triple their turnover to £2.5M per year while > lowering their costs. > So? They probably could have doubled that again by using an spreadsheet. Too bad your code held them back. >> -- >> ================== >> Remove the "x" from my email address >> Jerry Stuckle >> JDS Computer Training Corp. >> jstucklex@attglobal.net >> ================== > > -- ================== 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 10:10 +0100 |
| Message-ID | <bK9kr.300805$xD4.33148@fx06.am4> |
| In reply to | #5574 |
"Jerry Stuckle" wrote in message news:jmp154$4tt$1@dont-email.me... > >On 4/19/2012 4:27 AM, Tony Marston wrote: >> "Jerry Stuckle"<jstucklex@attglobal.net> wrote in message >> news:jmmauq$9ke$1@dont-email.me... <snip> >>>>> You've been doing it that badly all this time? >>>> >>>> Not according to my fellow developers and paying customers. >>>> >>> >>> First rule is that customers don't know anything about good coding. And >>> your fellow developers could easily be as bad as you. No credibility >>> there. >> >> Delivering code which satisfies the client takes a higher priority than >> writing code which satisfies other programmers. It is not possible to >> write >> code which satisfies EVERY programmer on the plant as they all have >> different ideas as to what "best practice" actually is. >> > >It is when you're only doing simple stuff. REAL programmers concentrate on >making their code MAINTAINABLE. You have no basis on which to make the statement that my code is unmaintainable. My code has been reviewed by many others, and the vast majority have nothing but compliments. >And it IS possible to satisfy multiple programmers. But then you've never >worked on anything even slightly complex, so you have no idea. So you are saying that an ERP system with 1700 transactions is not complex then you have a strange idea of what "complex" really means. <snip> >> I don't GET/SET individual fields - everything (by this I mean database >> data) goes in as an array, and everything comes out as an array. The idea >> of >> unpicking the array to inject every value individually strikes me as >> being >> inefficient, and therefore bad practice. >> > >Gee, which means you have to build an array for the whole object every time >you need to change one property. Which means the rest of the program is >also dependent on that object. More bloat. More complexity. I don't need to build an array as the array is provided for me. If it comes from the user it is the $_POST array. If it comes from the database it is an array of rows and columns. How is using an array which can contain any number of columns and values "more complex" than having to define a separate variable for each column, and a separate getter/setter for each column. My method uses LESS code therefore it is LESS complex. >>> And MVC is quite popular amongst some programmers, mainly those writing >>> web apps. But it never really picked up in the business world for many >>> reasons. >> >> I write business applications, initially for the desktop but now for the >> web. I have tried many different paradigms in my long career, and I have >> found the 3-Tier architecture to be the best, so that it what I decided >> to >> use for my PHP framework. It just happens that after I wrote it a fellow >> programmer told me that I had also implemented the MVC pattern. >> > >It's an OK platform. But not suitable for every application. However, >what did your "business applications" do? Room reservations for a hotel? >Or another database application? You obviously don't know what ERP means, do you? I write e-commerce applications, which means that I have to deal with customers and suppliers, organisations and people, products, product features, product prices, sales orders, purchase orders, transfer orders, invoices, credit notes, inventory, shipments, requests and requirements, work effort. It's also multi-lingual and multi-currency. <snip> >>> You've obviously never been involved with a large application. Try >>> something with> 3M LOC. Or when you have 100+ programmers working on a >>> project for 3+ years. >> >> 3M LOC is a meaningless figure if that contains a lot of duplicated code. >> If >> I achieved exactly the same result, but in only 1M LOC would that make my >> application smaller? It is what the application does which is important, >> not >> how many lines of code it takes to achieve it. >> > >You couldn't do an application like this in 1M LOC. But then you've never >worked on anything moderately complex, obviously. I don't copy and paste like you do, I write reusable functions. This means that I achieve similar results with less code. >>> None of those use frameworks because the frameworks don't work. >> >> You mean that the frameworks which you have used didn't work. If you >> write >> an application with> 3M LOC *WITHOUT* using a framework, even if you >> have >> to build it yourself, then you are not an efficient programmer. >> > >Nope. What kind of framework do you use for an OS, for instance? What has building an OS got to do with this conversation? This is a PHP newsgroup, which means that we are supposed to be talking about web applications written in PHP. >>> They are fine for simple applications. But your previous example of an >>> application with> 200 tables and 350 relationships shows what can (and >>> usually does) happen. >> >> An application is merely a collecton of individual components, and it is >> possible for a small application to grow larger simply by adding new >> components. A framework which helps you build new components quickly, and >> which provides as much of the plumbing code as possible so that the >> programmer can spend his valuable time by concentrating on the payload, >> should be of considerable benefit. >> > >An overly simplistic statement from someone who's never worked on any even >moderately complex application. My statement is not overly simplistic. Your statement is overly complex. <snip> >>>>>> When using the Radicore framework it provides all the plumbing code >>>>>> for >>>>>> you, you only have to add code to deal with business rules which go >>>>>> beyond what Radicore provides as standard. >>>>>> >>>>> >>>>> Ah, so you DO have to write PHP code, then. >>>> >>>> Only when necessary, and then only for the payload, not the plumbing. >>>> >>> >>> You said earlier you didn't have to write any code. Now the truth comes >>> out. >> >> You're not reading what I wrote - I said that my framework generates a >> runnable but basic transaction with default behaviour. I only need to >> write >> any code when I want to change the defaults. >> > >Yes, I did. Maybe you need to go back and read what you wrote. And now >the truth is out and you have to backpedal. I'm not back pedalling. I simply said that my framework generates basic yet runnable transactions with default behaviour. All the programmer has to do is change the defaults where necessary. <snip> >>> And how does it do that? How does it know, for instance, the needed >>> rules >>> for a password? Once again you said you didn't need to write any code. >> >> I have one password validation routine which I wrote many years ago. The >> validation rules - such as minimum length, the number of uppercase >> characters, the number of lowercase characters, the number of digits - is >> defined on a database table. Thus the rules can be changed by changing >> values on a screen and not by writing code. >> > >Bloat... How often do you need to change the rules? None of my customers >have ever needed to. The point is that any of my customers can change the password rules to whatever they want without me having to change any code. >And what about existing passwords which don't follow the new rules? The password rules only apply to new passwords. >But again, more bloatware. Wrong. I'm providing the ability for a customer to tailor the password rules to his own specifications without the need to make any code changes. How is that "bloatware"? >>>>> Yes, I know you think your toy is the answer to life, the universe and >>>>> everything. But it isn't. >>>> >>>> It works in my universe, but my universe is not centered around Uranus. >>>> >>> >>> That's true. You are in some alternate universe. Hopefully you never >>> get >>> a customer who knows something. >> >> Really? My biggest customer has been using my ERP application for over 4 >> years, and it has helped them triple their turnover to £2.5M per year >> while >> lowering their costs. >> > >So? They probably could have doubled that again by using an spreadsheet. >Too bad your code held them back. A single spreadsheet cannot be access simultaneously by multiple users, and a spreadsheet cannot possible handle the requirements of an ERP system. You need a proper database for that, and a proper database application to go with it. -- Tony Marston http://www.tonymarston.net http://www.radicore.org
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-04-20 08:09 -0400 |
| Message-ID | <jmrjmk$ubd$1@dont-email.me> |
| In reply to | #5587 |
On 4/20/2012 5:10 AM, Tony Marston wrote: > "Jerry Stuckle" wrote in message news:jmp154$4tt$1@dont-email.me... >> >> On 4/19/2012 4:27 AM, Tony Marston wrote: >>> "Jerry Stuckle"<jstucklex@attglobal.net> wrote in message >>> news:jmmauq$9ke$1@dont-email.me... > <snip> >>>>>> You've been doing it that badly all this time? >>>>> >>>>> Not according to my fellow developers and paying customers. >>>>> >>>> >>>> First rule is that customers don't know anything about good coding. And >>>> your fellow developers could easily be as bad as you. No credibility >>>> there. >>> >>> Delivering code which satisfies the client takes a higher priority than >>> writing code which satisfies other programmers. It is not possible to >>> write >>> code which satisfies EVERY programmer on the plant as they all have >>> different ideas as to what "best practice" actually is. >>> >> >> It is when you're only doing simple stuff. REAL programmers >> concentrate on making their code MAINTAINABLE. > > You have no basis on which to make the statement that my code is > unmaintainable. My code has been reviewed by many others, and the vast > majority have nothing but compliments. > Sure I do. Your description of it right here. And what is that "vast majority"? How many people actually use your code instead of just downloading it and tossing it out? >> And it IS possible to satisfy multiple programmers. But then you've >> never worked on anything even slightly complex, so you have no idea. > > So you are saying that an ERP system with 1700 transactions is not > complex then you have a strange idea of what "complex" really means. > Not what you wrote, it isn't. A real ERP system takes a lot of programmers a long time to develop. SAP is an example of a REAL ERP implementation. > <snip> >>> I don't GET/SET individual fields - everything (by this I mean database >>> data) goes in as an array, and everything comes out as an array. The >>> idea of >>> unpicking the array to inject every value individually strikes me as >>> being >>> inefficient, and therefore bad practice. >>> >> >> Gee, which means you have to build an array for the whole object every >> time you need to change one property. Which means the rest of the >> program is also dependent on that object. More bloat. More complexity. > > I don't need to build an array as the array is provided for me. If it > comes from the user it is the $_POST array. If it comes from the > database it is an array of rows and columns. > > How is using an array which can contain any number of columns and values > "more complex" than having to define a separate variable for each > column, and a separate getter/setter for each column. My method uses > LESS code therefore it is LESS complex. > And if the application needs to change one value without using the $_POST array, it has to build an entire array just to set the one value. Bloat! There are reasons for SET/GET methods. If you understood even the very basics of OO programming (one of which is encapsulation), you would know why they are needed. Less code does not mean less complexity. In fact, just the opposite can be true. >>>> And MVC is quite popular amongst some programmers, mainly those writing >>>> web apps. But it never really picked up in the business world for many >>>> reasons. >>> >>> I write business applications, initially for the desktop but now for the >>> web. I have tried many different paradigms in my long career, and I have >>> found the 3-Tier architecture to be the best, so that it what I >>> decided to >>> use for my PHP framework. It just happens that after I wrote it a fellow >>> programmer told me that I had also implemented the MVC pattern. >>> >> >> It's an OK platform. But not suitable for every application. However, >> what did your "business applications" do? Room reservations for a >> hotel? Or another database application? > > You obviously don't know what ERP means, do you? I write e-commerce > applications, which means that I have to deal with customers and > suppliers, organisations and people, products, product features, product > prices, sales orders, purchase orders, transfer orders, invoices, credit > notes, inventory, shipments, requests and requirements, work effort. > Unlike you, I DO know what ERP is, and I know what goes into a REAL ERP application. What you describe is an e-commerce application, available all over the internet. Not an ERP application. And if it were designed properly it wouldn't need over 200 tables. Bloat, bloat, bloat. > It's also multi-lingual and multi-currency. > Whoppee. No big thing there. > <snip> >>>> You've obviously never been involved with a large application. Try >>>> something with> 3M LOC. Or when you have 100+ programmers working on a >>>> project for 3+ years. >>> >>> 3M LOC is a meaningless figure if that contains a lot of duplicated >>> code. If >>> I achieved exactly the same result, but in only 1M LOC would that >>> make my >>> application smaller? It is what the application does which is >>> important, not >>> how many lines of code it takes to achieve it. >>> >> >> You couldn't do an application like this in 1M LOC. But then you've >> never worked on anything moderately complex, obviously. > > I don't copy and paste like you do, I write reusable functions. This > means that I achieve similar results with less code. > You only assume cut and paste. But you've never written a complex application, so you have no idea. >>>> None of those use frameworks because the frameworks don't work. >>> >>> You mean that the frameworks which you have used didn't work. If you >>> write >>> an application with> 3M LOC *WITHOUT* using a framework, even if you >>> have >>> to build it yourself, then you are not an efficient programmer. >>> >> >> Nope. What kind of framework do you use for an OS, for instance? > > What has building an OS got to do with this conversation? This is a PHP > newsgroup, which means that we are supposed to be talking about web > applications written in PHP. > An OS is an application. You claim all this knowledge of great techniques. So have you ever written an OS? Or how about a compiler? Even DOS 1.0 was more complex than anything you've written. >>>> They are fine for simple applications. But your previous example of an >>>> application with> 200 tables and 350 relationships shows what can (and >>>> usually does) happen. >>> >>> An application is merely a collecton of individual components, and it is >>> possible for a small application to grow larger simply by adding new >>> components. A framework which helps you build new components quickly, >>> and >>> which provides as much of the plumbing code as possible so that the >>> programmer can spend his valuable time by concentrating on the payload, >>> should be of considerable benefit. >>> >> >> An overly simplistic statement from someone who's never worked on any >> even moderately complex application. > > My statement is not overly simplistic. Your statement is overly complex. > Once again, you have no idea what an even moderately complex application is. All you've done is database applications and simple e-commerce (and called it ERP). > <snip> >>>>>>> When using the Radicore framework it provides all the plumbing >>>>>>> code for >>>>>>> you, you only have to add code to deal with business rules which go >>>>>>> beyond what Radicore provides as standard. >>>>>>> >>>>>> >>>>>> Ah, so you DO have to write PHP code, then. >>>>> >>>>> Only when necessary, and then only for the payload, not the plumbing. >>>>> >>>> >>>> You said earlier you didn't have to write any code. Now the truth comes >>>> out. >>> >>> You're not reading what I wrote - I said that my framework generates a >>> runnable but basic transaction with default behaviour. I only need to >>> write >>> any code when I want to change the defaults. >>> >> >> Yes, I did. Maybe you need to go back and read what you wrote. And now >> the truth is out and you have to backpedal. > > I'm not back pedalling. I simply said that my framework generates basic > yet runnable transactions with default behaviour. All the programmer has > to do is change the defaults where necessary. > Just continue backpedaling. > <snip> >>>> And how does it do that? How does it know, for instance, the needed >>>> rules >>>> for a password? Once again you said you didn't need to write any code. >>> >>> I have one password validation routine which I wrote many years ago. The >>> validation rules - such as minimum length, the number of uppercase >>> characters, the number of lowercase characters, the number of digits >>> - is >>> defined on a database table. Thus the rules can be changed by changing >>> values on a screen and not by writing code. >>> >> >> Bloat... How often do you need to change the rules? None of my >> customers have ever needed to. > > The point is that any of my customers can change the password rules to > whatever they want without me having to change any code. > And how often do they need to change the rules? None of my customers ever needed to. But then we discuss that up front, along with the pros and cons of different rule sets. The result is a simple one-line password verification rule - not bloatware. >> And what about existing passwords which don't follow the new rules? > > The password rules only apply to new passwords. > So then you have a mixture of both old and new rules. >> But again, more bloatware. > > Wrong. I'm providing the ability for a customer to tailor the password > rules to his own specifications without the need to make any code > changes. How is that "bloatware"? > Because it's code that adds unnecessary complexity to the code, for an unnecessary feature. But you've shown you're good at that. How many customers have actually demanded the need to change the rules? In over 30 years of programming for clients, none of mine have. >>>>>> Yes, I know you think your toy is the answer to life, the universe >>>>>> and >>>>>> everything. But it isn't. >>>>> >>>>> It works in my universe, but my universe is not centered around >>>>> Uranus. >>>>> >>>> >>>> That's true. You are in some alternate universe. Hopefully you never >>>> get >>>> a customer who knows something. >>> >>> Really? My biggest customer has been using my ERP application for over 4 >>> years, and it has helped them triple their turnover to £2.5M per year >>> while >>> lowering their costs. >>> >> >> So? They probably could have doubled that again by using an >> spreadsheet. Too bad your code held them back. > > A single spreadsheet cannot be access simultaneously by multiple users, > and a spreadsheet cannot possible handle the requirements of an ERP > system. You need a proper database for that, and a proper database > application to go with it. > Neither can your code. All your code is is a simple e-commerce system, one of many available on the internet. -- ================== 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 10:35 +0100 |
| Message-ID | <nbvkr.3746$Gd1.2455@fx02.am4> |
| In reply to | #5593 |
"Jerry Stuckle" wrote in message news:jmrjmk$ubd$1@dont-email.me... > >On 4/20/2012 5:10 AM, Tony Marston wrote: >> "Jerry Stuckle" wrote in message news:jmp154$4tt$1@dont-email.me... >>> >>> On 4/19/2012 4:27 AM, Tony Marston wrote: >>>> "Jerry Stuckle"<jstucklex@attglobal.net> wrote in message >>>> news:jmmauq$9ke$1@dont-email.me... >> <snip> >>>>>>> You've been doing it that badly all this time? >>>>>> >>>>>> Not according to my fellow developers and paying customers. >>>>>> >>>>> >>>>> First rule is that customers don't know anything about good coding. >>>>> And >>>>> your fellow developers could easily be as bad as you. No credibility >>>>> there. >>>> >>>> Delivering code which satisfies the client takes a higher priority than >>>> writing code which satisfies other programmers. It is not possible to >>>> write >>>> code which satisfies EVERY programmer on the plant as they all have >>>> different ideas as to what "best practice" actually is. >>>> >>> >>> It is when you're only doing simple stuff. REAL programmers >>> concentrate on making their code MAINTAINABLE. >> >> You have no basis on which to make the statement that my code is >> unmaintainable. My code has been reviewed by many others, and the vast >> majority have nothing but compliments. >> > >Sure I do. Your description of it right here. And what is that "vast >majority"? How many people actually use your code instead of just >downloading it and tossing it out? You cannot possibly tell if code is unmaintainable just by a simple description. You have to work with the code and actually maintain it before you can make that judgement. By "vast majority" I mean the "vast majority of people who send me emails about my work". For every 100 I receive 99 of them are complimentary. The other 1% are nothing but personal insults, sent anonymously and without valid return addresses. >>> And it IS possible to satisfy multiple programmers. But then you've >>> never worked on anything even slightly complex, so you have no idea. >> >> So you are saying that an ERP system with 1700 transactions is not >> complex then you have a strange idea of what "complex" really means. >> > >Not what you wrote, it isn't. A real ERP system takes a lot of programmers >a long time to develop. SAP is an example of a REAL ERP implementation. Not if you use the right framework. I started with Len Silverston's database models (as I mentioned in a previous post), and using the Radicore framework (which was specifically built to work from database schemas) I had the first version working in 6 months. This was because I didn't have to waste my time writing any code to carry out the boring and repetitive plumbing work. Instead I could concentrate on the payload - all the business rules and clever stuff. I certainly did not have to do any of that cut/paste/modify that you seem so fond of. >> <snip> >>>> I don't GET/SET individual fields - everything (by this I mean database >>>> data) goes in as an array, and everything comes out as an array. The >>>> idea of >>>> unpicking the array to inject every value individually strikes me as >>>> being >>>> inefficient, and therefore bad practice. >>>> >>> >>> Gee, which means you have to build an array for the whole object every >>> time you need to change one property. Which means the rest of the >>> program is also dependent on that object. More bloat. More complexity. >> >> I don't need to build an array as the array is provided for me. If it >> comes from the user it is the $_POST array. If it comes from the >> database it is an array of rows and columns. >> >> How is using an array which can contain any number of columns and values >> "more complex" than having to define a separate variable for each >> column, and a separate getter/setter for each column. My method uses >> LESS code therefore it is LESS complex. >> > >And if the application needs to change one value without using the $_POST >array, it has to build an entire array just to set the one value. Bloat! > >There are reasons for SET/GET methods. Just as there are reasons NOT to use them. I may insert data into an object with a setter, or I may use an argument on a method call. I find it much easier (ie: less coding) to insert the $_POST array as a complete array in a single method argument that to split it into its component parts and "set" each component one at a time. >If you understood even the very basics of OO programming (one of which is >encapsulation), you would know why they are needed. Getters and setters are NOT required for encapsulation. Encapsulation means *implementation* hiding, not *information* hiding. >Less code does not mean less complexity. In fact, just the opposite can be >true. Less code to write means less time to write it, less time to test (as the pre-written functions have already been tested), and less maintenance. That has been my experience over 30 years, and nothing you can say will change my opinion. >>>>> And MVC is quite popular amongst some programmers, mainly those >>>>> writing >>>>> web apps. But it never really picked up in the business world for many >>>>> reasons. >>>> >>>> I write business applications, initially for the desktop but now for >>>> the >>>> web. I have tried many different paradigms in my long career, and I >>>> have >>>> found the 3-Tier architecture to be the best, so that it what I >>>> decided to >>>> use for my PHP framework. It just happens that after I wrote it a >>>> fellow >>>> programmer told me that I had also implemented the MVC pattern. >>>> >>> >>> It's an OK platform. But not suitable for every application. However, >>> what did your "business applications" do? Room reservations for a >>> hotel? Or another database application? >> >> You obviously don't know what ERP means, do you? I write e-commerce >> applications, which means that I have to deal with customers and >> suppliers, organisations and people, products, product features, product >> prices, sales orders, purchase orders, transfer orders, invoices, credit >> notes, inventory, shipments, requests and requirements, work effort. >> > >Unlike you, I DO know what ERP is, and I know what goes into a REAL ERP >application. What you describe is an e-commerce application, available all >over the internet. Not an ERP application. A "real" ERP application is basically an order processing or order fulfilment system (also known as supply chain management. It starts with sales orders (which may be entered via a front-end website) and then helps the organisation process those orders through authorisation, generating pick lists, issuing from inventory, packaging, and shipping to the customer. It will also have to deal with customer returns, possible purchase orders to suppliers and receipts from suppliers, as well as invoicing and credit notes. Take a look at the definition of "ERP" at http://en.wikipedia.org/wiki/Enterprise_resource_planning and tell me I'm wrong. I don't have all the modules listed there, but SME's don't need all those modules. That describes the ERP system that a major client of mine has been using for 4 years. Simply having a website that accepts sales orders would be useless without a back-office system that allows them to get the goods shipped to the customer as quickly as possible. >And if it were designed properly it wouldn't need over 200 tables. Bloat, >bloat, bloat. You obviously don't know what it means to normalise data, so I presume you work with toy spreadsheets and not proper relational databases. >> It's also multi-lingual and multi-currency. >> > >Whoppee. No big thing there. It is if you want it done properly. I've seen other people's attempts at providing a multi-lingual and multi-currency system, and they have been quite hilarious. For my major client they have a single set of central databases which is maintained by my ERP system, but they have several websites which use different languages (German, Swedish and American) and different currencies (Sterling, Euros, Krona and Dollars) and which are fed from the same central databases. This means that any text which is obtained from the database has to be supplied in the correct language, and when orders are taken they are stored in Sterling but with the currency code and current exchange rate. When invoices are sent out they use the language and currency of the customer. When automated emails are sent out they use the language of the customer. If you have ever written such a system (which I seriously doubt) you would realise that it is far from being simple. >> <snip> >>>>> You've obviously never been involved with a large application. Try >>>>> something with> 3M LOC. Or when you have 100+ programmers working on a >>>>> project for 3+ years. >>>> >>>> 3M LOC is a meaningless figure if that contains a lot of duplicated >>>> code. If >>>> I achieved exactly the same result, but in only 1M LOC would that >>>> make my >>>> application smaller? It is what the application does which is >>>> important, not >>>> how many lines of code it takes to achieve it. >>>> >>> >>> You couldn't do an application like this in 1M LOC. But then you've >>> never worked on anything moderately complex, obviously. >> >> I don't copy and paste like you do, I write reusable functions. This >> means that I achieve similar results with less code. >> > >You only assume cut and paste. No I don't. You told me yourself that you regularly cut, paste and modify code. I don't need to do that as the code is defined once in a reusable function. >But you've never written a complex application, so you have no idea. Then our definitions of "complex" must surely differ. If you write applications where a single script can perform the functions of list, enquire, add, update, delete and search then it can only be a simple application in my book. I have been writing database applications for businesses for decades, and that "simple" approach would never be accepted. An application can be described as "complex" by looking at the volume of business rules which have to be implemented. Using the Radicore framework I can quickly generate working transactions which already handle the boring work of moving data between the database and the user interface, which leaves maximum time to spend on the payload, the business rules. >>>>> None of those use frameworks because the frameworks don't work. >>>> >>>> You mean that the frameworks which you have used didn't work. If you >>>> write >>>> an application with> 3M LOC *WITHOUT* using a framework, even if you >>>> have >>>> to build it yourself, then you are not an efficient programmer. >>>> >>> >>> Nope. What kind of framework do you use for an OS, for instance? >> >> What has building an OS got to do with this conversation? This is a PHP >> newsgroup, which means that we are supposed to be talking about web >> applications written in PHP. >> > >An OS is an application. You claim all this knowledge of great techniques. >So have you ever written an OS? Or how about a compiler? I repeat, this is a PHP newsgroup, which means that we are supposed to be talking about web applications written in PHP. Applications which are NOT web applications and NOT written in PHP are irrelevant. >Even DOS 1.0 was more complex than anything you've written. DOS is not a web application written in PHP, so it's irrelevant. >>>>> They are fine for simple applications. But your previous example of an >>>>> application with> 200 tables and 350 relationships shows what can (and >>>>> usually does) happen. >>>> >>>> An application is merely a collecton of individual components, and it >>>> is >>>> possible for a small application to grow larger simply by adding new >>>> components. A framework which helps you build new components quickly, >>>> and >>>> which provides as much of the plumbing code as possible so that the >>>> programmer can spend his valuable time by concentrating on the payload, >>>> should be of considerable benefit. >>>> >>> >>> An overly simplistic statement from someone who's never worked on any >>> even moderately complex application. >> >> My statement is not overly simplistic. Your statement is overly complex. >> > >Once again, you have no idea what an even moderately complex application >is. All you've done is database applications and simple e-commerce (and >called it ERP). You simply don't know what constitutes an ERP system, do you? Look at the wikipedia defintion at http://en.wikipedia.org/wiki/Enterprise_resource_planning >> <snip> >>>>>>>> When using the Radicore framework it provides all the plumbing >>>>>>>> code for >>>>>>>> you, you only have to add code to deal with business rules which go >>>>>>>> beyond what Radicore provides as standard. >>>>>>>> >>>>>>> >>>>>>> Ah, so you DO have to write PHP code, then. >>>>>> >>>>>> Only when necessary, and then only for the payload, not the plumbing. >>>>>> >>>>> >>>>> You said earlier you didn't have to write any code. Now the truth >>>>> comes >>>>> out. >>>> >>>> You're not reading what I wrote - I said that my framework generates a >>>> runnable but basic transaction with default behaviour. I only need to >>>> write >>>> any code when I want to change the defaults. >>>> >>> >>> Yes, I did. Maybe you need to go back and read what you wrote. And now >>> the truth is out and you have to backpedal. >> >> I'm not back pedalling. I simply said that my framework generates basic >> yet runnable transactions with default behaviour. All the programmer has >> to do is change the defaults where necessary. >> > >Just continue backpedaling. You don't know what back pedalling really means, do you? You're just like that character in Alice in Wonderalnd yoiu says "aword means whatever I want it to mean, nothing more and nothing less". >> <snip> >>>>> And how does it do that? How does it know, for instance, the needed >>>>> rules >>>>> for a password? Once again you said you didn't need to write any code. >>>> >>>> I have one password validation routine which I wrote many years ago. >>>> The >>>> validation rules - such as minimum length, the number of uppercase >>>> characters, the number of lowercase characters, the number of digits >>>> - is >>>> defined on a database table. Thus the rules can be changed by changing >>>> values on a screen and not by writing code. >>>> >>> >>> Bloat... How often do you need to change the rules? None of my >>> customers have ever needed to. >> >> The point is that any of my customers can change the password rules to >> whatever they want without me having to change any code. >> > >And how often do they need to change the rules? None of my customers ever >needed to. A customer may not need to change the rules once the system has been installed, but if you write a package that may be used by numerous customers then different rules may need to be specified when the system is installed. >But then we discuss that up front, along with the pros and cons of >different rule sets. The result is a simple one-line password verification >rule - not bloatware. >>> And what about existing passwords which don't follow the new rules? >> >> The password rules only apply to new passwords. >> > >So then you have a mixture of both old and new rules. No. Validation rules only apply when a value is entered, not read. If a user is forced to change his password after a number of days, or a number of logons, then any change in rules is only applied when he changes his password. A change in validation rules has no effect on existing passwords. >>> But again, more bloatware. >> >> Wrong. I'm providing the ability for a customer to tailor the password >> rules to his own specifications without the need to make any code >> changes. How is that "bloatware"? >> > >Because it's code that adds unnecessary complexity to the code, for an >unnecessary feature. But you've shown you're good at that. It is not an unnecessary feature. Different customers may have different rules, and I can satisfy those rules without having to change a single line of code. >How many customers have actually demanded the need to change the rules? In >over 30 years of programming for clients, none of mine have. None have had to demand such a facility for the simple reason that it is supplied as standard. >>>>>>> Yes, I know you think your toy is the answer to life, the universe >>>>>>> and >>>>>>> everything. But it isn't. >>>>>> >>>>>> It works in my universe, but my universe is not centered around >>>>>> Uranus. >>>>>> >>>>> >>>>> That's true. You are in some alternate universe. Hopefully you never >>>>> get >>>>> a customer who knows something. >>>> >>>> Really? My biggest customer has been using my ERP application for over >>>> 4 >>>> years, and it has helped them triple their turnover to £2.5M per year >>>> while >>>> lowering their costs. >>>> >>> >>> So? They probably could have doubled that again by using an >>> spreadsheet. Too bad your code held them back. >> >> A single spreadsheet cannot be access simultaneously by multiple users, >> and a spreadsheet cannot possible handle the requirements of an ERP >> system. You need a proper database for that, and a proper database >> application to go with it. >> > >Neither can your code. All your code is is a simple e-commerce system, one >of many available on the internet. I have looked at the documentation for several of these ecommerce packages, and I have never seen anything mentioned about those functions which are used only by members of staff which enable them to process the sales orders. These ecommerce packages concentrate only on the front-end website and totally ignore the back-end administrative functions. The major customer of my ERP system took a look at various ecommerce packages before deciding that they weren't good enough, which is why I was asked to design and build a "proper" system for them. -- Tony Marston http://www.tonymarston.net http://www.radicore.org
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-04-21 06:21 -0400 |
| Message-ID | <jmu1nc$fui$1@dont-email.me> |
| In reply to | #5622 |
On 4/21/2012 5:35 AM, Tony Marston wrote: > "Jerry Stuckle" wrote in message news:jmrjmk$ubd$1@dont-email.me... >> >> On 4/20/2012 5:10 AM, Tony Marston wrote: >>> "Jerry Stuckle" wrote in message news:jmp154$4tt$1@dont-email.me... >>>> >>>> On 4/19/2012 4:27 AM, Tony Marston wrote: >>>>> "Jerry Stuckle"<jstucklex@attglobal.net> wrote in message >>>>> news:jmmauq$9ke$1@dont-email.me... >>> <snip> >>>>>>>> You've been doing it that badly all this time? >>>>>>> >>>>>>> Not according to my fellow developers and paying customers. >>>>>>> >>>>>> >>>>>> First rule is that customers don't know anything about good >>>>>> coding. And >>>>>> your fellow developers could easily be as bad as you. No credibility >>>>>> there. >>>>> >>>>> Delivering code which satisfies the client takes a higher priority >>>>> than >>>>> writing code which satisfies other programmers. It is not possible to >>>>> write >>>>> code which satisfies EVERY programmer on the plant as they all have >>>>> different ideas as to what "best practice" actually is. >>>>> >>>> >>>> It is when you're only doing simple stuff. REAL programmers >>>> concentrate on making their code MAINTAINABLE. >>> >>> You have no basis on which to make the statement that my code is >>> unmaintainable. My code has been reviewed by many others, and the vast >>> majority have nothing but compliments. >>> >> >> Sure I do. Your description of it right here. And what is that "vast >> majority"? How many people actually use your code instead of just >> downloading it and tossing it out? > > You cannot possibly tell if code is unmaintainable just by a simple > description. You have to work with the code and actually maintain it > before you can make that judgement. > From your description, any good programmer can tell your code is crap. Only those like yourself can't see crap when it's described. > By "vast majority" I mean the "vast majority of people who send me > emails about my work". For every 100 I receive 99 of them are > complimentary. The other 1% are nothing but personal insults, sent > anonymously and without valid return addresses. > Yea, right. And what is the experience of those programmers? PHP programmers as a whole are not known for their intelligence or competence. In fact, just the opposite is true. But then you're a great example of the latter. >>>> And it IS possible to satisfy multiple programmers. But then you've >>>> never worked on anything even slightly complex, so you have no idea. >>> >>> So you are saying that an ERP system with 1700 transactions is not >>> complex then you have a strange idea of what "complex" really means. >>> >> >> Not what you wrote, it isn't. A real ERP system takes a lot of >> programmers a long time to develop. SAP is an example of a REAL ERP >> implementation. > > Not if you use the right framework. I started with Len Silverston's > database models (as I mentioned in a previous post), and using the > Radicore framework (which was specifically built to work from database > schemas) I had the first version working in 6 months. This was because I > didn't have to waste my time writing any code to carry out the boring > and repetitive plumbing work. Instead I could concentrate on the payload > - all the business rules and clever stuff. I certainly did not have to > do any of that cut/paste/modify that you seem so fond of. > Horse hockey. You don't have an ERP system. You don't even know what an ERP system is, and have never seen a real one. You've got a simple order entry/tracking system. Any competent programmer can do the same in a short time. >>> <snip> >>>>> I don't GET/SET individual fields - everything (by this I mean >>>>> database >>>>> data) goes in as an array, and everything comes out as an array. The >>>>> idea of >>>>> unpicking the array to inject every value individually strikes me as >>>>> being >>>>> inefficient, and therefore bad practice. >>>>> >>>> >>>> Gee, which means you have to build an array for the whole object every >>>> time you need to change one property. Which means the rest of the >>>> program is also dependent on that object. More bloat. More complexity. >>> >>> I don't need to build an array as the array is provided for me. If it >>> comes from the user it is the $_POST array. If it comes from the >>> database it is an array of rows and columns. >>> >>> How is using an array which can contain any number of columns and values >>> "more complex" than having to define a separate variable for each >>> column, and a separate getter/setter for each column. My method uses >>> LESS code therefore it is LESS complex. >>> >> >> And if the application needs to change one value without using the >> $_POST array, it has to build an entire array just to set the one >> value. Bloat! >> >> There are reasons for SET/GET methods. > > Just as there are reasons NOT to use them. I may insert data into an > object with a setter, or I may use an argument on a method call. I find > it much easier (ie: less coding) to insert the $_POST array as a > complete array in a single method argument that to split it into its > component parts and "set" each component one at a time. > What do you think a setter is if it's not a method? And you never have answered how the programmer can change one property without building a whole array. Or get a single property? Also, the presence of set/get methods does not preclude the parsing of arrays. I have both, for instance. >> If you understood even the very basics of OO programming (one of which >> is encapsulation), you would know why they are needed. > > Getters and setters are NOT required for encapsulation. Encapsulation > means *implementation* hiding, not *information* hiding. > Yes, and the properties of the class (i.e. variables) are part of the implementation. >> Less code does not mean less complexity. In fact, just the opposite >> can be true. > > Less code to write means less time to write it, less time to test (as > the pre-written functions have already been tested), and less > maintenance. That has been my experience over 30 years, and nothing you > can say will change my opinion. > That also is not necessarily true. Yes, pre-written functions are great. That's why I use them in my code generator. But less code can mean MORE complexity. However, you've never worked on anything non-trivial, so you wouldn't understand. >>>>>> And MVC is quite popular amongst some programmers, mainly those >>>>>> writing >>>>>> web apps. But it never really picked up in the business world for >>>>>> many >>>>>> reasons. >>>>> >>>>> I write business applications, initially for the desktop but now >>>>> for the >>>>> web. I have tried many different paradigms in my long career, and I >>>>> have >>>>> found the 3-Tier architecture to be the best, so that it what I >>>>> decided to >>>>> use for my PHP framework. It just happens that after I wrote it a >>>>> fellow >>>>> programmer told me that I had also implemented the MVC pattern. >>>>> >>>> >>>> It's an OK platform. But not suitable for every application. However, >>>> what did your "business applications" do? Room reservations for a >>>> hotel? Or another database application? >>> >>> You obviously don't know what ERP means, do you? I write e-commerce >>> applications, which means that I have to deal with customers and >>> suppliers, organisations and people, products, product features, product >>> prices, sales orders, purchase orders, transfer orders, invoices, credit >>> notes, inventory, shipments, requests and requirements, work effort. >>> >> >> Unlike you, I DO know what ERP is, and I know what goes into a REAL >> ERP application. What you describe is an e-commerce application, >> available all over the internet. Not an ERP application. > > A "real" ERP application is basically an order processing or order > fulfilment system (also known as supply chain management. It starts with > sales orders (which may be entered via a front-end website) and then > helps the organisation process those orders through authorisation, > generating pick lists, issuing from inventory, packaging, and shipping > to the customer. It will also have to deal with customer returns, > possible purchase orders to suppliers and receipts from suppliers, as > well as invoicing and credit notes. > No, a REAL ERP application does a lot more than that. What you describe is an order entry/tracking system. A real ERP system also does all the accounting (including taxes), payroll, benefits, budgeting and all kinds of things. But then you've never seen a real ERP system, that's obvious. Your order entry/tracking system doesn't even begin to approach the capabilities of even the most limited ERP system. > Take a look at the definition of "ERP" at > http://en.wikipedia.org/wiki/Enterprise_resource_planning and tell me > I'm wrong. I don't have all the modules listed there, but SME's don't > need all those modules. > I suggest you read it. An ERP system HAS all the modules. You can't pick and choose. It's an integrated system. All you have is a simple order entry/tracking system. > That describes the ERP system that a major client of mine has been using > for 4 years. Simply having a website that accepts sales orders would be > useless without a back-office system that allows them to get the goods > shipped to the customer as quickly as possible. > All you have is a simple order entry/tracking system. >> And if it were designed properly it wouldn't need over 200 tables. >> Bloat, bloat, bloat. > > You obviously don't know what it means to normalise data, so I presume > you work with toy spreadsheets and not proper relational databases. > I was normalizing data long before you knew what relational databases were - back in the early 80's. But your customer could do just as well with an excel spreadsheet. >>> It's also multi-lingual and multi-currency. >>> >> >> Whoppee. No big thing there. > > It is if you want it done properly. I've seen other people's attempts at > providing a multi-lingual and multi-currency system, and they have been > quite hilarious. For my major client they have a single set of central > databases which is maintained by my ERP system, but they have several > websites which use different languages (German, Swedish and American) > and different currencies (Sterling, Euros, Krona and Dollars) and which > are fed from the same central databases. This means that any text which > is obtained from the database has to be supplied in the correct > language, and when orders are taken they are stored in Sterling but with > the currency code and current exchange rate. > Only a big thing for you, obviously. Not for any competent programmer. And you do not have an ERP system. All you have is a simple order entry/tracking system. > When invoices are sent out they use the language and currency of the > customer. > No big problem there, either, for a competent programmer. But you seem to think it's a really big thing. That speaks wonders of your "competence". > When automated emails are sent out they use the language of the customer. > Again, no big thing. > If you have ever written such a system (which I seriously doubt) you > would realise that it is far from being simple. > Sorry to say, but I was doing it in the 80's on mainframes when working for IBM. No big thing. BTW - do you do Katakana? Now that gets a bit more difficult! >>> <snip> >>>>>> You've obviously never been involved with a large application. Try >>>>>> something with> 3M LOC. Or when you have 100+ programmers working >>>>>> on a >>>>>> project for 3+ years. >>>>> >>>>> 3M LOC is a meaningless figure if that contains a lot of duplicated >>>>> code. If >>>>> I achieved exactly the same result, but in only 1M LOC would that >>>>> make my >>>>> application smaller? It is what the application does which is >>>>> important, not >>>>> how many lines of code it takes to achieve it. >>>>> >>>> >>>> You couldn't do an application like this in 1M LOC. But then you've >>>> never worked on anything moderately complex, obviously. >>> >>> I don't copy and paste like you do, I write reusable functions. This >>> means that I achieve similar results with less code. >>> >> >> You only assume cut and paste. > > No I don't. You told me yourself that you regularly cut, paste and > modify code. I don't need to do that as the code is defined once in a > reusable function. > Exactly. But that's not duplicated code. It's starting with a code template and modifying it to suit my needs. That way you don't need to start from scratch every time. >> But you've never written a complex application, so you have no idea. > > Then our definitions of "complex" must surely differ. If you write > applications where a single script can perform the functions of list, > enquire, add, update, delete and search then it can only be a simple > application in my book. I have been writing database applications for > businesses for decades, and that "simple" approach would never be accepted. > Sure, a single CLASS can do all that. It works great. Now let's see how many OS's you've worked on. Or compilers. > An application can be described as "complex" by looking at the volume of > business rules which have to be implemented. Using the Radicore > framework I can quickly generate working transactions which already > handle the boring work of moving data between the database and the user > interface, which leaves maximum time to spend on the payload, the > business rules. > You can claim that for your simple database applications. But then you need to do that to satisfy yourself you're working on "complex" applications. Those of us who have worked on truly complex applications know better. >>>>>> None of those use frameworks because the frameworks don't work. >>>>> >>>>> You mean that the frameworks which you have used didn't work. If you >>>>> write >>>>> an application with> 3M LOC *WITHOUT* using a framework, even if you >>>>> have >>>>> to build it yourself, then you are not an efficient programmer. >>>>> >>>> >>>> Nope. What kind of framework do you use for an OS, for instance? >>> >>> What has building an OS got to do with this conversation? This is a PHP >>> newsgroup, which means that we are supposed to be talking about web >>> applications written in PHP. >>> >> >> An OS is an application. You claim all this knowledge of great >> techniques. So have you ever written an OS? Or how about a compiler? > > I repeat, this is a PHP newsgroup, which means that we are supposed to > be talking about web applications written in PHP. > So? You've claimed you've worked on "database applications for decades". That's long before PHP existed. You opened the door. Now you're backpedaling. Typical. > Applications which are NOT web applications and NOT written in PHP are > irrelevant. > Only because all you do are trivial applications in PHP - and you do it poorly, at that. >> Even DOS 1.0 was more complex than anything you've written. > > DOS is not a web application written in PHP, so it's irrelevant. > Nope, and neither were the "decades of database applications" you claimed to have written in the very post I'm replying to. Nor is database normalization (which you also claimed to know how to do properly - which I also doubt) in that same post. But the incompetent need to have it both ways - ignore the rules when it benefits them but claim it's off topic when the rules don't suit them. >>>>>> They are fine for simple applications. But your previous example >>>>>> of an >>>>>> application with> 200 tables and 350 relationships shows what can >>>>>> (and >>>>>> usually does) happen. >>>>> >>>>> An application is merely a collecton of individual components, and >>>>> it is >>>>> possible for a small application to grow larger simply by adding new >>>>> components. A framework which helps you build new components quickly, >>>>> and >>>>> which provides as much of the plumbing code as possible so that the >>>>> programmer can spend his valuable time by concentrating on the >>>>> payload, >>>>> should be of considerable benefit. >>>>> >>>> >>>> An overly simplistic statement from someone who's never worked on any >>>> even moderately complex application. >>> >>> My statement is not overly simplistic. Your statement is overly complex. >>> >> >> Once again, you have no idea what an even moderately complex >> application is. All you've done is database applications and simple >> e-commerce (and called it ERP). > > You simply don't know what constitutes an ERP system, do you? Look at > the wikipedia defintion at > http://en.wikipedia.org/wiki/Enterprise_resource_planning > I do, much more than you do. And all you've got is a simple order entry/tracking system. An ERP system includes all those modules - that's why it's called ENTERPRISE RESOURCE STEM - not order entry/tracking. >>> <snip> >>>>>>>>> When using the Radicore framework it provides all the plumbing >>>>>>>>> code for >>>>>>>>> you, you only have to add code to deal with business rules >>>>>>>>> which go >>>>>>>>> beyond what Radicore provides as standard. >>>>>>>>> >>>>>>>> >>>>>>>> Ah, so you DO have to write PHP code, then. >>>>>>> >>>>>>> Only when necessary, and then only for the payload, not the >>>>>>> plumbing. >>>>>>> >>>>>> >>>>>> You said earlier you didn't have to write any code. Now the truth >>>>>> comes >>>>>> out. >>>>> >>>>> You're not reading what I wrote - I said that my framework generates a >>>>> runnable but basic transaction with default behaviour. I only need to >>>>> write >>>>> any code when I want to change the defaults. >>>>> >>>> >>>> Yes, I did. Maybe you need to go back and read what you wrote. And now >>>> the truth is out and you have to backpedal. >>> >>> I'm not back pedalling. I simply said that my framework generates basic >>> yet runnable transactions with default behaviour. All the programmer has >>> to do is change the defaults where necessary. >>> >> >> Just continue backpedaling. > > You don't know what back pedalling really means, do you? You're just > like that character in Alice in Wonderalnd yoiu says "aword means > whatever I want it to mean, nothing more and nothing less". > Nope, you just continue to backpedal then you're called on it, you try to change the meaning. >>> <snip> >>>>>> And how does it do that? How does it know, for instance, the needed >>>>>> rules >>>>>> for a password? Once again you said you didn't need to write any >>>>>> code. >>>>> >>>>> I have one password validation routine which I wrote many years >>>>> ago. The >>>>> validation rules - such as minimum length, the number of uppercase >>>>> characters, the number of lowercase characters, the number of digits >>>>> - is >>>>> defined on a database table. Thus the rules can be changed by changing >>>>> values on a screen and not by writing code. >>>>> >>>> >>>> Bloat... How often do you need to change the rules? None of my >>>> customers have ever needed to. >>> >>> The point is that any of my customers can change the password rules to >>> whatever they want without me having to change any code. >>> >> >> And how often do they need to change the rules? None of my customers >> ever needed to. > > A customer may not need to change the rules once the system has been > installed, but if you write a package that may be used by numerous > customers then different rules may need to be specified when the system > is installed. > Bloat, bloat, bloat. >> But then we discuss that up front, along with the pros and cons of >> different rule sets. The result is a simple one-line password >> verification rule - not bloatware. > >>>> And what about existing passwords which don't follow the new rules? >>> >>> The password rules only apply to new passwords. >>> >> >> So then you have a mixture of both old and new rules. > > No. Validation rules only apply when a value is entered, not read. If a > user is forced to change his password after a number of days, or a > number of logons, then any change in rules is only applied when he > changes his password. A change in validation rules has no effect on > existing passwords. > Which means a mixture of conformant and non-conformant passwords in your database. Anyone knowledgeable of security would cringe at such a setup. But it really doesn't matter - it's all bloatware anyway. >>>> But again, more bloatware. >>> >>> Wrong. I'm providing the ability for a customer to tailor the password >>> rules to his own specifications without the need to make any code >>> changes. How is that "bloatware"? >>> >> >> Because it's code that adds unnecessary complexity to the code, for an >> unnecessary feature. But you've shown you're good at that. > > It is not an unnecessary feature. Different customers may have different > rules, and I can satisfy those rules without having to change a single > line of code. > Bloatware. If a customer wants a customized password rule, it's one line of code to change. And it doesn't add all that unnecessary complexity (bloatware) to the script. >> How many customers have actually demanded the need to change the >> rules? In over 30 years of programming for clients, none of mine have. > > None have had to demand such a facility for the simple reason that it is > supplied as standard. > My point exactly. Bloatware. A feature no one wants or cares about. >>>>>>>> Yes, I know you think your toy is the answer to life, the universe >>>>>>>> and >>>>>>>> everything. But it isn't. >>>>>>> >>>>>>> It works in my universe, but my universe is not centered around >>>>>>> Uranus. >>>>>>> >>>>>> >>>>>> That's true. You are in some alternate universe. Hopefully you never >>>>>> get >>>>>> a customer who knows something. >>>>> >>>>> Really? My biggest customer has been using my ERP application for >>>>> over 4 >>>>> years, and it has helped them triple their turnover to £2.5M per year >>>>> while >>>>> lowering their costs. >>>>> >>>> >>>> So? They probably could have doubled that again by using an >>>> spreadsheet. Too bad your code held them back. >>> >>> A single spreadsheet cannot be access simultaneously by multiple users, >>> and a spreadsheet cannot possible handle the requirements of an ERP >>> system. You need a proper database for that, and a proper database >>> application to go with it. >>> >> >> Neither can your code. All your code is is a simple e-commerce system, >> one of many available on the internet. > > I have looked at the documentation for several of these ecommerce > packages, and I have never seen anything mentioned about those functions > which are used only by members of staff which enable them to process the > sales orders. These ecommerce packages concentrate only on the front-end > website and totally ignore the back-end administrative functions. > So, what have you looked at. The open source free things out there? There is a lot more out there than what you find on SourceForge and the like. > The major customer of my ERP system took a look at various ecommerce > packages before deciding that they weren't good enough, which is why I > was asked to design and build a "proper" system for them. > You don't have an ERP system. You have a simple order entry/tracking system. And maybe they should have hired a competent consultant who could have recommended a proper system for them at a fraction of the cost you charged them for your custom system. -- ================== 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-22 10:27 +0100 |
| Message-ID | <Q9Qkr.304958$yJ4.71463@fx07.am4> |
| In reply to | #5624 |
"Jerry Stuckle" wrote in message news:jmu1nc$fui$1@dont-email.me... > >On 4/21/2012 5:35 AM, Tony Marston wrote: <snip> > From your description, any good programmer can tell your code is crap. > Only those like yourself can't see crap when it's described. Your definition of crap code seems to be nothing more than "it doesn't follow my rules, therefore it must be crap". >> By "vast majority" I mean the "vast majority of people who send me >> emails about my work". For every 100 I receive 99 of them are >> complimentary. The other 1% are nothing but personal insults, sent >> anonymously and without valid return addresses. >> > >Yea, right. And what is the experience of those programmers? PHP >programmers as a whole are not known for their intelligence or competence. >In fact, just the opposite is true. So, as this is a newsgroup for PHP programmers you are effectively saying that every member of this group is stupid and incompetent? Do you know how arrogant that makes you sound? >But then you're a great example of the latter. Have you looked in the mirror lately? <snip> >Horse hockey. You don't have an ERP system. You don't even know what an >ERP system is, and have never seen a real one. You've got a simple order >entry/tracking system. Any competent programmer can do the same in a short >time. My system qualifies as an ERP system according to the definition in wikipedia. The fact that it does not satisfy your personal definition is irrelevant. >>>> <snip> >>>>>> I don't GET/SET individual fields - everything (by this I mean >>>>>> database >>>>>> data) goes in as an array, and everything comes out as an array. The >>>>>> idea of >>>>>> unpicking the array to inject every value individually strikes me as >>>>>> being >>>>>> inefficient, and therefore bad practice. >>>>>> >>>>> >>>>> Gee, which means you have to build an array for the whole object every >>>>> time you need to change one property. Which means the rest of the >>>>> program is also dependent on that object. More bloat. More complexity. >>>> >>>> I don't need to build an array as the array is provided for me. If it >>>> comes from the user it is the $_POST array. If it comes from the >>>> database it is an array of rows and columns. >>>> >>>> How is using an array which can contain any number of columns and >>>> values >>>> "more complex" than having to define a separate variable for each >>>> column, and a separate getter/setter for each column. My method uses >>>> LESS code therefore it is LESS complex. >>>> >>> >>> And if the application needs to change one value without using the >>> $_POST array, it has to build an entire array just to set the one >>> value. Bloat! >>> >>> There are reasons for SET/GET methods. >> >> Just as there are reasons NOT to use them. I may insert data into an >> object with a setter, or I may use an argument on a method call. I find >> it much easier (ie: less coding) to insert the $_POST array as a >> complete array in a single method argument that to split it into its >> component parts and "set" each component one at a time. >> > >What do you think a setter is if it's not a method? And you never have >answered how the programmer can change one property without building a >whole array. Or get a single property? The table data already exists in the object as an array, so the programmer can examine or change the contents of the array at will. The programmer does not have to build the array, it is already there! Why can't you understand such a simple concept? >Also, the presence of set/get methods does not preclude the parsing of >arrays. I have both, for instance. > >>> If you understood even the very basics of OO programming (one of which >>> is encapsulation), you would know why they are needed. >> >> Getters and setters are NOT required for encapsulation. Encapsulation >> means *implementation* hiding, not *information* hiding. >> > >Yes, and the properties of the class (i.e. variables) are part of the >implementation. Implementation means code, not data. >>> Less code does not mean less complexity. In fact, just the opposite >>> can be true. >> >> Less code to write means less time to write it, less time to test (as >> the pre-written functions have already been tested), and less >> maintenance. That has been my experience over 30 years, and nothing you >> can say will change my opinion. >> > >That also is not necessarily true. Yes, pre-written functions are great. >That's why I use them in my code generator. My framework generates less code than yours because it uses more generalised functions. I don't use the copy paste method that you seem to favour. >But less code can mean MORE complexity. However, you've never worked on >anything non-trivial, so you wouldn't understand. How can less code be more complex? <snip> >> Take a look at the definition of "ERP" at >> http://en.wikipedia.org/wiki/Enterprise_resource_planning and tell me >> I'm wrong. I don't have all the modules listed there, but SME's don't >> need all those modules. > >I suggest you read it. An ERP system HAS all the modules. You can't pick >and choose. It's an integrated system. If you read the definition properly you will see that it is a set of integrated modules, and not all users require all modules. My ERP system does much more than deal with just sales orders. It does what my users want, and I care more for their opinion than I do yours. <snip> >> No I don't. You told me yourself that you regularly cut, paste and >> modify code. I don't need to do that as the code is defined once in a >> reusable function. > >Exactly. But that's not duplicated code. It's starting with a code >template and modifying it to suit my needs. That way you don't need to >start from scratch every time. If you were really competent you would create a version of that code template that could be reused as a single function instead of having to be copied and modified multiple times. <snip> >> An application can be described as "complex" by looking at the volume of >> business rules which have to be implemented. Using the Radicore >> framework I can quickly generate working transactions which already >> handle the boring work of moving data between the database and the user >> interface, which leaves maximum time to spend on the payload, the >> business rules. >> > >You can claim that for your simple database applications. But then you >need to do that to satisfy yourself you're working on "complex" >applications. Those of us who have worked on truly complex applications >know better. A complex application has complex business rules. A simple application has simple business rules. The number of lines of code is irrelevant. If I can take an application that uses 3M LOC and achieve the same result using half as many LOC would that automatically make my version half as complex? I think not. >>>>>>> None of those use frameworks because the frameworks don't work. >>>>>> >>>>>> You mean that the frameworks which you have used didn't work. If you >>>>>> write >>>>>> an application with> 3M LOC *WITHOUT* using a framework, even if you >>>>>> have >>>>>> to build it yourself, then you are not an efficient programmer. >>>>>> >>>>> >>>>> Nope. What kind of framework do you use for an OS, for instance? >>>> >>>> What has building an OS got to do with this conversation? This is a PHP >>>> newsgroup, which means that we are supposed to be talking about web >>>> applications written in PHP. >>>> >>> >>> An OS is an application. You claim all this knowledge of great >>> techniques. So have you ever written an OS? Or how about a compiler? >> >> I repeat, this is a PHP newsgroup, which means that we are supposed to >> be talking about web applications written in PHP. >> >So? You've claimed you've worked on "database applications for decades". >That's long before PHP existed. You opened the door. Now you're >backpedaling. Typical. I am not back pedalling. This newsgroup is for people who write database applications in PHP, so comments about writing operating systems or compilers are irrelevant. Before I starting writing database applications with PHP I wrote database applications with a variety of other languages. That shows that my experience of writing database applications has not been confined to the PHP language. Tellme how that is back pedalling? >> Applications which are NOT web applications and NOT written in PHP are >> irrelevant. > >Only because all you do are trivial applications in PHP - and you do it >poorly, at that. > >>> Even DOS 1.0 was more complex than anything you've written. >> >> DOS is not a web application written in PHP, so it's irrelevant. > >Nope, and neither were the "decades of database applications" you claimed >to have written in the very post I'm replying to. The fact that my experience with other languages meant that I wrote database applications for the desktop does not mean that it is totally irrelevant when using PHP to write database applications for the web. A database application is a database application regardless of whether the user interface is the web or the desktop. >Nor is database normalization (which you also claimed to know how to do >properly - which I also doubt) in that same post. I shall treat that remark with the contempt it deserves. >But the incompetent need to have it both ways - ignore the rules when it >benefits them but claim it's off topic when the rules don't suit them. You so are saying that I'm incompetent simply because I refuse to follow YOUR rules? Do you know how arrogant that makes you? <snip> >>>>> And what about existing passwords which don't follow the new rules? >>>> >>>> The password rules only apply to new passwords. >>> >>> So then you have a mixture of both old and new rules. >> >> No. Validation rules only apply when a value is entered, not read. If a >> user is forced to change his password after a number of days, or a >> number of logons, then any change in rules is only applied when he >> changes his password. A change in validation rules has no effect on >> existing passwords. > >Which means a mixture of conformant and non-conformant passwords in your >database. Anyone knowledgeable of security would cringe at such a setup. Any competent person would tell you that if the password validation rules are changed in such a way as to make all exissting passwords non-conformant then you get everybody to change their passwords so that all NEW passwords conform to the NEW rules. >But it really doesn't matter - it's all bloatware anyway. > >>>>> But again, more bloatware. >>>> >>>> Wrong. I'm providing the ability for a customer to tailor the password >>>> rules to his own specifications without the need to make any code >>>> changes. How is that "bloatware"? >>>> >>> >>> Because it's code that adds unnecessary complexity to the code, for an >>> unnecessary feature. But you've shown you're good at that. >> >> It is not an unnecessary feature. Different customers may have different >> rules, and I can satisfy those rules without having to change a single >> line of code. >> > >Bloatware. If a customer wants a customized password rule, it's one line >of code to change. And it doesn't add all that unnecessary complexity >(bloatware) to the script. So you are admitting that in YOUR implementation if you want to change the password validation rules then you have to change your code. In MY implementation this can be done by changing a value in the database, and you have the audacity and arrogance to call that bloat! >>> How many customers have actually demanded the need to change the >>> rules? In over 30 years of programming for clients, none of mine have. >> >> None have had to demand such a facility for the simple reason that it is >> supplied as standard. >> > >My point exactly. Bloatware. A feature no one wants or cares about. My customers care for it, and their opinion means more to me than yours. <snip> >> The major customer of my ERP system took a look at various ecommerce >> packages before deciding that they weren't good enough, which is why I >> was asked to design and build a "proper" system for them. >> > >You don't have an ERP system. You have a simple order entry/tracking >system. > >And maybe they should have hired a competent consultant who could have >recommended a proper system for them at a fraction of the cost you charged >them for your custom system. Your personal insults are adding nothing to this newsgroup. Please try showing a bit more professionalism and maturity. -- Tony Marston http://www.tonymarston.net http://www.radicore.org
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-04-22 10:43 -0400 |
| Message-ID | <jn15dt$gjl$1@dont-email.me> |
| In reply to | #5650 |
On 4/22/2012 5:27 AM, Tony Marston wrote: > "Jerry Stuckle" wrote in message news:jmu1nc$fui$1@dont-email.me... >> >> On 4/21/2012 5:35 AM, Tony Marston wrote: > <snip> >> From your description, any good programmer can tell your code is crap. >> Only those like yourself can't see crap when it's described. > > Your definition of crap code seems to be nothing more than "it doesn't > follow my rules, therefore it must be crap". > My definition of crap code is that "it is bloated, overly complicated and doesn't follow generally recognized rules". IOW, everything you've shown your code to be. >>> >> >> Yea, right. And what is the experience of those programmers? PHP >> programmers as a whole are not known for their intelligence or >> competence. In fact, just the opposite is true. > > So, as this is a newsgroup for PHP programmers you are effectively > saying that every member of this group is stupid and incompetent? Do you > know how arrogant that makes you sound? > No, you're putting words in my mouth (again). I'm not saying every member of this group is stupid or incompetent. There are a number of people here who are quite intelligent and competent, whose opinions I regard highly. But there are a few here who are stupid and incompetent. This especially goes for people who think they can ignore any rules they don't feel like implementing, and can call a simple order entry/tracking system an ERP system. You're just continuing to show your stupidity, Tony. You should have quit while you were ahead (not that you ever were). >> But then you're a great example of the latter. > > Have you looked in the mirror lately? > Ah, a comment I would expect from a three-year-old. About your speed. > <snip> >> Horse hockey. You don't have an ERP system. You don't even know what >> an ERP system is, and have never seen a real one. You've got a simple >> order entry/tracking system. Any competent programmer can do the same >> in a short time. > > My system qualifies as an ERP system according to the definition in > wikipedia. The fact that it does not satisfy your personal definition is > irrelevant. > No, it does not. It is a simple order entry/tracking system. But you can lie about it all you want. It just shows you are dishonest as well as stupid. >> >> What do you think a setter is if it's not a method? And you never have >> answered how the programmer can change one property without building a >> whole array. Or get a single property? > > The table data already exists in the object as an array, so the > programmer can examine or change the contents of the array at will. The > programmer does not have to build the array, it is already there! Why > can't you understand such a simple concept? > Yes, you've already said you don't understand one of the basic principles of OO programming - encapsulation. >> Also, the presence of set/get methods does not preclude the parsing of >> arrays. I have both, for instance. >> >>>> If you understood even the very basics of OO programming (one of which >>>> is encapsulation), you would know why they are needed. >>> >>> Getters and setters are NOT required for encapsulation. Encapsulation >>> means *implementation* hiding, not *information* hiding. >>> >> >> Yes, and the properties of the class (i.e. variables) are part of the >> implementation. > > Implementation means code, not data. > That's where you don't understand even basic OO. Implementation means both code and data. >>>> Less code does not mean less complexity. In fact, just the opposite >>>> can be true. >>> >>> Less code to write means less time to write it, less time to test (as >>> the pre-written functions have already been tested), and less >>> maintenance. That has been my experience over 30 years, and nothing you >>> can say will change my opinion. >>> >> >> That also is not necessarily true. Yes, pre-written functions are >> great. That's why I use them in my code generator. > > My framework generates less code than yours because it uses more > generalised functions. I don't use the copy paste method that you seem > to favour. > Your framework generates less code because it's only a half-assed implementation of even basic OO principles (which you have repeatedly shown you don't understand). >> But less code can mean MORE complexity. However, you've never worked >> on anything non-trivial, so you wouldn't understand. > > How can less code be more complex? > Again, it shows how little you know. Just because there code is smaller does not mean it's easier to understand. Sometimes it's better to add code to make it more understandable. > <snip> >>> Take a look at the definition of "ERP" at >>> http://en.wikipedia.org/wiki/Enterprise_resource_planning and tell me >>> I'm wrong. I don't have all the modules listed there, but SME's don't >>> need all those modules. >> >> I suggest you read it. An ERP system HAS all the modules. You can't >> pick and choose. It's an integrated system. > > If you read the definition properly you will see that it is a set of > integrated modules, and not all users require all modules. My ERP system > does much more than deal with just sales orders. It does what my users > want, and I care more for their opinion than I do yours. > No, not all users require all modules. However, all ERP systems PROVIDE all modules. But once again you show how dishonest your are by claiming your code is something it isn't. > <snip> >>> No I don't. You told me yourself that you regularly cut, paste and >>> modify code. I don't need to do that as the code is defined once in a >>> reusable function. >> >> Exactly. But that's not duplicated code. It's starting with a code >> template and modifying it to suit my needs. That way you don't need to >> start from scratch every time. > > If you were really competent you would create a version of that code > template that could be reused as a single function instead of having to > be copied and modified multiple times. > And you've just proved that once again you have no idea what you're talking about. A good example - a table with 25 columns. Most are text/numeric, but one is a 20MB BLOB. In one form you want to display all columns in a two column table (label/value). This one is easy. In a second case you want to display 10-16 of those columns in a 4-column table; 6 columns will be displayed or not based on values in other columns. 1 (the BLOB) will be displayed if it is not null. In the third case, you want to display 5 columns in a 5 column table row (only). You do not want to retrieve the BLOB column as it is unnecessary overhead (bloat). Let's see your template do that. > <snip> >>> An application can be described as "complex" by looking at the volume of >>> business rules which have to be implemented. Using the Radicore >>> framework I can quickly generate working transactions which already >>> handle the boring work of moving data between the database and the user >>> interface, which leaves maximum time to spend on the payload, the >>> business rules. >>> >> >> You can claim that for your simple database applications. But then you >> need to do that to satisfy yourself you're working on "complex" >> applications. Those of us who have worked on truly complex >> applications know better. > > A complex application has complex business rules. A simple application > has simple business rules. The number of lines of code is irrelevant. If > I can take an application that uses 3M LOC and achieve the same result > using half as many LOC would that automatically make my version half as > complex? I think not. > In your universe, yes. Anyone who has worked on truly complex applications knows better. But people who only do simple database applications think a few rules make something complex. I hate to burst your balloon, but it doesn't. You can keep deluding yourself, though. >>> >> So? You've claimed you've worked on "database applications for >> decades". That's long before PHP existed. You opened the door. Now >> you're backpedaling. Typical. > > I am not back pedalling. This newsgroup is for people who write database > applications in PHP, so comments about writing operating systems or > compilers are irrelevant. > You are back-pedalling. This is not a database newsgroup, nor is it a newsgroup for people who write database applications. You brought up databases, not me. > Before I starting writing database applications with PHP I wrote > database applications with a variety of other languages. That shows that > my experience of writing database applications has not been confined to > the PHP language. Tellme how that is back pedalling? > All database applications. Trivial to anyone who's ever worked on truly complex applications. You brought up an irrelevant subject, and now you're back-pedaling because I pointed out the fallacy in your argument. The fact is all you've EVER done is simple database applications. You have no idea what a complicated application is. >>> Applications which are NOT web applications and NOT written in PHP are >>> irrelevant. >> >> Only because all you do are trivial applications in PHP - and you do >> it poorly, at that. >> >>>> Even DOS 1.0 was more complex than anything you've written. >>> >>> DOS is not a web application written in PHP, so it's irrelevant. >> >> Nope, and neither were the "decades of database applications" you >> claimed to have written in the very post I'm replying to. > > The fact that my experience with other languages meant that I wrote > database applications for the desktop does not mean that it is totally > irrelevant when using PHP to write database applications for the web. A > database application is a database application regardless of whether the > user interface is the web or the desktop. > You're bringing up other languages and databases claiming they're relevant - yet when I mention other languages or applications you claim they are irrelevant. The truth is you have no leg to stand on so you keep trying to change the subject and/or claim something is irrelevant. >> Nor is database normalization (which you also claimed to know how to >> do properly - which I also doubt) in that same post. > > I shall treat that remark with the contempt it deserves. > Good. You are contemptful. >> But the incompetent need to have it both ways - ignore the rules when >> it benefits them but claim it's off topic when the rules don't suit them. > > You so are saying that I'm incompetent simply because I refuse to follow > YOUR rules? Do you know how arrogant that makes you? > No, widely recognized rules by experts. But you refuse to follow them. Do you know how arrogant (and stupid) that makes YOU? But once again you refuse to discuss the issue and attack back. You're only showing your stupidity. >> Which means a mixture of conformant and non-conformant passwords in >> your database. Anyone knowledgeable of security would cringe at such a >> setup. > > Any competent person would tell you that if the password validation > rules are changed in such a way as to make all exissting passwords > non-conformant then you get everybody to change their passwords so that > all NEW passwords conform to the NEW rules. > Which is why you set the rules ahead of time. But that's not what you claimed earlier, so you have to once-again back-pedal. >> But it really doesn't matter - it's all bloatware anyway. >> >>> >> >> Bloatware. If a customer wants a customized password rule, it's one >> line of code to change. And it doesn't add all that unnecessary >> complexity (bloatware) to the script. > > So you are admitting that in YOUR implementation if you want to change > the password validation rules then you have to change your code. In MY > implementation this can be done by changing a value in the database, and > you have the audacity and arrogance to call that bloat! > Sure. It's a one line change to the code. Quick, simple, and straightforward. But once a system is installed, I've NEVER had a customer ask for the rules to be changed. That's because we discuss the pros and cons of different rules up front. Plus I don't have to stay on the phone trying to talk the customer through how to implement his new rules. Your method is nothing but bloat - which is why you're the only one who's ever implemented such a stupid concept. >>>> How many customers have actually demanded the need to change the >>>> rules? In over 30 years of programming for clients, none of mine have. >>> >>> None have had to demand such a facility for the simple reason that it is >>> supplied as standard. >>> >> >> My point exactly. Bloatware. A feature no one wants or cares about. > > My customers care for it, and their opinion means more to me than yours. > I highly doubt your customers give a damn about it. Maybe they do because you sold them on how great it is - but then snake oil salesmen are good at that. > <snip> >>> The major customer of my ERP system took a look at various ecommerce >>> packages before deciding that they weren't good enough, which is why I >>> was asked to design and build a "proper" system for them. >>> >> >> You don't have an ERP system. You have a simple order entry/tracking >> system. >> >> And maybe they should have hired a competent consultant who could have >> recommended a proper system for them at a fraction of the cost you >> charged them for your custom system. > > Your personal insults are adding nothing to this newsgroup. Please try > showing a bit more professionalism and maturity. > No personal insult. Just the truth. You want the king of personal insults, look back through your own posts. -- ================== 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-23 15:23 +0100 |
| Message-ID | <dBdlr.18686$_Q.3940@fx01.am4> |
| In reply to | #5656 |
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message news:jn15dt$gjl$1@dont-email.me... > On 4/22/2012 5:27 AM, Tony Marston wrote: >> "Jerry Stuckle" wrote in message news:jmu1nc$fui$1@dont-email.me... >>> >>> On 4/21/2012 5:35 AM, Tony Marston wrote: >> <snip> >>> From your description, any good programmer can tell your code is crap. >>> Only those like yourself can't see crap when it's described. >> >> Your definition of crap code seems to be nothing more than "it doesn't >> follow my rules, therefore it must be crap". >> > > My definition of crap code is that "it is bloated, overly complicated and > doesn't follow generally recognized rules". IOW, everything you've shown > your code to be. You call my code bloated because I have included the option to change the password validation rules by changing values on a screen whereas you have to change the code. My method may have taken slightly longer to code, but it also means that changes are easier to implement. You call my code overly complicated because it has a pre-written validation class whereas to have to write code to validate each piece of user input. You say that my code does not follow "generally recognized rules" for no other reason that the rules which it *DOES* follow are not the same as yours. There is no single set of rules that is universally folowed by all programmers, so I follow the rules which I consider to be the most appropriate. >>> Yea, right. And what is the experience of those programmers? PHP >>> programmers as a whole are not known for their intelligence or >>> competence. In fact, just the opposite is true. >> >> So, as this is a newsgroup for PHP programmers you are effectively >> saying that every member of this group is stupid and incompetent? Do you >> know how arrogant that makes you sound? >> > > No, you're putting words in my mouth (again). No I'm not. Your exact words were, and I quote: "PHP programmers as a whole are not known for their intelligence or competence. In fact, just the opposite is true." The phrase "as a whole" tends to encompass the entire PHP programming fraternity, not just a select few. > I'm not saying every member of this group is stupid or incompetent. There > are a number of people here who are quite intelligent and competent, whose > opinions I regard highly. Only those who dare not disagree with anything you say. I am the founder-member of the "I disagree with everything that Jerry Stuckle says" society, so I don't think I'm in that group. Ask me if I care! <snip> >>> What do you think a setter is if it's not a method? And you never have >>> answered how the programmer can change one property without building a >>> whole array. Or get a single property? >> >> The table data already exists in the object as an array, so the >> programmer can examine or change the contents of the array at will. The >> programmer does not have to build the array, it is already there! Why >> can't you understand such a simple concept? > > Yes, you've already said you don't understand one of the basic principles > of OO programming - encapsulation. Encapsulation has nothing to do with information hiding, only implementation hiding. Encapsulation does not require te use of getters and setters. >>> Also, the presence of set/get methods does not preclude the parsing of >>> arrays. I have both, for instance. >>> >>>>> If you understood even the very basics of OO programming (one of which >>>>> is encapsulation), you would know why they are needed. >>>> >>>> Getters and setters are NOT required for encapsulation. Encapsulation >>>> means *implementation* hiding, not *information* hiding. >>>> >>> >>> Yes, and the properties of the class (i.e. variables) are part of the >>> implementation. >> >> Implementation means code, not data. > > That's where you don't understand even basic OO. Implementation means > both code and data. No it does not. On the subject of "Encapsulation is not data hiding" take a look at the following articles: http://www.javaworld.com/javaworld/jw-05-2001/jw-0518-encapsulation.html http://www.itmweb.com/essay550.htm http://homepage.mac.com/keithray/blog/2006/02/22/ <snip> >> My framework generates less code than yours because it uses more >> generalised functions. I don't use the copy paste method that you seem >> to favour. > > Your framework generates less code because it's only a half-assed > implementation of even basic OO principles (which you have repeatedly > shown you don't understand). My framework is an implementation of MY understanding of the principles of OOP just as your framework is an implementation of YOUR understanding of the same principles. When you consider the fact that there is no universal agreement on what "Object Oriented Programming" actually means then it is not surprising that two individuals have a totally different understanding. Yet I am not the one who is saying that *MY* understanding is the only opinion worth having. Take a look at these articles to see if you can identify a definition of OOP with is universally accepted: http://c2.com/cgi/wiki?DefinitionsForOo http://c2.com/cgi/wiki?NobodyAgreesOnWhatOoIs http://www.devx.com/opinion/Article/26776 http://www.geocities.com/tablizer/oopbad.htm http://www.geocities.com/tablizer/whypr.htm http://www.geocities.com/tablizer/core1.htm http://www.geocities.com/tablizer/beyondhw.htm http://c2.com/cgi/wiki?ArgumentsAgainstOop http://c2.com/cgi/wiki?ObjectOrientationIsDead http://c2.com/cgi/wiki?ObjectOrientationIsaHoax http://dreamsongs.com/ObjectsHaveFailedNarrative.html http://www.eetimes.com/design/embedded/4216597/Nuts-to-OOP http://c2.com/cgi/wiki?ObjectOrientedForDummies >>> But less code can mean MORE complexity. However, you've never worked >>> on anything non-trivial, so you wouldn't understand. >> >> How can less code be more complex? > > Again, it shows how little you know. Just because there code is smaller > does not mean it's easier to understand. Sometimes it's better to add > code to make it more understandable. I agree that several lines of simple code is easier to understand than one line of complex code, which is why I like to keep my code as simple as possible. Yet you seem to object that it is "too simple". >> <snip> >>>> Take a look at the definition of "ERP" at >>>> http://en.wikipedia.org/wiki/Enterprise_resource_planning and tell me >>>> I'm wrong. I don't have all the modules listed there, but SME's don't >>>> need all those modules. >>> >>> I suggest you read it. An ERP system HAS all the modules. You can't >>> pick and choose. It's an integrated system. >> >> If you read the definition properly you will see that it is a set of >> integrated modules, and not all users require all modules. My ERP system >> does much more than deal with just sales orders. It does what my users >> want, and I care more for their opinion than I do yours. >> > > No, not all users require all modules. However, all ERP systems PROVIDE > all modules. I don't provide modules that have not been requested. I started off by calling it an order processing system, but my first customer insisted that it was much more than. So if a paying customer says that it is an ERP system why should I accept your definition? <snip> >>>> No I don't. You told me yourself that you regularly cut, paste and >>>> modify code. I don't need to do that as the code is defined once in a >>>> reusable function. >>> >>> Exactly. But that's not duplicated code. It's starting with a code >>> template and modifying it to suit my needs. That way you don't need to >>> start from scratch every time. >> >> If you were really competent you would create a version of that code >> template that could be reused as a single function instead of having to >> be copied and modified multiple times. > > And you've just proved that once again you have no idea what you're > talking about. > > A good example - a table with 25 columns. Most are text/numeric, but one > is a 20MB BLOB. > > In one form you want to display all columns in a two column table > (label/value). This one is easy. > > In a second case you want to display 10-16 of those columns in a 4-column > table; 6 columns will be displayed or not based on values in other > columns. 1 (the BLOB) will be displayed if it is not null. > > In the third case, you want to display 5 columns in a 5 column table row > (only). You do not want to retrieve the BLOB column as it is unnecessary > overhead (bloat). > > Let's see your template do that. The number of columns which are retrieved from the database is not controlled by the template. By default all columns are retrieved, but the defaults can be changed whenever needed. >> <snip> >>>> An application can be described as "complex" by looking at the volume >>>> of >>>> business rules which have to be implemented. Using the Radicore >>>> framework I can quickly generate working transactions which already >>>> handle the boring work of moving data between the database and the user >>>> interface, which leaves maximum time to spend on the payload, the >>>> business rules. >>>> >>> >>> You can claim that for your simple database applications. But then you >>> need to do that to satisfy yourself you're working on "complex" >>> applications. Those of us who have worked on truly complex >>> applications know better. >> >> A complex application has complex business rules. A simple application >> has simple business rules. The number of lines of code is irrelevant. If >> I can take an application that uses 3M LOC and achieve the same result >> using half as many LOC would that automatically make my version half as >> complex? I think not. >> > > In your universe, yes. Anyone who has worked on truly complex > applications knows better. But people who only do simple database > applications think a few rules make something complex. I hate to burst > your balloon, but it doesn't. You can keep deluding yourself, though. While I agree that an application which does nothing more than move data between the database and the user interface and does not have any business rules to process is a simple application, it is naive to say that the addition of a large number of complex rules does not turn it into a more complex application. Using my framework all the simple stuff can be done without writing any code, but the complicated stuff, the processing of business rules, requires the programmer to actually add code to the relevant classes. It is the volume of code which the programmer has to add to the framework-generated code which adds to its complexity. Just because you think that a database application cannot possibly be complicated does not make it so. >>> So? You've claimed you've worked on "database applications for >>> decades". That's long before PHP existed. You opened the door. Now >>> you're backpedaling. Typical. >> >> I am not back pedalling. This newsgroup is for people who write database >> applications in PHP, so comments about writing operating systems or >> compilers are irrelevant. > > You are back-pedalling. This is not a database newsgroup, nor is it a > newsgroup for people who write database applications. You brought up > databases, not me. If you bother looking at what the OP wrote he wanted a way to generate an HTML form from a MySQL table structure. That is why I am talking about databases in this post. >> Before I starting writing database applications with PHP I wrote >> database applications with a variety of other languages. That shows that >> my experience of writing database applications has not been confined to >> the PHP language. Tellme how that is back pedalling? >> > > All database applications. Trivial to anyone who's ever worked on truly > complex applications. You brought up an irrelevant subject, and now > you're back-pedaling because I pointed out the fallacy in your argument. > > The fact is all you've EVER done is simple database applications. You > have no idea what a complicated application is. I shan't bother replying to such a pathetic statement. >>>> Applications which are NOT web applications and NOT written in PHP are >>>> irrelevant. >>> >>> Only because all you do are trivial applications in PHP - and you do >>> it poorly, at that. >>> >>>>> Even DOS 1.0 was more complex than anything you've written. >>>> >>>> DOS is not a web application written in PHP, so it's irrelevant. >>> >>> Nope, and neither were the "decades of database applications" you >>> claimed to have written in the very post I'm replying to. >> >> The fact that my experience with other languages meant that I wrote >> database applications for the desktop does not mean that it is totally >> irrelevant when using PHP to write database applications for the web. A >> database application is a database application regardless of whether the >> user interface is the web or the desktop. > > You're bringing up other languages and databases claiming they're > relevant - yet when I mention other languages or applications you claim > they are irrelevant. I am constantly talking about "database applications" because they are relevant to this topic. Non-database applications, such as operating systems and compilers are totally irrelevant. > The truth is you have no leg to stand on so you keep trying to change the > subject and/or claim something is irrelevant. > >>> Nor is database normalization (which you also claimed to know how to >>> do properly - which I also doubt) in that same post. >> >> I shall treat that remark with the contempt it deserves. > > Good. You are contemptful. Of you, yes. >>> But the incompetent need to have it both ways - ignore the rules when >>> it benefits them but claim it's off topic when the rules don't suit >>> them. >> >> You so are saying that I'm incompetent simply because I refuse to follow >> YOUR rules? Do you know how arrogant that makes you? > > No, widely recognized rules by experts. Who says that the rules that you choose to follow were written by experts? What about different sets of rules written by different sets of experts? > But you refuse to follow them. Do you know how arrogant (and stupid) that > makes YOU? > > But once again you refuse to discuss the issue and attack back. You're > only showing your stupidity. No, I'm showing that I don't agree with you. >>> Which means a mixture of conformant and non-conformant passwords in >>> your database. Anyone knowledgeable of security would cringe at such a >>> setup. >> >> Any competent person would tell you that if the password validation >> rules are changed in such a way as to make all exissting passwords >> non-conformant then you get everybody to change their passwords so that >> all NEW passwords conform to the NEW rules. > > Which is why you set the rules ahead of time. But that's not what you > claimed earlier, so you have to once-again back-pedal. Password validation rules MAY be set when the application is first installed, but it is also possible that they MAY be changed some time later. have yiu never heard of customers changing their minds? >>> But it really doesn't matter - it's all bloatware anyway. Only in your opinion. >>> Bloatware. If a customer wants a customized password rule, it's one >>> line of code to change. And it doesn't add all that unnecessary >>> complexity (bloatware) to the script. >> >> So you are admitting that in YOUR implementation if you want to change >> the password validation rules then you have to change your code. In MY >> implementation this can be done by changing a value in the database, and >> you have the audacity and arrogance to call that bloat! > > Sure. It's a one line change to the code. Quick, simple, and > straightforward. But once a system is installed, I've NEVER had a > customer ask for the rules to be changed. That's because we discuss the > pros and cons of different rules up front. > > Plus I don't have to stay on the phone trying to talk the customer through > how to implement his new rules. If you design a simple screen which allows a user to define different password validation rules then your are a poor designer. > Your method is nothing but bloat - which is why you're the only one who's > ever implemented such a stupid concept. It is not boat, it is a valid option. It is also an option that can be modified without having to change a single line of code. >>>>> How many customers have actually demanded the need to change the >>>>> rules? In over 30 years of programming for clients, none of mine have. >>>> >>>> None have had to demand such a facility for the simple reason that it >>>> is >>>> supplied as standard. >>> >>> My point exactly. Bloatware. A feature no one wants or cares about. >> >> My customers care for it, and their opinion means more to me than yours. > > I highly doubt your customers give a damn about it. Maybe they do because > you sold them on how great it is - but then snake oil salesmen are good at > that. I don't sell then anything that doesn't work. I ask then what password validation rules they want rom day 1, then I show then how to set those rules using the screen provided. They then know how to change the rules should they ever want to. <snip> >> Your personal insults are adding nothing to this newsgroup. Please try >> showing a bit more professionalism and maturity. > > No personal insult. Just the truth. No, just your version of what you assume the truth to be. -- Tony Marston http://www.tonymarston.net http://www.radicore.org
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | comp.lang.php
csiph-web