| Dynamic form generation [message #177642] |
Thu, 12 April 2012 03:48  |
Charles
Messages: 13
Registered: February 2011
Karma: 0
|
Junior Member |
|
|
I'm working on a database application, and I'd like to write a function that takes the table structure from a MySQL database table and generates a fresh data entry form from it each time someone browses to it.
That way I can have four functions that serve the four purposes of data entry, view/query, edit, and delete, instead of 4 scripts for each table (the application has 64 tables so far) that have to be editted every time the table changes.
Is it possible to use PHP to generate data entry forms on the fly?
Does anyone have any recommendation for a reference resource or some sample code to study for this?
|
|
|
|
| Re: Dynamic form generation [message #177644 is a reply to message #177642] |
Thu, 12 April 2012 04:03  |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/11/2012 11:48 PM, Charles wrote:
> I'm working on a database application, and I'd like to write a function that takes the table structure from a MySQL database table and generates a fresh data entry form from it each time someone browses to it.
>
> That way I can have four functions that serve the four purposes of data entry, view/query, edit, and delete, instead of 4 scripts for each table (the application has 64 tables so far) that have to be editted every time the table changes.
>
> Is it possible to use PHP to generate data entry forms on the fly?
>
> Does anyone have any recommendation for a reference resource or some sample code to study for this?
>
You can do it. You need to get the table definition, parse it and
create the appropriate form. That's what PHPMyAdmin does, for instance.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Dynamic form generation [message #177645 is a reply to message #177642] |
Thu, 12 April 2012 04:46 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Charles wrote:
> I'm working on a database application, and I'd like to write a function that takes the table structure from a MySQL database table and generates a fresh data entry form from it each time someone browses to it.
>
> That way I can have four functions that serve the four purposes of data entry, view/query, edit, and delete, instead of 4 scripts for each table (the application has 64 tables so far) that have to be editted every time the table changes.
>
> Is it possible to use PHP to generate data entry forms on the fly?
it certainly is, yes, but a general purpose function is less easy.
Because you need to associate e.g. a label for each entry box with a
field in each table.
And you may want to vary the layout for each presentable form.
My way of doing it to start what will probably be a long and acrimonious
religious discussion is to write a form library which does basic things
like putting and input box with a legend by its size at a given screen
location. Plus open and close database functions. And generic stuff goes
in there, plus a generic page header that sets up stuff like the overall
screen appearance and style sheets and any menu systems that you might
have. That code is common to all screens.
Then each form is custom written forte tables uit access. In genarl it
has these parts.
1/. Set up the page headers and any menu systems by calling a generic
initialisation with the page identities as the parameters to pass. Also
open the database.
2/. If the form has been called as a result of a submit operation check
for that and if so check as to whether (usually) some row ID is set -
if it is you can regard that as an update, and parse and valisdate and
sanitise the PUT variables before updating the database (or returning
some error).
3/. else if its an update but no ID is set assume its new data to be
interested. How you arrange to do that depends on how you want the form
to work. Insert te data, bick up the last insret id and copy that into
your gobal id field.
4/ then draw the screen either with empty data or by reloading the data
from the DB using the global record ID variable as the key.
Thats what works for me.
>
> Does anyone have any recommendation for a reference resource or some sample code to study for this?
>
--
To people who know nothing, anything is possible.
To people who know too much, it is a sad fact
that they know how little is really possible -
and how hard it is to achieve it.
|
|
|
|
| Re: Dynamic form generation [message #177646 is a reply to message #177642] |
Thu, 12 April 2012 04:52 |
Michael Vilain
Messages: 88
Registered: September 2010
Karma: 0
|
Member |
|
|
In article
<7262665.439.1334202496427.JavaMail.geo-discussion-forums@vbgx21>,
Charles <cchamb2(at)gmail(dot)com> wrote:
> I'm working on a database application, and I'd like to write a function that
> takes the table structure from a MySQL database table and generates a fresh
> data entry form from it each time someone browses to it.
>
> That way I can have four functions that serve the four purposes of data
> entry, view/query, edit, and delete, instead of 4 scripts for each table (the
> application has 64 tables so far) that have to be editted every time the
> table changes.
>
> Is it possible to use PHP to generate data entry forms on the fly?
>
> Does anyone have any recommendation for a reference resource or some sample
> code to study for this?
I did this for a site I created to manage the membership database behind
it. You'll have to read up on how to use php to access mysql (or
whatever database you're using as a backend), display forms, and process
them via get or post. It's a little more than can be discussed here. I
got a book on building a web site using php but it's most likely
hopelessly out of date by now.
If you want to do this 'by yourself', then you're going to have to write
or reuse various functions to do all this stuff.
--
DeeDee, don't press that button! DeeDee! NO! Dee...
[I filter all Goggle Groups posts, so any reply may be automatically ignored]
|
|
|
|
| Re: Dynamic form generation [message #177648 is a reply to message #177642] |
Thu, 12 April 2012 09:52 |
Tony Marston
Messages: 57
Registered: November 2010
Karma: 0
|
Member |
|
|
If you are working on a database application rather than a website then you
might want to look at http://www.radicore.org which is an open source
framework specifically designed for database applications. You import your
table structures into the data dictionary, export them to generate your
class files, then generate user transactions from a library of transaction
patterns. You can generate working transactions in a matter of minutes, all
without writing a single line of PHP, HTML or SQL. All the plumbing is done
for you, so all you need do is add custom code for the payload. It has an
inbuilt logon screen, Role Based Access Control (RBAC), dynamic menus, audit
logging, and an activity-based workflow system.
This framework has been used to create an ERP package which has helped an
online jewellery company triple its turnover to £2.5m per year without
increasing its cost base. That package has over 200 database tables, 350
relationships and 1700 transactions, so Radicore has been proven to work in
the commercial world.
--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
"Charles" <cchamb2(at)gmail(dot)com> wrote in message
news:7262665.439.1334202496427.JavaMail.geo-discussion-forums@vbgx21...
> I'm working on a database application, and I'd like to write a function
> that takes the table structure from a MySQL database table and generates a
> fresh data entry form from it each time someone browses to it.
>
> That way I can have four functions that serve the four purposes of data
> entry, view/query, edit, and delete, instead of 4 scripts for each table
> (the application has 64 tables so far) that have to be editted every time
> the table changes.
>
> Is it possible to use PHP to generate data entry forms on the fly?
>
> Does anyone have any recommendation for a reference resource or some
> sample code to study for this?
>
>
|
|
|
|
| Re: Dynamic form generation [message #177657 is a reply to message #177646] |
Thu, 12 April 2012 12:42 |
Denis McMahon
Messages: 634
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Wed, 11 Apr 2012 21:52:31 -0700, Michael Vilain wrote:
> You'll have to read up on how to use php to access mysql (or
> whatever database you're using as a backend), display forms, and process
> them via get or post.
I think he knows that much, what he's asking for is a bit more complex
than the very basic "how do I use php and mysql to generate web pages"
that you seem to not be answering.
What he's talking about, specifically, is code that takes the output of
the sql query "describe <tablename>;" or "show columns from <tablename>"
and generates forms to enter, update or display the data in that table
based on the table structure.
i.e. first of all taking the output of the describe <tablename> / show
columns from <tablename> query, generating a list of fieldnames and
datatypes, and then generating suitable forms / tables etc to display /
enter / update those values and insert into / update the tables as
appropriate.
Rgds
Denis McMahon
|
|
|
|
| Re: Dynamic form generation [message #177676 is a reply to message #177657] |
Fri, 13 April 2012 03:43 |
Charles
Messages: 13
Registered: February 2011
Karma: 0
|
Junior Member |
|
|
Absolutely correct. The database has 34 active and 34 historical tables so far, and my guess is that about another dozen or so of each to create.
I can visualize the relationships between the tables, and I'm normalizing as I go on table structure, but having to write and maintain somewhere around 150 scripts each and every time I so much as sneeze (add/remove a field or change a field type in any of the 100 tables) is daunting.
I'm just as comfortable with calling a script to do crate each form as I need it.
Any suggestions?
On Thursday, April 12, 2012 5:42:15 AM UTC-7, Denis McMahon wrote:
> On Wed, 11 Apr 2012 21:52:31 -0700, Michael Vilain wrote:
>
>> You'll have to read up on how to use php to access mysql (or
>> whatever database you're using as a backend), display forms, and process
>> them via get or post.
>
> I think he knows that much, what he's asking for is a bit more complex
> than the very basic "how do I use php and mysql to generate web pages"
> that you seem to not be answering.
>
> What he's talking about, specifically, is code that takes the output of
> the sql query "describe <tablename>;" or "show columns from <tablename>"
> and generates forms to enter, update or display the data in that table
> based on the table structure.
>
> i.e. first of all taking the output of the describe <tablename> / show
> columns from <tablename> query, generating a list of fieldnames and
> datatypes, and then generating suitable forms / tables etc to display /
> enter / update those values and insert into / update the tables as
> appropriate.
>
> Rgds
>
> Denis McMahon
|
|
|
|
| Re: Dynamic form generation [message #177677 is a reply to message #177676] |
Fri, 13 April 2012 04:55 |
Michael Vilain
Messages: 88
Registered: September 2010
Karma: 0
|
Member |
|
|
In article
<6651622.883.1334288601914.JavaMail.geo-discussion-forums@vbbfj25>,
Charles <cchamb2(at)gmail(dot)com> wrote:
> Absolutely correct. The database has 34 active and 34 historical tables so
> far, and my guess is that about another dozen or so of each to create.
> I can visualize the relationships between the tables, and I'm normalizing
> as I go on table structure, but having to write and maintain somewhere
> around 150 scripts each and every time I so much as sneeze (add/remove a
> field or change a field type in any of the 100 tables) is daunting.
>
> I'm just as comfortable with calling a script to do crate each form as I need
> it.
>
> Any suggestions?
>
> On Thursday, April 12, 2012 5:42:15 AM UTC-7, Denis McMahon wrote:
>> On Wed, 11 Apr 2012 21:52:31 -0700, Michael Vilain wrote:
>>
>>> You'll have to read up on how to use php to access mysql (or
>>> whatever database you're using as a backend), display forms, and process
>>> them via get or post.
>>
>> I think he knows that much, what he's asking for is a bit more complex
>> than the very basic "how do I use php and mysql to generate web pages"
>> that you seem to not be answering.
>>
>> What he's talking about, specifically, is code that takes the output of
>> the sql query "describe <tablename>;" or "show columns from <tablename>"
>> and generates forms to enter, update or display the data in that table
>> based on the table structure.
>>
>> i.e. first of all taking the output of the describe <tablename> / show
>> columns from <tablename> query, generating a list of fieldnames and
>> datatypes, and then generating suitable forms / tables etc to display /
>> enter / update those values and insert into / update the tables as
>> appropriate.
>>
>> Rgds
>>
>> Denis McMahon
I don't know of any php tools that will automatically generate
display/modify/delete forms for specific tables if you just give them
the table layout. I think you're stuck coding and maintaining each form
by hand.
I've heard Java does this sort of thing automatically. Seriously. When
you change the class in Java, apparently there are libraries that will
change the forms automatically.
There's no real short cut. If there was, a lot of php developers would
be out of work.
--
DeeDee, don't press that button! DeeDee! NO! Dee...
[I filter all Goggle Groups posts, so any reply may be automatically ignored]
|
|
|
|
| Re: Dynamic form generation [message #177679 is a reply to message #177676] |
Fri, 13 April 2012 08:59 |
Tony Marston
Messages: 57
Registered: November 2010
Karma: 0
|
Member |
|
|
"Charles" <cchamb2(at)gmail(dot)com> wrote in message
news:6651622.883.1334288601914.JavaMail.geo-discussion-forums@vbbfj25...
> Absolutely correct. The database has 34 active and 34 historical tables
> so far, and my guess is that about another dozen or so of each to create.
> I can visualize the relationships between the tables, and I'm normalizing
> as
> I go on table structure, but having to write and maintain somewhere around
> 150 scripts each and every time I so much as sneeze (add/remove a field or
> change a field type in any of the 100 tables) is daunting.
> I'm just as comfortable with calling a script to do crate each form as I
> need it.
> Any suggestions?
If you used a proper framework then you wouldn't have to do so much work for
a minor database change. If you used radicore all you would have to do is
re-import the table's structure into the data dictionary and then export the
updated structure to replace the table's structure file. The only time you
would need to modify another script would be if you needed to change the
screen structure (by modifying a small screen structure file) or a business
rule (by modifying that table's class file).
A lot of simple changes, such as a field's size, can be achieved with a
simple import/export without having to modify any scripts at all.
Tony Marston
On Thursday, April 12, 2012 5:42:15 AM UTC-7, Denis McMahon wrote:
> On Wed, 11 Apr 2012 21:52:31 -0700, Michael Vilain wrote:
>
>> You'll have to read up on how to use php to access mysql (or
>> whatever database you're using as a backend), display forms, and process
>> them via get or post.
>
> I think he knows that much, what he's asking for is a bit more complex
> than the very basic "how do I use php and mysql to generate web pages"
> that you seem to not be answering.
>
> What he's talking about, specifically, is code that takes the output of
> the sql query "describe <tablename>;" or "show columns from <tablename>"
> and generates forms to enter, update or display the data in that table
> based on the table structure.
>
> i.e. first of all taking the output of the describe <tablename> / show
> columns from <tablename> query, generating a list of fieldnames and
> datatypes, and then generating suitable forms / tables etc to display /
> enter / update those values and insert into / update the tables as
> appropriate.
>
> Rgds
>
> Denis McMahon
|
|
|
|
| Re: Dynamic form generation [message #177681 is a reply to message #177642] |
Fri, 13 April 2012 09:39 |
Erwin Moller
Messages: 228
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/12/2012 5:48 AM, Charles wrote:
> I'm working on a database application, and I'd like to write a function that takes the table structure from a MySQL database table and generates a fresh data entry form from it each time someone browses to it.
>
> That way I can have four functions that serve the four purposes of data entry, view/query, edit, and delete, instead of 4 scripts for each table (the application has 64 tables so far) that have to be editted every time the table changes.
>
> Is it possible to use PHP to generate data entry forms on the fly?
>
> Does anyone have any recommendation for a reference resource or some sample code to study for this?
>
Hi Charles,
I have written such a contraption for Postgres 8.1 a few years ago.
I don't think I am allowed to send you the code, but I can describe it
(translated to mysql).
The approach is really simple:
http://dev.mysql.com/doc/refman/5.0/en/getting-information.html
1) Figure out how you can get a listing of all your tables in the db.
('show tables' in mysql, I think)
2) List them all on the screen, and hyperlink to a details page.
3) Look up all the columns in use for that given table.
('describe table' I think)
4) Make a mapping for each datatype you want to support.
Don't try to support everything: BLOB makes no sense to edit in a html form.
For example:
$myMapping = [
"CHAR(x)" => "TS",
"VARCHAR(x)" => "TS",
"TEXT" => "TB",
"TINYINT" => "I",
etc...
];
TS meaning Texttype and small (Use INPUT type="text" in form)
TB meaning Texttype and big (Use textarea in form)
I meaning int.
You need a bit smarter code than plain matching, since CHAR(30) must match.
You can use a regular expression.
Now you can map every column to a suitable HTML form element.
You can also use that mapping to do the right casting before inserting
when you receive a new row.
for example: use mysql_realescape() on TS and TB.
Cast received integers to int.
Cast floats/doubles to... etc.
It isn't too difficult to write if you use a simple mapping array and
only support datatypes that make sense. I wrote a simple one in 1 day.
And it is fun. :-)
Hope this helps you going.
Good luck.
Regards,
Erwin Moller
--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens
|
|
|
|
| Re: Dynamic form generation [message #177684 is a reply to message #177677] |
Fri, 13 April 2012 13:19 |
Denis McMahon
Messages: 634
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Thu, 12 Apr 2012 21:55:04 -0700, Michael Vilain wrote:
> I don't know of any php tools that will automatically generate
> display/modify/delete forms for specific tables if you just give them
> the table layout. I think you're stuck coding and maintaining each form
> by hand.
As I think Jerry has already posted, phpmyadmin does this, and the OP
could probably, with a bit of searching, lift the code from there.
Rgds
Denis McMahon
|
|
|
|
| Re: Dynamic form generation [message #177685 is a reply to message #177679] |
Fri, 13 April 2012 13:22 |
Denis McMahon
Messages: 634
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote:
> If you used a proper framework ...
.... then you'd have all the junk and baggage that comes along with that
framework, including any security flaws in the framework.
Not saying that frameworks are inherently bad, but they're not
automatically the solution either.
Rgds
Denis McMahon
|
|
|
|
| Re: Dynamic form generation [message #177687 is a reply to message #177642] |
Fri, 13 April 2012 13:27 |
Jonathan Stein
Messages: 43
Registered: September 2010
Karma: 0
|
Member |
|
|
Den 12-04-2012 05:48, Charles wrote:
> I'm working on a database application, and I'd like to write a function that takes the table structure from a MySQL database table and generates a fresh data entry form from it each time someone browses to it.
I would strongly recommend a framework. My favorite is CakePHP
(http://cakephp.org/), which can dynamically generate pages to create,
read, update or delete records in your database.
If you obey to some naming conventions, CakePHP can handle relations
between your tables without any additional coding.
You can customize the way your pages are generated - and if you want to
customize specific pages more, CakePHP can write the code for the page,
so that you change any detail the way you prefer. (But then you have to
maintain the page manually).
- But you must be prepared to invest some time learning your framework,
before you start to gain from it!
Regards
Jonathan
|
|
|
|
| Re: Dynamic form generation [message #177695 is a reply to message #177679] |
Sat, 14 April 2012 13:53 |
Peter H. Coffin
Messages: 245
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote:
>
> "Charles" <cchamb2(at)gmail(dot)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
|
|
|
|
| Re: Dynamic form generation [message #177696 is a reply to message #177695] |
Sun, 15 April 2012 07:33 |
Tony Marston
Messages: 57
Registered: November 2010
Karma: 0
|
Member |
|
|
"Peter H. Coffin" <hellsop(at)ninehells(dot)com> wrote in message
news:slrnjoj0b7(dot)4ci(dot)hellsop(at)nibelheim(dot)ninehells(dot)com...
> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote:
>>
>> "Charles" <cchamb2(at)gmail(dot)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
|
|
|
|
| Re: Dynamic form generation [message #177698 is a reply to message #177696] |
Sun, 15 April 2012 12:51 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/15/2012 3:33 AM, Tony Marston wrote:
> "Peter H. Coffin"<hellsop(at)ninehells(dot)com> wrote in message
> news:slrnjoj0b7(dot)4ci(dot)hellsop(at)nibelheim(dot)ninehells(dot)com...
>> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote:
>>>
>>> "Charles"<cchamb2(at)gmail(dot)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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Dynamic form generation [message #177711 is a reply to message #177698] |
Mon, 16 April 2012 08:31 |
Tony Marston
Messages: 57
Registered: November 2010
Karma: 0
|
Member |
|
|
"Jerry Stuckle" <jstucklex(at)attglobal(dot)net> wrote in message
news:jmeg9a$5pt$2(at)dont-email(dot)me...
> On 4/15/2012 3:33 AM, Tony Marston wrote:
>> "Peter H. Coffin"<hellsop(at)ninehells(dot)com> wrote in message
>> news:slrnjoj0b7(dot)4ci(dot)hellsop(at)nibelheim(dot)ninehells(dot)com...
>>> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote:
>>>>
>>>> "Charles"<cchamb2(at)gmail(dot)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(at)attglobal(dot)net
> ==================
|
|
|
|
| Re: Dynamic form generation [message #177713 is a reply to message #177711] |
Mon, 16 April 2012 12:33 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/16/2012 4:31 AM, Tony Marston wrote:
> "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message
> news:jmeg9a$5pt$2(at)dont-email(dot)me...
>> On 4/15/2012 3:33 AM, Tony Marston wrote:
>>> "Peter H. Coffin"<hellsop(at)ninehells(dot)com> wrote in message
>>> news:slrnjoj0b7(dot)4ci(dot)hellsop(at)nibelheim(dot)ninehells(dot)com...
>>>> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote:
>>>> >
>>>> > "Charles"<cchamb2(at)gmail(dot)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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Dynamic form generation [message #177715 is a reply to message #177713] |
Mon, 16 April 2012 14:11 |
Tony Marston
Messages: 57
Registered: November 2010
Karma: 0
|
Member |
|
|
"Jerry Stuckle" <jstucklex(at)attglobal(dot)net> wrote in message
news:jmh3iq$f4m$1(at)dont-email(dot)me...
> On 4/16/2012 4:31 AM, Tony Marston wrote:
>> "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message
>> news:jmeg9a$5pt$2(at)dont-email(dot)me...
>>> On 4/15/2012 3:33 AM, Tony Marston wrote:
>>>> "Peter H. Coffin"<hellsop(at)ninehells(dot)com> wrote in message
>>>> news:slrnjoj0b7(dot)4ci(dot)hellsop(at)nibelheim(dot)ninehells(dot)com...
>>>> > On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote:
>>>> >>
>>>> >> "Charles"<cchamb2(at)gmail(dot)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(at)attglobal(dot)net
> ==================
|
|
|
|
| Re: Dynamic form generation [message #177716 is a reply to message #177715] |
Mon, 16 April 2012 15:18 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/16/2012 10:11 AM, Tony Marston wrote:
> "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message
> news:jmh3iq$f4m$1(at)dont-email(dot)me...
>> On 4/16/2012 4:31 AM, Tony Marston wrote:
>>> "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message
>>> news:jmeg9a$5pt$2(at)dont-email(dot)me...
>>>> On 4/15/2012 3:33 AM, Tony Marston wrote:
>>>> > "Peter H. Coffin"<hellsop(at)ninehells(dot)com> wrote in message
>>>> > news:slrnjoj0b7(dot)4ci(dot)hellsop(at)nibelheim(dot)ninehells(dot)com...
>>>> >> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote:
>>>> >>>
>>>> >>> "Charles"<cchamb2(at)gmail(dot)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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Dynamic form generation [message #177721 is a reply to message #177716] |
Tue, 17 April 2012 08:18 |
Tony Marston
Messages: 57
Registered: November 2010
Karma: 0
|
Member |
|
|
"Jerry Stuckle" wrote in message news:jmhd8m$6jr$1(at)dont-email(dot)me...
>
> On 4/16/2012 10:11 AM, Tony Marston wrote:
>> "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message
>> news:jmh3iq$f4m$1(at)dont-email(dot)me...
>>> On 4/16/2012 4:31 AM, Tony Marston wrote:
>>>> "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message
>>>> news:jmeg9a$5pt$2(at)dont-email(dot)me...
>>>> > On 4/15/2012 3:33 AM, Tony Marston wrote:
>>>> >> "Peter H. Coffin"<hellsop(at)ninehells(dot)com> wrote in message
>>>> >> news:slrnjoj0b7(dot)4ci(dot)hellsop(at)nibelheim(dot)ninehells(dot)com...
>>>> >>> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote:
>>>> >>>>
>>>> >>>> "Charles"<cchamb2(at)gmail(dot)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
|
|
|
|
| Re: Dynamic form generation [message #177722 is a reply to message #177721] |
Tue, 17 April 2012 10:07 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/17/2012 4:18 AM, Tony Marston wrote:
> "Jerry Stuckle" wrote in message news:jmhd8m$6jr$1(at)dont-email(dot)me...
>>
>> On 4/16/2012 10:11 AM, Tony Marston wrote:
>>> "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message
>>> news:jmh3iq$f4m$1(at)dont-email(dot)me...
>>>> On 4/16/2012 4:31 AM, Tony Marston wrote:
>>>> > "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message
>>>> > news:jmeg9a$5pt$2(at)dont-email(dot)me...
>>>> >> On 4/15/2012 3:33 AM, Tony Marston wrote:
>>>> >>> "Peter H. Coffin"<hellsop(at)ninehells(dot)com> wrote in message
>>>> >>> news:slrnjoj0b7(dot)4ci(dot)hellsop(at)nibelheim(dot)ninehells(dot)com...
>>>> >>>> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote:
>>>> >>>>>
>>>> >>>>> "Charles"<cchamb2(at)gmail(dot)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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Dynamic form generation [message #177723 is a reply to message #177685] |
Tue, 17 April 2012 12:49 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Denis McMahon wrote:
> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote:
>> If you used a proper framework ...
>
> ... then you'd have all the junk and baggage that comes along with that
> framework, including any security flaws in the framework.
>
> Not saying that frameworks are inherently bad, but they're not
> automatically the solution either.
TINSTAAFL. If you want complete flexibility of the application as the OP
wants, you have to have an abstraction layer in your application, i.e. it
has to be built on a framework (some people really should reflect on the
term "framework" and its etymology). Abstraction layers come at a price:
Increased overall complexity of the application and decreased efficiency for
tasks that do not require as much flexibility.
Whether that framework was written by you or someone else is another matter.
Chances are that a framework written by someone else has already gained
enough adoption in the global software community that its flaws – including
security flaws – are more quickly detected and fixed than in a framework
that you have written yourself. On the other hand, chances are that a
framework you have written yourself can be better adjusted *by you* to do
what you want than a framework written by someone else, especially if you
created it for the same project in which you are using it.
Inevitably all frameworks become bloated if functionality for flexibility
keeps being added to them. It would appear that there is a point where a
framework author should stop improving it and start something new for a new
project, maybe based on old code (but sometimes a rewrite is less expensive
and turns out to be better). IOW, it is a good idea if you built frameworks
with modularity in mind and use them only *as needed* (not simply for the
sake of using them, like trying to appear cool to the crowd).
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
|
|
|
|
| Re: Dynamic form generation [message #177724 is a reply to message #177723] |
Tue, 17 April 2012 15:36 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/17/2012 8:49 AM, Thomas 'PointedEars' Lahn wrote:
> Denis McMahon wrote:
>
>> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote:
>>> If you used a proper framework ...
>>
>> ... then you'd have all the junk and baggage that comes along with that
>> framework, including any security flaws in the framework.
>>
>> Not saying that frameworks are inherently bad, but they're not
>> automatically the solution either.
>
> TINSTAAFL. If you want complete flexibility of the application as the OP
> wants, you have to have an abstraction layer in your application, i.e. it
> has to be built on a framework (some people really should reflect on the
> term "framework" and its etymology). Abstraction layers come at a price:
> Increased overall complexity of the application and decreased efficiency for
> tasks that do not require as much flexibility.
>
Yup, and when you use a framework you force the application to match the
framework, instead of allowing the application to meet the client's needs.
It may work - but then it may not, also.
> Whether that framework was written by you or someone else is another matter.
> Chances are that a framework written by someone else has already gained
> enough adoption in the global software community that its flaws – including
> security flaws – are more quickly detected and fixed than in a framework
> that you have written yourself. On the other hand, chances are that a
> framework you have written yourself can be better adjusted *by you* to do
> what you want than a framework written by someone else, especially if you
> created it for the same project in which you are using it.
>
So? Good programming practices and test cases will eliminate more
security flaws than many of the "frameworks" out there. Have you seen
some of the crap code which has been written "by committee"? Not all of
it, but a lot of the donations are from people who don't really
understand what they're doing - or at least don't write code like they
know what they're doing.
> Inevitably all frameworks become bloated if functionality for flexibility
> keeps being added to them. It would appear that there is a point where a
> framework author should stop improving it and start something new for a new
> project, maybe based on old code (but sometimes a rewrite is less expensive
> and turns out to be better). IOW, it is a good idea if you built frameworks
> with modularity in mind and use them only *as needed* (not simply for the
> sake of using them, like trying to appear cool to the crowd).
>
>
> PointedEars
If a framework attempts to be "all things to all people", then that's
quite true. But the same is true of *any* code.
However, a limited framework with limited goals doesn't necessarily have
to be the case.
For instance, in my case - I have a framework which builds PHP classes
to interface to a database. It generates a lot of usable code for those
classes, including form handling. However, since each class is pretty
much independent, I can easily change a class without affecting the rest
of the program.
I don't have it where it will work with multiple tables yet (something I
will do one of these days), but it takes a huge amount of the repetitive
work off of me.
And no, I don't try to use it for every project. But where a project is
database-intensive, it suits my purposes.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Dynamic form generation [message #177725 is a reply to message #177722] |
Wed, 18 April 2012 08:10 |
Tony Marston
Messages: 57
Registered: November 2010
Karma: 0
|
Member |
|
|
"Jerry Stuckle" wrote in message news:jmjfdk$vmp$1(at)dont-email(dot)me...
>
> On 4/17/2012 4:18 AM, Tony Marston wrote:
>> "Jerry Stuckle" wrote in message news:jmhd8m$6jr$1(at)dont-email(dot)me...
>>>
>>> On 4/16/2012 10:11 AM, Tony Marston wrote:
>>>> "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message
>>>> news:jmh3iq$f4m$1(at)dont-email(dot)me...
>>>> > On 4/16/2012 4:31 AM, Tony Marston wrote:
>>>> >> "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message
>>>> >> news:jmeg9a$5pt$2(at)dont-email(dot)me...
>>>> >>> On 4/15/2012 3:33 AM, Tony Marston wrote:
>>>> >>>> "Peter H. Coffin"<hellsop(at)ninehells(dot)com> wrote in message
>>>> >>>> news:slrnjoj0b7(dot)4ci(dot)hellsop(at)nibelheim(dot)ninehells(dot)com...
>>>> >>>>> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote:
>>>> >>>>>>
>>>> >>>>>> "Charles"<cchamb2(at)gmail(dot)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
|
|
|
|
| Re: Dynamic form generation [message #177726 is a reply to message #177724] |
Wed, 18 April 2012 08:33 |
Tony Marston
Messages: 57
Registered: November 2010
Karma: 0
|
Member |
|
|
"Jerry Stuckle" wrote in message news:jmk2lu$hgn$1(at)dont-email(dot)me...
>
> On 4/17/2012 8:49 AM, Thomas 'PointedEars' Lahn wrote:
>> Denis McMahon wrote:
>>
>>> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote:
>>>> If you used a proper framework ...
>>>
>>> ... then you'd have all the junk and baggage that comes along with that
>>> framework, including any security flaws in the framework.
>>>
>>> Not saying that frameworks are inherently bad, but they're not
>>> automatically the solution either.
>>
>> TINSTAAFL. If you want complete flexibility of the application as the OP
>> wants, you have to have an abstraction layer in your application, i.e. it
>> has to be built on a framework (some people really should reflect on the
>> term "framework" and its etymology). Abstraction layers come at a price:
>> Increased overall complexity of the application and decreased efficiency
>> for
>> tasks that do not require as much flexibility.
>>
>
> Yup, and when you use a framework you force the application to match the
> framework, instead of allowing the application to meet the client's needs.
>
> It may work - but then it may not, also.
The client's needs are met by screens/reports which have the right layout
and which perform the right functions. My framework does not stand in the
way of that at all. When user transactions are initially generated they have
default screens and default behaviour, but these can be customised to
whatever level of sophistication you want.
>> Whether that framework was written by you or someone else is another
>> matter.
>> Chances are that a framework written by someone else has already gained
>> enough adoption in the global software community that its flaws –
>> including
>> security flaws – are more quickly detected and fixed than in a framework
>> that you have written yourself. On the other hand, chances are that a
>> framework you have written yourself can be better adjusted *by you* to do
>> what you want than a framework written by someone else, especially if you
>> created it for the same project in which you are using it.
>>
>
> So? Good programming practices and test cases will eliminate more security
> flaws than many of the "frameworks" out there. Have you seen some of the
> crap code which has been written "by committee"? Not all of it, but a lot
> of the donations are from people who don't really understand what they're
> doing - or at least don't write code like they know what they're doing.
>
>> Inevitably all frameworks become bloated if functionality for flexibility
>> keeps being added to them. It would appear that there is a point where a
>> framework author should stop improving it and start something new for a
>> new
>> project, maybe based on old code (but sometimes a rewrite is less
>> expensive
>> and turns out to be better). IOW, it is a good idea if you built
>> frameworks
>> with modularity in mind and use them only *as needed* (not simply for the
>> sake of using them, like trying to appear cool to the crowd).
>>
>>
>> PointedEars
>
> If a framework attempts to be "all things to all people", then that's quite
> true. But the same is true of *any* code.
>
> However, a limited framework with limited goals doesn't necessarily have to
> be the case.
>
> For instance, in my case - I have a framework which builds PHP classes to
> interface to a database. It generates a lot of usable code for those
> classes, including form handling.
So you framework generates "a lot" of code, does it? My framework generates
very small amounts of code which call shared functions or which inherit code
from abstract classes.
> However, since each class is pretty much independent, I can easily change
> a class without affecting the rest of the program.
So can I with my framework.
> I don't have it where it will work with multiple tables yet (something I
> will do one of these days), but it takes a huge amount of the repetitive
> work off of me.
Removing the need for all this repetitive coding, the "plumbing" as I call
it, is exactly what my framework does.
> And no, I don't try to use it for every project. But where a project is
> database-intensive, it suits my purposes.
All my applications are database-intensive, which is why I use a framework
which is centred around the database.
--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
|
|
|
|
| Re: Dynamic form generation [message #177727 is a reply to message #177726] |
Wed, 18 April 2012 11:59 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/18/2012 4:33 AM, Tony Marston wrote:
> "Jerry Stuckle" wrote in message news:jmk2lu$hgn$1(at)dont-email(dot)me...
>>
>> On 4/17/2012 8:49 AM, Thomas 'PointedEars' Lahn wrote:
>>> Denis McMahon wrote:
>>>
>>>> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote:
>>>> > If you used a proper framework ...
>>>>
>>>> ... then you'd have all the junk and baggage that comes along with that
>>>> framework, including any security flaws in the framework.
>>>>
>>>> Not saying that frameworks are inherently bad, but they're not
>>>> automatically the solution either.
>>>
>>> TINSTAAFL. If you want complete flexibility of the application as the OP
>>> wants, you have to have an abstraction layer in your application,
>>> i.e. it
>>> has to be built on a framework (some people really should reflect on the
>>> term "framework" and its etymology). Abstraction layers come at a price:
>>> Increased overall complexity of the application and decreased
>>> efficiency for
>>> tasks that do not require as much flexibility.
>>>
>>
>> Yup, and when you use a framework you force the application to match
>> the framework, instead of allowing the application to meet the
>> client's needs.
>>
>> It may work - but then it may not, also.
>
> The client's needs are met by screens/reports which have the right
> layout and which perform the right functions. My framework does not
> stand in the way of that at all. When user transactions are initially
> generated they have default screens and default behaviour, but these can
> be customised to whatever level of sophistication you want.
>
The client's needs are met by the APPLICATION. This is much more than
the screens and the layouts. But then if all you do are trivial
database applications, then I can see where something like that can help.
However, your example of over 200 tables and 350 relationships is a
perfect example of how bloated such code can become.
>>> Whether that framework was written by you or someone else is another
>>> matter.
>>> Chances are that a framework written by someone else has already gained
>>> enough adoption in the global software community that its flaws –
>>> including
>>> security flaws – are more quickly detected and fixed than in a framework
>>> that you have written yourself. On the other hand, chances are that a
>>> framework you have written yourself can be better adjusted *by you*
>>> to do
>>> what you want than a framework written by someone else, especially if
>>> you
>>> created it for the same project in which you are using it.
>>>
>>
>> So? Good programming practices and test cases will eliminate more
>> security flaws than many of the "frameworks" out there. Have you seen
>> some of the crap code which has been written "by committee"? Not all
>> of it, but a lot of the donations are from people who don't really
>> understand what they're doing - or at least don't write code like they
>> know what they're doing.
>>
>>> Inevitably all frameworks become bloated if functionality for
>>> flexibility
>>> keeps being added to them. It would appear that there is a point where a
>>> framework author should stop improving it and start something new for
>>> a new
>>> project, maybe based on old code (but sometimes a rewrite is less
>>> expensive
>>> and turns out to be better). IOW, it is a good idea if you built
>>> frameworks
>>> with modularity in mind and use them only *as needed* (not simply for
>>> the
>>> sake of using them, like trying to appear cool to the crowd).
>>>
>>>
>>> PointedEars
>>
>> If a framework attempts to be "all things to all people", then that's
>> quite true. But the same is true of *any* code.
>>
>> However, a limited framework with limited goals doesn't necessarily
>> have to be the case.
>>
>> For instance, in my case - I have a framework which builds PHP classes
>> to interface to a database. It generates a lot of usable code for
>> those classes, including form handling.
>
> So you framework generates "a lot" of code, does it? My framework
> generates very small amounts of code which call shared functions or
> which inherit code from abstract classes.
>
Yup, for instance, it generates all the set and get methods for the
applicable class, as well as database access code (insert/update/delete
for single rows and single rows and lists of multiple rows for SELECT).
(Most of the access code is in parent classes). It also generates the
code necessary to validate a field. Some stock fields (like "must be
integer") have predefined validation functions. Others, like passwords
where the rules may change, allow the validation to be handled by a
regex, function call or similar.
It also has the ability to generate forms html to display (read/write or
read only). And this is all one function. If I need a different layout
for a different page, it's easy to copy/paste a new function and redo
the output.
It also has a function to populate the object from $_GET or $_POST
values (with validation).
>> However, since each class is pretty much independent, I can easily
>> change a class without affecting the rest of the program.
>
> So can I with my framework.
>
>> I don't have it where it will work with multiple tables yet (something
>> I will do one of these days), but it takes a huge amount of the
>> repetitive work off of me.
>
> Removing the need for all this repetitive coding, the "plumbing" as I
> call it, is exactly what my framework does.
>
Not if it only generates a tiny bit of code.
>> And no, I don't try to use it for every project. But where a project
>> is database-intensive, it suits my purposes.
>
> All my applications are database-intensive, which is why I use a
> framework which is centred around the database.
>
Ah, that explains it, then. Database access is easy (although many
people can still screw that up). Most of my applications need to do
real work.
But I'm also not so stupid as to think that my frameworks is good for
everyone. It works for me. But I don't try to foist it off on someone
else without telling them it's my framework. That is just plain dishonest.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Dynamic form generation [message #177728 is a reply to message #177725] |
Wed, 18 April 2012 12:09 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/18/2012 4:10 AM, Tony Marston wrote:
> "Jerry Stuckle" wrote in message news:jmjfdk$vmp$1(at)dont-email(dot)me...
>>
>> On 4/17/2012 4:18 AM, Tony Marston wrote:
>>> "Jerry Stuckle" wrote in message news:jmhd8m$6jr$1(at)dont-email(dot)me...
>>>>
>>>> On 4/16/2012 10:11 AM, Tony Marston wrote:
>>>> > "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message
>>>> > news:jmh3iq$f4m$1(at)dont-email(dot)me...
>>>> >> On 4/16/2012 4:31 AM, Tony Marston wrote:
>>>> >>> "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message
>>>> >>> news:jmeg9a$5pt$2(at)dont-email(dot)me...
>>>> >>>> On 4/15/2012 3:33 AM, Tony Marston wrote:
>>>> >>>>> "Peter H. Coffin"<hellsop(at)ninehells(dot)com> wrote in message
>>>> >>>>> news:slrnjoj0b7(dot)4ci(dot)hellsop(at)nibelheim(dot)ninehells(dot)com...
>>>> >>>>>> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote:
>>>> >>>>>>>
>>>> >>>>>>> "Charles"<cchamb2(at)gmail(dot)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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Dynamic form generation [message #177738 is a reply to message #177728] |
Thu, 19 April 2012 08:27 |
Tony Marston
Messages: 57
Registered: November 2010
Karma: 0
|
Member |
|
|
"Jerry Stuckle" <jstucklex(at)attglobal(dot)net> wrote in message
news:jmmauq$9ke$1(at)dont-email(dot)me...
> On 4/18/2012 4:10 AM, Tony Marston wrote:
>> "Jerry Stuckle" wrote in message news:jmjfdk$vmp$1(at)dont-email(dot)me...
>>>
>>> On 4/17/2012 4:18 AM, Tony Marston wrote:
>>>> "Jerry Stuckle" wrote in message news:jmhd8m$6jr$1(at)dont-email(dot)me...
>>>> >
>>>> > On 4/16/2012 10:11 AM, Tony Marston wrote:
>>>> >> "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message
>>>> >> news:jmh3iq$f4m$1(at)dont-email(dot)me...
>>>> >>> On 4/16/2012 4:31 AM, Tony Marston wrote:
>>>> >>>> "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message
>>>> >>>> news:jmeg9a$5pt$2(at)dont-email(dot)me...
>>>> >>>>> On 4/15/2012 3:33 AM, Tony Marston wrote:
>>>> >>>>>> "Peter H. Coffin"<hellsop(at)ninehells(dot)com> wrote in message
>>>> >>>>>> news:slrnjoj0b7(dot)4ci(dot)hellsop(at)nibelheim(dot)ninehells(dot)com...
>>>> >>>>>>> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote:
>>>> >>>>>>>>
>>>> >>>>>>>> "Charles"<cchamb2(at)gmail(dot)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(at)attglobal(dot)net
> ==================
|
|
|
|
| Re: Dynamic form generation [message #177739 is a reply to message #177727] |
Thu, 19 April 2012 08:56 |
Tony Marston
Messages: 57
Registered: November 2010
Karma: 0
|
Member |
|
|
"Jerry Stuckle" <jstucklex(at)attglobal(dot)net> wrote in message
news:jmmabk$67a$1(at)dont-email(dot)me...
> On 4/18/2012 4:33 AM, Tony Marston wrote:
>> "Jerry Stuckle" wrote in message news:jmk2lu$hgn$1(at)dont-email(dot)me...
>>>
>>> On 4/17/2012 8:49 AM, Thomas 'PointedEars' Lahn wrote:
>>>> Denis McMahon wrote:
>>>>
>>>> > On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote:
>>>> >> If you used a proper framework ...
>>>> >
>>>> > ... then you'd have all the junk and baggage that comes along with
>>>> > that
>>>> > framework, including any security flaws in the framework.
>>>> >
>>>> > Not saying that frameworks are inherently bad, but they're not
>>>> > automatically the solution either.
>>>>
>>>> TINSTAAFL. If you want complete flexibility of the application as the
>>>> OP
>>>> wants, you have to have an abstraction layer in your application,
>>>> i.e. it
>>>> has to be built on a framework (some people really should reflect on
>>>> the
>>>> term "framework" and its etymology). Abstraction layers come at a
>>>> price:
>>>> Increased overall complexity of the application and decreased
>>>> efficiency for
>>>> tasks that do not require as much flexibility.
>>>>
>>>
>>> Yup, and when you use a framework you force the application to match
>>> the framework, instead of allowing the application to meet the
>>> client's needs.
>>>
>>> It may work - but then it may not, also.
>>
>> The client's needs are met by screens/reports which have the right
>> layout and which perform the right functions. My framework does not
>> stand in the way of that at all. When user transactions are initially
>> generated they have default screens and default behaviour, but these can
>> be customised to whatever level of sophistication you want.
>>
>
> The client's needs are met by the APPLICATION. This is much more than the
> screens and the layouts. But then if all you do are trivial database
> applications, then I can see where something like that can help.
An application is nothing more than a collection of individual components,
where each component does a "unit of work" from the user's point of view. A
small application has a small number of components, while a large
application has a large number of components.
> However, your example of over 200 tables and 350 relationships is a
> perfect example of how bloated such code can become.
The term "bloat" implies having things which are not used, and I can assure
you that every database table has a purpose and is used in one or more
transactions. If a database table ever became redundant then I would remove
it.
My databases are based on the designs in Len Silverston's Data Model
Resource book. So far I have implemented the PARTY, PRODUCT, ORDER,
INVENTORY, SHIPMENT, INVOICE, REQUEST and WORK-EFFORT databases. If you
bother to read his book you wil see that every table serves a purpose.
>>>> Whether that framework was written by you or someone else is another
>>>> matter.
>>>> Chances are that a framework written by someone else has already gained
>>>> enough adoption in the global software community that its flaws -
>>>> including
>>>> security flaws - are more quickly detected and fixed than in a
>>>> framework
>>>> that you have written yourself. On the other hand, chances are that a
>>>> framework you have written yourself can be better adjusted *by you*
>>>> to do
>>>> what you want than a framework written by someone else, especially if
>>>> you
>>>> created it for the same project in which you are using it.
>>>>
>>>
>>> So? Good programming practices and test cases will eliminate more
>>> security flaws than many of the "frameworks" out there. Have you seen
>>> some of the crap code which has been written "by committee"? Not all
>>> of it, but a lot of the donations are from people who don't really
>>> understand what they're doing - or at least don't write code like they
>>> know what they're doing.
>>>
>>>> Inevitably all frameworks become bloated if functionality for
>>>> flexibility
>>>> keeps being added to them. It would appear that there is a point where
>>>> a
>>>> framework author should stop improving it and start something new for
>>>> a new
>>>> project, maybe based on old code (but sometimes a rewrite is less
>>>> expensive
>>>> and turns out to be better). IOW, it is a good idea if you built
>>>> frameworks
>>>> with modularity in mind and use them only *as needed* (not simply for
>>>> the
>>>> sake of using them, like trying to appear cool to the crowd).
>>>>
>>>>
>>>> PointedEars
>>>
>>> If a framework attempts to be "all things to all people", then that's
>>> quite true. But the same is true of *any* code.
>>>
>>> However, a limited framework with limited goals doesn't necessarily
>>> have to be the case.
>>>
>>> For instance, in my case - I have a framework which builds PHP classes
>>> to interface to a database. It generates a lot of usable code for
>>> those classes, including form handling.
>>
>> So you framework generates "a lot" of code, does it? My framework
>> generates very small amounts of code which call shared functions or
>> which inherit code from abstract classes.
>>
>
> Yup, for instance, it generates all the set and get methods for the
> applicable class, as well as database access code (insert/update/delete
> for single rows and single rows and lists of multiple rows for SELECT).
> (Most of the access code is in parent classes).
My framework does not bother generating set and get methods as they are
inefficient. Data goes in and comes out as an array.
My framework does not generate any database access code as that is already
provided by my Data Access Object (DAO). I have one for MySQL, one for
PostgreSQL, one for Oracle and another for SQL Server. I can switch from one
to another simply by changing a single line in a config file.
> It also generates the code necessary to validate a field. Some stock
> fields (like "must be integer") have predefined validation functions.
My framework does not generate any code to perform basic field validation as
that is performed by a validation class which I wrote years ago.
> Others, like passwords where the rules may change, allow the validation
> to be handled by a regex, function call or similar.
In my framework any password rues - such as minimum length, the number of
uppercase characters, the number of lowercase characters, the number of
digits - is controlled from a database record. Each customer can therefore
change the rules without me having to change any code.
> It also has the ability to generate forms html to display (read/write or
> read only). And this is all one function. If I need a different layout
> for a different page, it's easy to copy/paste a new function and redo the
> output.
Copy/Paste? That produces duplicate code, not sharable code, and even you
should know that duplicate code violates the DRY principle.
> It also has a function to populate the object from $_GET or $_POST values
> (with validation).
I don't need a whole function to do that when a single line will do:-
$result = $object->insertRecord($_POST);
This means that the same line will work on any object regardless of which
class it came from. That is what polymorphism is all about.
>>> However, since each class is pretty much independent, I can easily
>>> change a class without affecting the rest of the program.
>>
>> So can I with my framework.
>>
>>> I don't have it where it will work with multiple tables yet (something
>>> I will do one of these days), but it takes a huge amount of the
>>> repetitive work off of me.
>>
>> Removing the need for all this repetitive coding, the "plumbing" as I
>> call it, is exactly what my framework does.
>>
>
> Not if it only generates a tiny bit of code.
You are missing the point as usual. My framework need only generate a small
amount of code as everything else, especially all the standard plumbing, is
included from standard pre-written functions.
>>> And no, I don't try to use it for every project. But where a project
>>> is database-intensive, it suits my purposes.
>>
>> All my applications are database-intensive, which is why I use a
>> framework which is centred around the database.
>>
>
> Ah, that explains it, then. Database access is easy (although many people
> can still screw that up). Most of my applications need to do real work.
My framework takes care of all the standard database access, and getting
data in and out of the screen, plus basic data validation. As for the "real
work" as you call - or the "payload" as I call it - that is done by adding
whatever code is necessary in the relevant class to implement each business
rule. The point is that when using my framework the programmer has to spend
little or no time on the standard plumbing, which leaves him with much more
time to spend on the payload.
> But I'm also not so stupid as to think that my frameworks is good for
> everyone. It works for me. But I don't try to foist it off on someone
> else without telling them it's my framework. That is just plain
> dishonest.
I never said that my framework is the perfect solution for everyone. If you
a writing a simple website then it's not good, but if you are writing a
database application then it's better than most.
I was never dishonest about the Radicore framework. I never said it was
written by someone else. I even include a link to the radicore website in my
signature.
If *your* framework is so good, then why don't you release it as open source
so that we call all have a laugh?
--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
|
|
|
|
| Re: Dynamic form generation [message #177742 is a reply to message #177739] |
Thu, 19 April 2012 12:29 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/19/2012 4:56 AM, Tony Marston wrote:
> "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message
> news:jmmabk$67a$1(at)dont-email(dot)me...
>> On 4/18/2012 4:33 AM, Tony Marston wrote:
>>> "Jerry Stuckle" wrote in message news:jmk2lu$hgn$1(at)dont-email(dot)me...
>>>>
>>>> On 4/17/2012 8:49 AM, Thomas 'PointedEars' Lahn wrote:
>>>> > Denis McMahon wrote:
>>>> >
>>>> >> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote:
>>>> >>> If you used a proper framework ...
>>>> >>
>>>> >> ... then you'd have all the junk and baggage that comes along with
>>>> >> that
>>>> >> framework, including any security flaws in the framework.
>>>> >>
>>>> >> Not saying that frameworks are inherently bad, but they're not
>>>> >> automatically the solution either.
>>>> >
>>>> > TINSTAAFL. If you want complete flexibility of the application as the
>>>> > OP
>>>> > wants, you have to have an abstraction layer in your application,
>>>> > i.e. it
>>>> > has to be built on a framework (some people really should reflect on
>>>> > the
>>>> > term "framework" and its etymology). Abstraction layers come at a
>>>> > price:
>>>> > Increased overall complexity of the application and decreased
>>>> > efficiency for
>>>> > tasks that do not require as much flexibility.
>>>> >
>>>>
>>>> Yup, and when you use a framework you force the application to match
>>>> the framework, instead of allowing the application to meet the
>>>> client's needs.
>>>>
>>>> It may work - but then it may not, also.
>>>
>>> The client's needs are met by screens/reports which have the right
>>> layout and which perform the right functions. My framework does not
>>> stand in the way of that at all. When user transactions are initially
>>> generated they have default screens and default behaviour, but these can
>>> be customised to whatever level of sophistication you want.
>>>
>>
>> The client's needs are met by the APPLICATION. This is much more than the
>> screens and the layouts. But then if all you do are trivial database
>> applications, then I can see where something like that can help.
>
> An application is nothing more than a collection of individual components,
> where each component does a "unit of work" from the user's point of view. A
> small application has a small number of components, while a large
> application has a large number of components.
>
I can understand how someone like you who does such simple stuff things
that way. But then you've never worked on something even moderately
complex.
A large application is much more complex than just having "a large
number of components".
>> However, your example of over 200 tables and 350 relationships is a
>> perfect example of how bloated such code can become.
>
> The term "bloat" implies having things which are not used, and I can assure
> you that every database table has a purpose and is used in one or more
> transactions. If a database table ever became redundant then I would remove
> it.
>
Not at all. "Bloat" also refers to applications which are overly large
for what needs to be done.
> My databases are based on the designs in Len Silverston's Data Model
> Resource book. So far I have implemented the PARTY, PRODUCT, ORDER,
> INVENTORY, SHIPMENT, INVOICE, REQUEST and WORK-EFFORT databases. If you
> bother to read his book you wil see that every table serves a purpose.
>
Yes, that works fine for simple applications. But then you've already
said that's all you do. You've never worked on anything even moderately
complex.
>>>> > Whether that framework was written by you or someone else is another
>>>> > matter.
>>>> > Chances are that a framework written by someone else has already gained
>>>> > enough adoption in the global software community that its flaws -
>>>> > including
>>>> > security flaws - are more quickly detected and fixed than in a
>>>> > framework
>>>> > that you have written yourself. On the other hand, chances are that a
>>>> > framework you have written yourself can be better adjusted *by you*
>>>> > to do
>>>> > what you want than a framework written by someone else, especially if
>>>> > you
>>>> > created it for the same project in which you are using it.
>>>> >
>>>>
>>>> So? Good programming practices and test cases will eliminate more
>>>> security flaws than many of the "frameworks" out there. Have you seen
>>>> some of the crap code which has been written "by committee"? Not all
>>>> of it, but a lot of the donations are from people who don't really
>>>> understand what they're doing - or at least don't write code like they
>>>> know what they're doing.
>>>>
>>>> > Inevitably all frameworks become bloated if functionality for
>>>> > flexibility
>>>> > keeps being added to them. It would appear that there is a point where
>>>> > a
>>>> > framework author should stop improving it and start something new for
>>>> > a new
>>>> > project, maybe based on old code (but sometimes a rewrite is less
>>>> > expensive
>>>> > and turns out to be better). IOW, it is a good idea if you built
>>>> > frameworks
>>>> > with modularity in mind and use them only *as needed* (not simply for
>>>> > the
>>>> > sake of using them, like trying to appear cool to the crowd).
>>>> >
>>>> >
>>>> > PointedEars
>>>>
>>>> If a framework attempts to be "all things to all people", then that's
>>>> quite true. But the same is true of *any* code.
>>>>
>>>> However, a limited framework with limited goals doesn't necessarily
>>>> have to be the case.
>>>>
>>>> For instance, in my case - I have a framework which builds PHP classes
>>>> to interface to a database. It generates a lot of usable code for
>>>> those classes, including form handling.
>>>
>>> So you framework generates "a lot" of code, does it? My framework
>>> generates very small amounts of code which call shared functions or
>>> which inherit code from abstract classes.
>>>
>>
>> Yup, for instance, it generates all the set and get methods for the
>> applicable class, as well as database access code (insert/update/delete
>> for single rows and single rows and lists of multiple rows for SELECT).
>> (Most of the access code is in parent classes).
>
> My framework does not bother generating set and get methods as they are
> inefficient. Data goes in and comes out as an array.
>
Yea, that's why your code is crap. You obviously know nothing about
proper OO coding techniques. And that means in order to change one item
in the object the user has to build an array for the whole thing?
Bloat... Bloat... Bloat...
> My framework does not generate any database access code as that is already
> provided by my Data Access Object (DAO). I have one for MySQL, one for
> PostgreSQL, one for Oracle and another for SQL Server. I can switch from one
> to another simply by changing a single line in a config file.
>
Yes, you always waste a lot of time retrieving all columns, whether they
are needed or not. And you update all columns, whether you need to or
not. Bloatware.
>> It also generates the code necessary to validate a field. Some stock
>> fields (like "must be integer") have predefined validation functions.
>
> My framework does not generate any code to perform basic field validation as
> that is performed by a validation class which I wrote years ago.
>
More bloat. And tell me how your class handles a rule such as "8-16
characters, must have both upper and lower case and at least one digit".
Or how about the bloat of calling a class to verify the input is an
integer when a simple one line statement works. More bloat.
>> Others, like passwords where the rules may change, allow the validation
>> to be handled by a regex, function call or similar.
>
> In my framework any password rues - such as minimum length, the number of
> uppercase characters, the number of lowercase characters, the number of
> digits - is controlled from a database record. Each customer can therefore
> change the rules without me having to change any code.
>
More bloat. And unnecessary.
>> It also has the ability to generate forms html to display (read/write or
>> read only). And this is all one function. If I need a different layout
>> for a different page, it's easy to copy/paste a new function and redo the
>> output.
>
> Copy/Paste? That produces duplicate code, not sharable code, and even you
> should know that duplicate code violates the DRY principle.
>
You obviously don't understand the DRY principle. Just because you
copy/paste does not mean it's duplicate code. Once the code has been
modified to do something else, it is no longer duplicate.
>> It also has a function to populate the object from $_GET or $_POST values
>> (with validation).
>
> I don't need a whole function to do that when a single line will do:-
> $result = $object->insertRecord($_POST);
>
So what is insertRecord($_POST) then, if it's not a function? Once
again you show your ignorance. Don't even know what a function is!
> This means that the same line will work on any object regardless of which
> class it came from. That is what polymorphism is all about.
>
Nope, that's not at all what polymorphism is about. But you obviously
don't understand polymorphism, either.
>>>> However, since each class is pretty much independent, I can easily
>>>> change a class without affecting the rest of the program.
>>>
>>> So can I with my framework.
>>>
>>>> I don't have it where it will work with multiple tables yet (something
>>>> I will do one of these days), but it takes a huge amount of the
>>>> repetitive work off of me.
>>>
>>> Removing the need for all this repetitive coding, the "plumbing" as I
>>> call it, is exactly what my framework does.
>>>
>>
>> Not if it only generates a tiny bit of code.
>
> You are missing the point as usual. My framework need only generate a small
> amount of code as everything else, especially all the standard plumbing, is
> included from standard pre-written functions.
>
No, I'm missing nothing. But you've clearly shown just how crappy your
code is.
>>>> And no, I don't try to use it for every project. But where a project
>>>> is database-intensive, it suits my purposes.
>>>
>>> All my applications are database-intensive, which is why I use a
>>> framework which is centred around the database.
>>>
>>
>> Ah, that explains it, then. Database access is easy (although many people
>> can still screw that up). Most of my applications need to do real work.
>
> My framework takes care of all the standard database access, and getting
> data in and out of the screen, plus basic data validation. As for the "real
> work" as you call - or the "payload" as I call it - that is done by adding
> whatever code is necessary in the relevant class to implement each business
> rule. The point is that when using my framework the programmer has to spend
> little or no time on the standard plumbing, which leaves him with much more
> time to spend on the payload.
>
Yup, you've never done any applications which require real work, as you
once again have shown.
>> But I'm also not so stupid as to think that my frameworks is good for
>> everyone. It works for me. But I don't try to foist it off on someone
>> else without telling them it's my framework. That is just plain
>> dishonest.
>
> I never said that my framework is the perfect solution for everyone. If you
> a writing a simple website then it's not good, but if you are writing a
> database application then it's better than most.
>
Hmmm, you sure seemed to indicate that when you first started pushing
this piece of horse hockey.
> I was never dishonest about the Radicore framework. I never said it was
> written by someone else. I even include a link to the radicore website in my
> signature.
>
And you never said it was written by you, and that you were nowhere near
an unbiased user. The fact you are pushing your own product without
telling people you have a vested interest is dishonest. The fact you
have a link to it in your sig is immaterial - lots of people have links
in their sigs to all kinds of things.
But then I can see why you don't want to tell people it's your product.
I wouldn't want to admit to having created that piece of horse hockey,
either.
> If *your* framework is so good, then why don't you release it as open source
> so that we call all have a laugh?
>
For a lot of reasons. Mainly because I'm not interested in the hassles
of having to support it for a bunch of people who want all kinds of
other features. I created it for my projects, and it serves those
projects well.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Dynamic form generation [message #177743 is a reply to message #177738] |
Thu, 19 April 2012 12:41 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/19/2012 4:27 AM, Tony Marston wrote:
> "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message
> news:jmmauq$9ke$1(at)dont-email(dot)me...
>> On 4/18/2012 4:10 AM, Tony Marston wrote:
>>> "Jerry Stuckle" wrote in message news:jmjfdk$vmp$1(at)dont-email(dot)me...
>>>>
>>>> On 4/17/2012 4:18 AM, Tony Marston wrote:
>>>> > "Jerry Stuckle" wrote in message news:jmhd8m$6jr$1(at)dont-email(dot)me...
>>>> >>
>>>> >> On 4/16/2012 10:11 AM, Tony Marston wrote:
>>>> >>> "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message
>>>> >>> news:jmh3iq$f4m$1(at)dont-email(dot)me...
>>>> >>>> On 4/16/2012 4:31 AM, Tony Marston wrote:
>>>> >>>>> "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message
>>>> >>>>> news:jmeg9a$5pt$2(at)dont-email(dot)me...
>>>> >>>>>> On 4/15/2012 3:33 AM, Tony Marston wrote:
>>>> >>>>>>> "Peter H. Coffin"<hellsop(at)ninehells(dot)com> wrote in message
>>>> >>>>>>> news:slrnjoj0b7(dot)4ci(dot)hellsop(at)nibelheim(dot)ninehells(dot)com...
>>>> >>>>>>>> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote:
>>>> >>>>>>>>>
>>>> >>>>>>>>> "Charles"<cchamb2(at)gmail(dot)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(at)attglobal(dot)net
>> ==================
>
>
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Dynamic form generation [message #177752 is a reply to message #177742] |
Fri, 20 April 2012 08:27 |
Tony Marston
Messages: 57
Registered: November 2010
Karma: 0
|
Member |
|
|
"Jerry Stuckle" wrote in message news:jmp0gb$d8$1(at)dont-email(dot)me...
>
> On 4/19/2012 4:56 AM, Tony Marston wrote:
>> "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message
>> news:jmmabk$67a$1(at)dont-email(dot)me...
>>> On 4/18/2012 4:33 AM, Tony Marston wrote:
>>>> "Jerry Stuckle" wrote in message news:jmk2lu$hgn$1(at)dont-email(dot)me...
>>>> >
>>>> > On 4/17/2012 8:49 AM, Thomas 'PointedEars' Lahn wrote:
>>>> >> Denis McMahon wrote:
>>>> >>
>>>> >>> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote:
>>>> >>>> If you used a proper framework ...
>>>> >>>
>>>> >>> ... then you'd have all the junk and baggage that comes along with
>>>> >>> that
>>>> >>> framework, including any security flaws in the framework.
>>>> >>>
>>>> >>> Not saying that frameworks are inherently bad, but they're not
>>>> >>> automatically the solution either.
>>>> >>
>>>> >> TINSTAAFL. If you want complete flexibility of the application as the
>>>> >> OP
>>>> >> wants, you have to have an abstraction layer in your application,
>>>> >> i.e. it
>>>> >> has to be built on a framework (some people really should reflect on
>>>> >> the
>>>> >> term "framework" and its etymology). Abstraction layers come at a
>>>> >> price:
>>>> >> Increased overall complexity of the application and decreased
>>>> >> efficiency for
>>>> >> tasks that do not require as much flexibility.
>>>> >>
>>>> >
>>>> > Yup, and when you use a framework you force the application to match
>>>> > the framework, instead of allowing the application to meet the
>>>> > client's needs.
>>>> >
>>>> > It may work - but then it may not, also.
>>>>
>>>> The client's needs are met by screens/reports which have the right
>>>> layout and which perform the right functions. My framework does not
>>>> stand in the way of that at all. When user transactions are initially
>>>> generated they have default screens and default behaviour, but these
>>>> can
>>>> be customised to whatever level of sophistication you want.
>>>>
>>>
>>> The client's needs are met by the APPLICATION. This is much more than
>>> the
>>> screens and the layouts. But then if all you do are trivial database
>>> applications, then I can see where something like that can help.
>>
>> An application is nothing more than a collection of individual
>> components,
>> where each component does a "unit of work" from the user's point of view.
>> A
>> small application has a small number of components, while a large
>> application has a large number of components.
>>
>
> I can understand how someone like you who does such simple stuff things
> that way. But then you've never worked on something even moderately
> complex.
Building an entire ERP system with 1700 transactions is much more than
"simple". I work on business applications for corporations, not toy systems
for hobbyists.
> A large application is much more complex than just having "a large number
> of components".
I disagree. An application which uses 200 database tables is more complex
than one which uses only 2, and the more tables you have the more
maintenance screens you require.
>>> However, your example of over 200 tables and 350 relationships is a
>>> perfect example of how bloated such code can become.
>>
>> The term "bloat" implies having things which are not used, and I can
>> assure
>> you that every database table has a purpose and is used in one or more
>> transactions. If a database table ever became redundant then I would
>> remove
>> it.
>>
>
> Not at all. "Bloat" also refers to applications which are overly large for
> what needs to be done.
My applications are not overly large. While I have a large number of small
transactions each of which does one thing, this is not "bloat", it is
following the Single Responsibility Principle.
>> My databases are based on the designs in Len Silverston's Data Model
>> Resource book. So far I have implemented the PARTY, PRODUCT, ORDER,
>> INVENTORY, SHIPMENT, INVOICE, REQUEST and WORK-EFFORT databases. If you
>> bother to read his book you wil see that every table serves a purpose.
>>
>
> Yes, that works fine for simple applications. But then you've already said
> that's all you do. You've never worked on anything even moderately
> complex.
I would like to see *YOU* design and build an ERP application basedon those
databases and then tell me it's simple!
>>>> >> Whether that framework was written by you or someone else is another
>>>> >> matter.
>>>> >> Chances are that a framework written by someone else has already
>>>> >> gained
>>>> >> enough adoption in the global software community that its flaws -
>>>> >> including
>>>> >> security flaws - are more quickly detected and fixed than in a
>>>> >> framework
>>>> >> that you have written yourself. On the other hand, chances are that a
>>>> >> framework you have written yourself can be better adjusted *by you*
>>>> >> to do
>>>> >> what you want than a framework written by someone else, especially if
>>>> >> you
>>>> >> created it for the same project in which you are using it.
>>>> >>
>>>> >
>>>> > So? Good programming practices and test cases will eliminate more
>>>> > security flaws than many of the "frameworks" out there. Have you seen
>>>> > some of the crap code which has been written "by committee"? Not all
>>>> > of it, but a lot of the donations are from people who don't really
>>>> > understand what they're doing - or at least don't write code like they
>>>> > know what they're doing.
>>>> >
>>>> >> Inevitably all frameworks become bloated if functionality for
>>>> >> flexibility
>>>> >> keeps being added to them. It would appear that there is a point
>>>> >> where
>>>> >> a
>>>> >> framework author should stop improving it and start something new for
>>>> >> a new
>>>> >> project, maybe based on old code (but sometimes a rewrite is less
>>>> >> expensive
>>>> >> and turns out to be better). IOW, it is a good idea if you built
>>>> >> frameworks
>>>> >> with modularity in mind and use them only *as needed* (not simply for
>>>> >> the
>>>> >> sake of using them, like trying to appear cool to the crowd).
>>>> >>
>>>> >>
>>>> >> PointedEars
>>>> >
>>>> > If a framework attempts to be "all things to all people", then that's
>>>> > quite true. But the same is true of *any* code.
>>>> >
>>>> > However, a limited framework with limited goals doesn't necessarily
>>>> > have to be the case.
>>>> >
>>>> > For instance, in my case - I have a framework which builds PHP classes
>>>> > to interface to a database. It generates a lot of usable code for
>>>> > those classes, including form handling.
>>>>
>>>> So you framework generates "a lot" of code, does it? My framework
>>>> generates very small amounts of code which call shared functions or
>>>> which inherit code from abstract classes.
>>>>
>>>
>>> Yup, for instance, it generates all the set and get methods for the
>>> applicable class, as well as database access code (insert/update/delete
>>> for single rows and single rows and lists of multiple rows for SELECT).
>>> (Most of the access code is in parent classes).
>>
>> My framework does not bother generating set and get methods as they are
>> inefficient. Data goes in and comes out as an array.
>>
>
> Yea, that's why your code is crap. You obviously know nothing about proper
> OO coding techniques. And that means in order to change one item in the
> object the user has to build an array for the whole thing? Bloat...
> Bloat... Bloat...
You obviously don't know what "proper OO" actually means. And where did I
say that in order to change one item in the object the user has to build an
array for the whole thing? You are reading things which I did not write.
>> My framework does not generate any database access code as that is
>> already
>> provided by my Data Access Object (DAO). I have one for MySQL, one for
>> PostgreSQL, one for Oracle and another for SQL Server. I can switch from
>> one
>> to another simply by changing a single line in a config file.
>>
>
> Yes, you always waste a lot of time retrieving all columns, whether they
> are needed or not. And you update all columns, whether you need to or not.
> Bloatware.
You are jumping to the wrong conclusion AGAIN! The default is to read all
columns simply because by default all columns are displayed on the screen.
The defaults can be changed.
>>> It also generates the code necessary to validate a field. Some stock
>>> fields (like "must be integer") have predefined validation functions.
>>
>> My framework does not generate any code to perform basic field validation
>> as
>> that is performed by a validation class which I wrote years ago.
>>
>
> More bloat. And tell me how your class handles a rule such as "8-16
> characters, must have both upper and lower case and at least one digit".
Easy peasy. I just set these values in the database:
min_length = 8
max_length = 16
upper_case = 1
lower_case = 1
num_digits = 1
> Or how about the bloat of calling a class to verify the input is an integer
> when a simple one line statement works. More bloat.
I have a validation class which is capable of validating every data type.
This means that I do not have to write the line of code which tests that a
piece of input is an integer. Not having to write that line is not bloat.
>>> Others, like passwords where the rules may change, allow the
>>> validation
>>> to be handled by a regex, function call or similar.
>>
>> In my framework any password rues - such as minimum length, the number of
>> uppercase characters, the number of lowercase characters, the number of
>> digits - is controlled from a database record. Each customer can
>> therefore
>> change the rules without me having to change any code.
>>
>
> More bloat. And unnecessary.
It is necessary if I want to allow the customer to change the password
validation rules without having to write any code. Not having to write code
is not bloat.
>>> It also has the ability to generate forms html to display (read/write or
>>> read only). And this is all one function. If I need a different layout
>>> for a different page, it's easy to copy/paste a new function and redo
>>> the
>>> output.
>>
>> Copy/Paste? That produces duplicate code, not sharable code, and even you
>> should know that duplicate code violates the DRY principle.
>>
>
> You obviously don't understand the DRY principle. Just because you
> copy/paste does not mean it's duplicate code. Once the code has been
> modified to do something else, it is no longer duplicate.
If you were really clever you wouldn't have to copy/paste/modify, you would
have a reusable module. In my MVC implementation I have a fixed set of
controllers, and each controller is reusable. Can you say the same in your
framework?
>>> It also has a function to populate the object from $_GET or $_POST
>>> values
>>> (with validation).
>>
>> I don't need a whole function to do that when a single line will do:-
>> $result = $object->insertRecord($_POST);
>>
>
> So what is insertRecord($_POST) then, if it's not a function? Once again
> you show your ignorance. Don't even know what a function is!
What I'm saying is that I don't have a function which splits the $_POST
array into its component parts so I can then use a setter on each component,
I simply inject the entire $_POST array in a single operation without the
need to split it down into its component parts.
>> This means that the same line will work on any object regardless of which
>> class it came from. That is what polymorphism is all about.
>>
>
> Nope, that's not at all what polymorphism is about. But you obviously
> don't understand polymorphism, either.
The definition of polymorphism which I use is "same method, different
implementation". What definition do you use?
>>>> > However, since each class is pretty much independent, I can easily
>>>> > change a class without affecting the rest of the program.
>>>>
>>>> So can I with my framework.
>>>>
>>>> > I don't have it where it will work with multiple tables yet (something
>>>> > I will do one of these days), but it takes a huge amount of the
>>>> > repetitive work off of me.
>>>>
>>>> Removing the need for all this repetitive coding, the "plumbing" as I
>>>> call it, is exactly what my framework does.
>>>>
>>>
>>> Not if it only generates a tiny bit of code.
>>
>> You are missing the point as usual. My framework need only generate a
>> small
>> amount of code as everything else, especially all the standard plumbing,
>> is
>> included from standard pre-written functions.
>>
>
> No, I'm missing nothing. But you've clearly shown just how crappy your
> code is.
Just because it's different from yours does not make it crap.
>>>> > And no, I don't try to use it for every project. But where a project
>>>> > is database-intensive, it suits my purposes.
>>>>
>>>> All my applications are database-intensive, which is why I use a
>>>> framework which is centred around the database.
>>>>
>>>
>>> Ah, that explains it, then. Database access is easy (although many
>>> people
>>> can still screw that up). Most of my applications need to do real work.
>>
>> My framework takes care of all the standard database access, and getting
>> data in and out of the screen, plus basic data validation. As for the
>> "real
>> work" as you call - or the "payload" as I call it - that is done by
>> adding
>> whatever code is necessary in the relevant class to implement each
>> business
>> rule. The point is that when using my framework the programmer has to
>> spend
>> little or no time on the standard plumbing, which leaves him with much
>> more
>> time to spend on the payload.
>>
>
> Yup, you've never done any applications which require real work, as you
> once again have shown.
Then you obviously have not experienced the complicated things which need to
be done in an ERP application.
>>> But I'm also not so stupid as to think that my frameworks is good for
>>> everyone. It works for me. But I don't try to foist it off on someone
>>> else without telling them it's my framework. That is just plain
>>> dishonest.
>>
>> I never said that my framework is the perfect solution for everyone. If
>> you
>> a writing a simple website then it's not good, but if you are writing a
>> database application then it's better than most.
>>
>
> Hmmm, you sure seemed to indicate that when you first started pushing this
> piece of horse hockey.
That may have been the impression that you got, but you have indicated time
and time again that your mind works in mysterious ways.
>> I was never dishonest about the Radicore framework. I never said it was
>> written by someone else. I even include a link to the radicore website in
>> my
>> signature.
>>
>
> And you never said it was written by you, and that you were nowhere near an
> unbiased user. The fact you are pushing your own product without telling
> people you have a vested interest is dishonest. The fact you have a link
> to it in your sig is immaterial - lots of people have links in their sigs
> to all kinds of things.
>
> But then I can see why you don't want to tell people it's your product. I
> wouldn't want to admit to having created that piece of horse hockey,
> either.
You're the expert in horse hockey judging by the amount you write in these
posts.
>> If *your* framework is so good, then why don't you release it as open
>> source
>> so that we call all have a laugh?
>>
>
> For a lot of reasons. Mainly because I'm not interested in the hassles of
> having to support it for a bunch of people who want all kinds of other
> features. I created it for my projects, and it serves those projects well.
What you really mean is that you are too ashamed to have it reviewed by your
peers, and that you are incapable of writing code which can be used by
others.
--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
|
|
|
|
| Re: Dynamic form generation [message #177755 is a reply to message #177743] |
Fri, 20 April 2012 09:10 |
Tony Marston
Messages: 57
Registered: November 2010
Karma: 0
|
Member |
|
|
"Jerry Stuckle" wrote in message news:jmp154$4tt$1(at)dont-email(dot)me...
>
> On 4/19/2012 4:27 AM, Tony Marston wrote:
>> "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message
>> news:jmmauq$9ke$1(at)dont-email(dot)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
|
|
|
|
| Re: Dynamic form generation [message #177760 is a reply to message #177752] |
Fri, 20 April 2012 11:47 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/20/2012 4:27 AM, Tony Marston wrote:
> "Jerry Stuckle" wrote in message news:jmp0gb$d8$1(at)dont-email(dot)me...
>>
>> On 4/19/2012 4:56 AM, Tony Marston wrote:
>>> "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message
>>> news:jmmabk$67a$1(at)dont-email(dot)me...
>>>> On 4/18/2012 4:33 AM, Tony Marston wrote:
>>>> > "Jerry Stuckle" wrote in message news:jmk2lu$hgn$1(at)dont-email(dot)me...
>>>> >>
>>>> >> On 4/17/2012 8:49 AM, Thomas 'PointedEars' Lahn wrote:
>>>> >>> Denis McMahon wrote:
>>>> >>>
>>>> >>>> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote:
>>>> >>>>> If you used a proper framework ...
>>>> >>>>
>>>> >>>> ... then you'd have all the junk and baggage that comes along with
>>>> >>>> that
>>>> >>>> framework, including any security flaws in the framework.
>>>> >>>>
>>>> >>>> Not saying that frameworks are inherently bad, but they're not
>>>> >>>> automatically the solution either.
>>>> >>>
>>>> >>> TINSTAAFL. If you want complete flexibility of the application as
>>>> >>> the
>>>> >>> OP
>>>> >>> wants, you have to have an abstraction layer in your application,
>>>> >>> i.e. it
>>>> >>> has to be built on a framework (some people really should reflect on
>>>> >>> the
>>>> >>> term "framework" and its etymology). Abstraction layers come at a
>>>> >>> price:
>>>> >>> Increased overall complexity of the application and decreased
>>>> >>> efficiency for
>>>> >>> tasks that do not require as much flexibility.
>>>> >>>
>>>> >>
>>>> >> Yup, and when you use a framework you force the application to match
>>>> >> the framework, instead of allowing the application to meet the
>>>> >> client's needs.
>>>> >>
>>>> >> It may work - but then it may not, also.
>>>> >
>>>> > The client's needs are met by screens/reports which have the right
>>>> > layout and which perform the right functions. My framework does not
>>>> > stand in the way of that at all. When user transactions are initially
>>>> > generated they have default screens and default behaviour, but
>>>> > these can
>>>> > be customised to whatever level of sophistication you want.
>>>> >
>>>>
>>>> The client's needs are met by the APPLICATION. This is much more
>>>> than the
>>>> screens and the layouts. But then if all you do are trivial database
>>>> applications, then I can see where something like that can help.
>>>
>>> An application is nothing more than a collection of individual
>>> components,
>>> where each component does a "unit of work" from the user's point of
>>> view. A
>>> small application has a small number of components, while a large
>>> application has a large number of components.
>>>
>>
>> I can understand how someone like you who does such simple stuff
>> things that way. But then you've never worked on something even
>> moderately complex.
>
> Building an entire ERP system with 1700 transactions is much more than
> "simple". I work on business applications for corporations, not toy
> systems for hobbyists.
>
Building a *decent* ERP is complex. SAP, for instance, has a good one.
They have several hundred programmers working on it constantly.
What you call an "ERP" is nothing like that.
>> A large application is much more complex than just having "a large
>> number of components".
>
> I disagree. An application which uses 200 database tables is more
> complex than one which uses only 2, and the more tables you have the
> more maintenance screens you require.
>
That's because you've never worked on a complex application. Your claim
of an ERP is proof of that.
All you do is database stuff. There's nothing complex about that.
>>>> However, your example of over 200 tables and 350 relationships is a
>>>> perfect example of how bloated such code can become.
>>>
>>> The term "bloat" implies having things which are not used, and I can
>>> assure
>>> you that every database table has a purpose and is used in one or more
>>> transactions. If a database table ever became redundant then I would
>>> remove
>>> it.
>>>
>>
>> Not at all. "Bloat" also refers to applications which are overly large
>> for what needs to be done.
>
> My applications are not overly large. While I have a large number of
> small transactions each of which does one thing, this is not "bloat", it
> is following the Single Responsibility Principle.
>
>
Nope, they aren't, because your applications are just for database access.
But they sure sound like they're bloated.
>> My databases are based on the designs in Len Silverston's Data Model
>>> Resource book. So far I have implemented the PARTY, PRODUCT, ORDER,
>>> INVENTORY, SHIPMENT, INVOICE, REQUEST and WORK-EFFORT databases. If you
>>> bother to read his book you wil see that every table serves a purpose.
>>>
>>
>> Yes, that works fine for simple applications. But then you've already
>> said that's all you do. You've never worked on anything even
>> moderately complex.
>
> I would like to see *YOU* design and build an ERP application basedon
> those databases and then tell me it's simple!
>
I'd like to see YOU create a REAL ERP application! All you did was
build database access to multiple tables. ERP is much more than that.
>>>> >>> Whether that framework was written by you or someone else is another
>>>> >>> matter.
>>>> >>> Chances are that a framework written by someone else has already
>>>> >>> gained
>>>> >>> enough adoption in the global software community that its flaws -
>>>> >>> including
>>>> >>> security flaws - are more quickly detected and fixed than in a
>>>> >>> framework
>>>> >>> that you have written yourself. On the other hand, chances are
>>>> >>> that a
>>>> >>> framework you have written yourself can be better adjusted *by you*
>>>> >>> to do
>>>> >>> what you want than a framework written by someone else,
>>>> >>> especially if
>>>> >>> you
>>>> >>> created it for the same project in which you are using it.
>>>> >>>
>>>> >>
>>>> >> So? Good programming practices and test cases will eliminate more
>>>> >> security flaws than many of the "frameworks" out there. Have you seen
>>>> >> some of the crap code which has been written "by committee"? Not all
>>>> >> of it, but a lot of the donations are from people who don't really
>>>> >> understand what they're doing - or at least don't write code like
>>>> >> they
>>>> >> know what they're doing.
>>>> >>
>>>> >>> Inevitably all frameworks become bloated if functionality for
>>>> >>> flexibility
>>>> >>> keeps being added to them. It would appear that there is a point
>>>> >>> where
>>>> >>> a
>>>> >>> framework author should stop improving it and start something new
>>>> >>> for
>>>> >>> a new
>>>> >>> project, maybe based on old code (but sometimes a rewrite is less
>>>> >>> expensive
>>>> >>> and turns out to be better). IOW, it is a good idea if you built
>>>> >>> frameworks
>>>> >>> with modularity in mind and use them only *as needed* (not simply
>>>> >>> for
>>>> >>> the
>>>> >>> sake of using them, like trying to appear cool to the crowd).
>>>> >>>
>>>> >>>
>>>> >>> PointedEars
>>>> >>
>>>> >> If a framework attempts to be "all things to all people", then that's
>>>> >> quite true. But the same is true of *any* code.
>>>> >>
>>>> >> However, a limited framework with limited goals doesn't necessarily
>>>> >> have to be the case.
>>>> >>
>>>> >> For instance, in my case - I have a framework which builds PHP
>>>> >> classes
>>>> >> to interface to a database. It generates a lot of usable code for
>>>> >> those classes, including form handling.
>>>> >
>>>> > So you framework generates "a lot" of code, does it? My framework
>>>> > generates very small amounts of code which call shared functions or
>>>> > which inherit code from abstract classes.
>>>> >
>>>>
>>>> Yup, for instance, it generates all the set and get methods for the
>>>> applicable class, as well as database access code (insert/update/delete
>>>> for single rows and single rows and lists of multiple rows for SELECT).
>>>> (Most of the access code is in parent classes).
>>>
>>> My framework does not bother generating set and get methods as they are
>>> inefficient. Data goes in and comes out as an array.
>>>
>>
>> Yea, that's why your code is crap. You obviously know nothing about
>> proper OO coding techniques. And that means in order to change one
>> item in the object the user has to build an array for the whole thing?
>> Bloat... Bloat... Bloat...
>
> You obviously don't know what "proper OO" actually means. And where did
> I say that in order to change one item in the object the user has to
> build an array for the whole thing? You are reading things which I did
> not write.
>
Oh, I sure do. You said you don't have SET/GET functions. You said you
set the values with an array. It's exactly what you said.
>>> My framework does not generate any database access code as that is
>>> already
>>> provided by my Data Access Object (DAO). I have one for MySQL, one for
>>> PostgreSQL, one for Oracle and another for SQL Server. I can switch
>>> from one
>>> to another simply by changing a single line in a config file.
>>>
>>
>> Yes, you always waste a lot of time retrieving all columns, whether
>> they are needed or not. And you update all columns, whether you need
>> to or not. Bloatware.
>
> You are jumping to the wrong conclusion AGAIN! The default is to read
> all columns simply because by default all columns are displayed on the
> screen. The defaults can be changed.
>
Ah, so you have to write code to change those defaults. Once again not
what you claimed earlier.
>>>> It also generates the code necessary to validate a field. Some stock
>>>> fields (like "must be integer") have predefined validation functions.
>>>
>>> My framework does not generate any code to perform basic field
>>> validation as
>>> that is performed by a validation class which I wrote years ago.
>>>
>>
>> More bloat. And tell me how your class handles a rule such as "8-16
>> characters, must have both upper and lower case and at least one digit".
>
> Easy peasy. I just set these values in the database:
> min_length = 8
> max_length = 16
> upper_case = 1
> lower_case = 1
> num_digits = 1
>
Bloatware. The code has to needlessly query the database, parse the
results then apply them to the password, when a regex would do the job
simply.
Bloat, bloat, bloat.
>> Or how about the bloat of calling a class to verify the input is an
>> integer when a simple one line statement works. More bloat.
>
> I have a validation class which is capable of validating every data
> type. This means that I do not have to write the line of code which
> tests that a piece of input is an integer. Not having to write that line
> is not bloat.
>
Again, bloatware, when a simple function call like intval() will do it.
You've added an additional and unnecessary layer of complexity to the
application.
>>>> Others, like passwords where the rules may change, allow the validation
>>>> to be handled by a regex, function call or similar.
>>>
>>> In my framework any password rues - such as minimum length, the
>>> number of
>>> uppercase characters, the number of lowercase characters, the number of
>>> digits - is controlled from a database record. Each customer can
>>> therefore
>>> change the rules without me having to change any code.
>>>
>>
>> More bloat. And unnecessary.
>
> It is necessary if I want to allow the customer to change the password
> validation rules without having to write any code. Not having to write
> code is not bloat.
>
More bloat. And unnecessary. How often does the customer want to
change the password rules? In about 35 years of programming for
clients, I've never had that happen. And what about the existing
passwords which don't match the new rules?
Why stop with the password? Why not let the customer change the window
layout, for instance? Or add tables and columns to the database?
Your code is just bloatware and adds an unnecessary layer of complexity
to the code.
>>>> It also has the ability to generate forms html to display
>>>> (read/write or
>>>> read only). And this is all one function. If I need a different layout
>>>> for a different page, it's easy to copy/paste a new function and
>>>> redo the
>>>> output.
>>>
>>> Copy/Paste? That produces duplicate code, not sharable code, and even
>>> you
>>> should know that duplicate code violates the DRY principle.
>>>
>>
>> You obviously don't understand the DRY principle. Just because you
>> copy/paste does not mean it's duplicate code. Once the code has been
>> modified to do something else, it is no longer duplicate.
>
> If you were really clever you wouldn't have to copy/paste/modify, you
> would have a reusable module. In my MVC implementation I have a fixed
> set of controllers, and each controller is reusable. Can you say the
> same in your framework?
>
Doesn't make any difference. How do you handle displaying the same
information two entirely different ways on two different windows? Mine
is simple and straightforward. It is also easy to maintain.
>>>> It also has a function to populate the object from $_GET or $_POST
>>>> values
>>>> (with validation).
>>>
>>> I don't need a whole function to do that when a single line will do:-
>>> $result = $object->insertRecord($_POST);
>>>
>>
>> So what is insertRecord($_POST) then, if it's not a function? Once
>> again you show your ignorance. Don't even know what a function is!
>
> What I'm saying is that I don't have a function which splits the $_POST
> array into its component parts so I can then use a setter on each
> component, I simply inject the entire $_POST array in a single operation
> without the need to split it down into its component parts.
>
So you do have a function which does the work. That's not what you said
earlier.
I never said I had to split it down into parts, either. I have a member
function which handles the input. But I guess that's just too much for
you to understand.
>>> This means that the same line will work on any object regardless of
>>> which
>>> class it came from. That is what polymorphism is all about.
>>>
>>
>> Nope, that's not at all what polymorphism is about. But you obviously
>> don't understand polymorphism, either.
>
> The definition of polymorphism which I use is "same method, different
> implementation". What definition do you use?
>
You've got a *partial* definition. Polymorphism is only applicable when
the two classes have a parent/child hierarchy, and the child class has a
method of the same name (and in some languages, the same parameter list)
as the parent.
When there is no parent/child relationship (as in the case of two
different database tables), there is no polymorphism.
>>>> >> However, since each class is pretty much independent, I can easily
>>>> >> change a class without affecting the rest of the program.
>>>> >
>>>> > So can I with my framework.
>>>> >
>>>> >> I don't have it where it will work with multiple tables yet
>>>> >> (something
>>>> >> I will do one of these days), but it takes a huge amount of the
>>>> >> repetitive work off of me.
>>>> >
>>>> > Removing the need for all this repetitive coding, the "plumbing" as I
>>>> > call it, is exactly what my framework does.
>>>> >
>>>>
>>>> Not if it only generates a tiny bit of code.
>>>
>>> You are missing the point as usual. My framework need only generate a
>>> small
>>> amount of code as everything else, especially all the standard
>>> plumbing, is
>>> included from standard pre-written functions.
>>>
>>
>> No, I'm missing nothing. But you've clearly shown just how crappy your
>> code is.
>
> Just because it's different from yours does not make it crap.
>
It's not because it's different that it's crap. It's crap because
you've shown here it's crap.
>>>> >> And no, I don't try to use it for every project. But where a project
>>>> >> is database-intensive, it suits my purposes.
>>>> >
>>>> > All my applications are database-intensive, which is why I use a
>>>> > framework which is centred around the database.
>>>> >
>>>>
>>>> Ah, that explains it, then. Database access is easy (although many
>>>> people
>>>> can still screw that up). Most of my applications need to do real work.
>>>
>>> My framework takes care of all the standard database access, and getting
>>> data in and out of the screen, plus basic data validation. As for the
>>> "real
>>> work" as you call - or the "payload" as I call it - that is done by
>>> adding
>>> whatever code is necessary in the relevant class to implement each
>>> business
>>> rule. The point is that when using my framework the programmer has to
>>> spend
>>> little or no time on the standard plumbing, which leaves him with
>>> much more
>>> time to spend on the payload.
>>>
>>
>> Yup, you've never done any applications which require real work, as
>> you once again have shown.
>
> Then you obviously have not experienced the complicated things which
> need to be done in an ERP application.
>
Obviously neither have you. What you have is not a real ERP
application. I suspect your customer would do as well with an Excel
spreadsheet.
And I wonder what your customer would think if he knew you were taking
credit for his hard work in building his business.
>>>> But I'm also not so stupid as to think that my frameworks is good for
>>>> everyone. It works for me. But I don't try to foist it off on someone
>>>> else without telling them it's my framework. That is just plain
>>>> dishonest.
>>>
>>> I never said that my framework is the perfect solution for everyone.
>>> If you
>>> a writing a simple website then it's not good, but if you are writing a
>>> database application then it's better than most.
>>>
>>
>> Hmmm, you sure seemed to indicate that when you first started pushing
>> this piece of horse hockey.
>
> That may have been the impression that you got, but you have indicated
> time and time again that your mind works in mysterious ways.
>
Yea, I live in the real world and have real world experience. Unlike
you, who seems to live in some alternative universe where you can make
up any rules you want and can ignore those you don't like. You can call
a simple database application an ERP and take all the credit for your
client's hard work.
>>> I was never dishonest about the Radicore framework. I never said it was
>>> written by someone else. I even include a link to the radicore
>>> website in my
>>> signature.
>>>
>>
>> And you never said it was written by you, and that you were nowhere
>> near an unbiased user. The fact you are pushing your own product
>> without telling people you have a vested interest is dishonest. The
>> fact you have a link to it in your sig is immaterial - lots of people
>> have links in their sigs to all kinds of things.
>>
>> But then I can see why you don't want to tell people it's your
>> product. I wouldn't want to admit to having created that piece of
>> horse hockey, either.
>
> You're the expert in horse hockey judging by the amount you write in
> these posts.
>
Nope, I know how to program properly. You've obviously never worked in
a corporate environment, for instance, where you have multiple
programmers and have to learn good programming techniques.
>>> If *your* framework is so good, then why don't you release it as open
>>> source
>>> so that we call all have a laugh?
>>>
>>
>> For a lot of reasons. Mainly because I'm not interested in the hassles
>> of having to support it for a bunch of people who want all kinds of
>> other features. I created it for my projects, and it serves those
>> projects well.
>
> What you really mean is that you are too ashamed to have it reviewed by
> your peers, and that you are incapable of writing code which can be used
> by others.
>
Not at all. I meant exactly what I said. Unlike you, I don't need my
ego stroked.
But my code is reviewed by others quite often. Most projects I work on
are collaborative. But then I work with programmers who know what
they're doing, also.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Dynamic form generation [message #177761 is a reply to message #177755] |
Fri, 20 April 2012 12:09 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/20/2012 5:10 AM, Tony Marston wrote:
> "Jerry Stuckle" wrote in message news:jmp154$4tt$1(at)dont-email(dot)me...
>>
>> On 4/19/2012 4:27 AM, Tony Marston wrote:
>>> "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message
>>> news:jmmauq$9ke$1(at)dont-email(dot)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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Dynamic form generation [message #177790 is a reply to message #177761] |
Sat, 21 April 2012 09:35 |
Tony Marston
Messages: 57
Registered: November 2010
Karma: 0
|
Member |
|
|
"Jerry Stuckle" wrote in message news:jmrjmk$ubd$1(at)dont-email(dot)me...
>
> On 4/20/2012 5:10 AM, Tony Marston wrote:
>> "Jerry Stuckle" wrote in message news:jmp154$4tt$1(at)dont-email(dot)me...
>>>
>>> On 4/19/2012 4:27 AM, Tony Marston wrote:
>>>> "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message
>>>> news:jmmauq$9ke$1(at)dont-email(dot)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
|
|
|
|
| Re: Dynamic form generation [message #177791 is a reply to message #177790] |
Sat, 21 April 2012 10:21 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/21/2012 5:35 AM, Tony Marston wrote:
> "Jerry Stuckle" wrote in message news:jmrjmk$ubd$1(at)dont-email(dot)me...
>>
>> On 4/20/2012 5:10 AM, Tony Marston wrote:
>>> "Jerry Stuckle" wrote in message news:jmp154$4tt$1(at)dont-email(dot)me...
>>>>
>>>> On 4/19/2012 4:27 AM, Tony Marston wrote:
>>>> > "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message
>>>> > news:jmmauq$9ke$1(at)dont-email(dot)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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Dynamic form generation [message #177792 is a reply to message #177760] |
Sat, 21 April 2012 11:22 |
Tony Marston
Messages: 57
Registered: November 2010
Karma: 0
|
Member |
|
|
"Jerry Stuckle" wrote in message news:jmrice$n8h$1(at)dont-email(dot)me...
>
> On 4/20/2012 4:27 AM, Tony Marston wrote:
>> "Jerry Stuckle" wrote in message news:jmp0gb$d8$1(at)dont-email(dot)me...
>>>
>>> On 4/19/2012 4:56 AM, Tony Marston wrote:
>>>> "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message
>>>> news:jmmabk$67a$1(at)dont-email(dot)me...
>>>> > On 4/18/2012 4:33 AM, Tony Marston wrote:
>>>> >> "Jerry Stuckle" wrote in message news:jmk2lu$hgn$1(at)dont-email(dot)me...
>>>> >>>
>>>> >>> On 4/17/2012 8:49 AM, Thomas 'PointedEars' Lahn wrote:
>>>> >>>> Denis McMahon wrote:
>>>> >>>>
>>>> >>>>> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote:
>>>> >>>>>> If you used a proper framework ...
>>>> >>>>>
>>>> >>>>> ... then you'd have all the junk and baggage that comes along with
>>>> >>>>> that
>>>> >>>>> framework, including any security flaws in the framework.
>>>> >>>>>
>>>> >>>>> Not saying that frameworks are inherently bad, but they're not
>>>> >>>>> automatically the solution either.
>>>> >>>>
>>>> >>>> TINSTAAFL. If you want complete flexibility of the application as
>>>> >>>> the
>>>> >>>> OP
>>>> >>>> wants, you have to have an abstraction layer in your application,
>>>> >>>> i.e. it
>>>> >>>> has to be built on a framework (some people really should reflect
>>>> >>>> on
>>>> >>>> the
>>>> >>>> term "framework" and its etymology). Abstraction layers come at a
>>>> >>>> price:
>>>> >>>> Increased overall complexity of the application and decreased
>>>> >>>> efficiency for
>>>> >>>> tasks that do not require as much flexibility.
>>>> >>>>
>>>> >>>
>>>> >>> Yup, and when you use a framework you force the application to match
>>>> >>> the framework, instead of allowing the application to meet the
>>>> >>> client's needs.
>>>> >>>
>>>> >>> It may work - but then it may not, also.
>>>> >>
>>>> >> The client's needs are met by screens/reports which have the right
>>>> >> layout and which perform the right functions. My framework does not
>>>> >> stand in the way of that at all. When user transactions are initially
>>>> >> generated they have default screens and default behaviour, but
>>>> >> these can
>>>> >> be customised to whatever level of sophistication you want.
>>>> >>
>>>> >
>>>> > The client's needs are met by the APPLICATION. This is much more
>>>> > than the
>>>> > screens and the layouts. But then if all you do are trivial database
>>>> > applications, then I can see where something like that can help.
>>>>
>>>> An application is nothing more than a collection of individual
>>>> components,
>>>> where each component does a "unit of work" from the user's point of
>>>> view. A
>>>> small application has a small number of components, while a large
>>>> application has a large number of components.
>>>>
>>>
>>> I can understand how someone like you who does such simple stuff
>>> things that way. But then you've never worked on something even
>>> moderately complex.
>>
>> Building an entire ERP system with 1700 transactions is much more than
>> "simple". I work on business applications for corporations, not toy
>> systems for hobbyists.
>>
>
> Building a *decent* ERP is complex. SAP, for instance, has a good one.
> They have several hundred programmers working on it constantly.
That is because they have made it more complex than it need be, and they are
obviously not using a framework which does all the grunt work for them.
> What you call an "ERP" is nothing like that.
My definition of ERP is the same as that found in wikipedia at
http://en.wikipedia.org/wiki/Enterprise_resource_planning.
Note that an ERP system need not contain all of those modules, just two or
more would be sufficient.
>>> A large application is much more complex than just having "a large
>>> number of components".
>>
>> I disagree. An application which uses 200 database tables is more
>> complex than one which uses only 2, and the more tables you have the
>> more maintenance screens you require.
>>
>
> That's because you've never worked on a complex application. Your claim of
> an ERP is proof of that.
You obviously don't know what features are available in my ERP system.
> All you do is database stuff. There's nothing complex about that.
Correct. There is nothing complex about writing code which moves data
between the user interface and the database. That is why I developed the
Radicore framework, to take care of all that simple "plumbing" stuff for me.
My valuable time is spent on writing the code which deals with the business
rules, the "payload" as I call it, some of which are more complex than
others
>>>> > However, your example of over 200 tables and 350 relationships is a
>>>> > perfect example of how bloated such code can become.
>>>>
>>>> The term "bloat" implies having things which are not used, and I can
>>>> assure
>>>> you that every database table has a purpose and is used in one or more
>>>> transactions. If a database table ever became redundant then I would
>>>> remove
>>>> it.
>>>>
>>>
>>> Not at all. "Bloat" also refers to applications which are overly large
>>> for what needs to be done.
>>
>> My applications are not overly large. While I have a large number of
>> small transactions each of which does one thing, this is not "bloat", it
>> is following the Single Responsibility Principle.
>>
>>
>
> Nope, they aren't, because your applications are just for database access.
They are not "just" for basic database access, they are for applying complex
business rules as well. The "basic" functionality is provided by the
framework while the business rules are provided by the programmer.
> But they sure sound like they're bloated.
The term "bloat" has nothing to do with the number of database tables.
Provided that the database has been properly normalised (you *DO* know what
the term "properly normalised" means, don't you?) and every table is used
somewhere then there is no "bloat" whatsoever.
In my book the term "bloat" is covered by unnecessary code, and I would say
that any application which you write which contains 3M LOC has much more
bloat than anything which I write.
>>> My databases are based on the designs in Len Silverston's Data Model
>>>> Resource book. So far I have implemented the PARTY, PRODUCT, ORDER,
>>>> INVENTORY, SHIPMENT, INVOICE, REQUEST and WORK-EFFORT databases. If you
>>>> bother to read his book you wil see that every table serves a purpose.
>>>>
>>>
>>> Yes, that works fine for simple applications. But then you've already
>>> said that's all you do. You've never worked on anything even
>>> moderately complex.
>>
>> I would like to see *YOU* design and build an ERP application basedon
>> those databases and then tell me it's simple!
>>
>
> I'd like to see YOU create a REAL ERP application! All you did was build
> database access to multiple tables. ERP is much more than that.
I know that. It also includes the application of business rules when
something changes state. An example would be: "when a sales order is
authorised it must be converted into an invoice, a PDF version of that
invoice must be created and emailed to the customer. The invoice must also
be in the language and currency of the customer."
<snip>
>>>> >> So you framework generates "a lot" of code, does it? My framework
>>>> >> generates very small amounts of code which call shared functions or
>>>> >> which inherit code from abstract classes.
>>>> >>
>>>> >
>>>> > Yup, for instance, it generates all the set and get methods for the
>>>> > applicable class, as well as database access code
>>>> > (insert/update/delete
>>>> > for single rows and single rows and lists of multiple rows for
>>>> > SELECT).
>>>> > (Most of the access code is in parent classes).
>>>>
>>>> My framework does not bother generating set and get methods as they are
>>>> inefficient. Data goes in and comes out as an array.
>>>>
>>>
>>> Yea, that's why your code is crap. You obviously know nothing about
>>> proper OO coding techniques. And that means in order to change one
>>> item in the object the user has to build an array for the whole thing?
>>> Bloat... Bloat... Bloat...
>>
>> You obviously don't know what "proper OO" actually means. And where did
>> I say that in order to change one item in the object the user has to
>> build an array for the whole thing? You are reading things which I did
>> not write.
>>
>
> Oh, I sure do. You said you don't have SET/GET functions. You said you
> set the values with an array. It's exactly what you said.
But I don't have to insert any code to create that array as it is already
provided for me in the form of $_GET or $_POST.
When data comes in from the database it appears as a single variable which
is an array of rows and columns.
>>>> My framework does not generate any database access code as that is
>>>> already
>>>> provided by my Data Access Object (DAO). I have one for MySQL, one for
>>>> PostgreSQL, one for Oracle and another for SQL Server. I can switch
>>>> from one
>>>> to another simply by changing a single line in a config file.
>>>>
>>>
>>> Yes, you always waste a lot of time retrieving all columns, whether
>>> they are needed or not. And you update all columns, whether you need
>>> to or not. Bloatware.
>>
>> You are jumping to the wrong conclusion AGAIN! The default is to read
>> all columns simply because by default all columns are displayed on the
>> screen. The defaults can be changed.
>>
>
> Ah, so you have to write code to change those defaults. Once again not
> what you claimed earlier.
Any person with more than two brain cells to rub together knows that if the
default behaviour is not what you want then you have to write code to change
those defaults. I have never claimed otherwise. My framework generates
working transactions based on a lot of default behaviour, and in a lot of
cases the default behaviour is good enough. When it isn't you can change it.
>>>> > It also generates the code necessary to validate a field. Some stock
>>>> > fields (like "must be integer") have predefined validation functions.
>>>>
>>>> My framework does not generate any code to perform basic field
>>>> validation as
>>>> that is performed by a validation class which I wrote years ago.
>>>>
>>>
>>> More bloat. And tell me how your class handles a rule such as "8-16
>>> characters, must have both upper and lower case and at least one digit".
>>
>> Easy peasy. I just set these values in the database:
>> min_length = 8
>> max_length = 16
>> upper_case = 1
>> lower_case = 1
>> num_digits = 1
>>
>
> Bloatware. The code has to needlessly query the database, parse the
> results then apply them to the password, when a regex would do the job
> simply.
But where do you store the regex? In thin air? Different customers have
different rules, so each customer can specify the rules that they want on
their copy of the database. That is not bloat, it is sensible design.
> Bloat, bloat, bloat.
>
>
>>> Or how about the bloat of calling a class to verify the input is an
>>> integer when a simple one line statement works. More bloat.
>>
>> I have a validation class which is capable of validating every data
>> type. This means that I do not have to write the line of code which
>> tests that a piece of input is an integer. Not having to write that line
>> is not bloat.
>>
>
> Again, bloatware, when a simple function call like intval() will do it.
> You've added an additional and unnecessary layer of complexity to the
> application.
You are missing the point AGAIN. In your applications you have to write code
to call the intval() function. In my applications I don't have to write any
validation code because I wrote a general purpose validation class many
years ago, and it deals with that level of validation automatically.
Again you are writing code to do something which my framework does
automatically. And you have the nerve to say that my methods are crap!
>>>> > Others, like passwords where the rules may change, allow the
>>>> > validation
>>>> > to be handled by a regex, function call or similar.
>>>>
>>>> In my framework any password rues - such as minimum length, the
>>>> number of
>>>> uppercase characters, the number of lowercase characters, the number of
>>>> digits - is controlled from a database record. Each customer can
>>>> therefore
>>>> change the rules without me having to change any code.
>>>>
>>>
>>> More bloat. And unnecessary.
>>
>> It is necessary if I want to allow the customer to change the password
>> validation rules without having to write any code. Not having to write
>> code is not bloat.
>>
>
> More bloat. And unnecessary. How often does the customer want to change
> the password rules? In about 35 years of programming for clients, I've
> never had that happen. And what about the existing passwords which don't
> match the new rules?
A customer may or may not want to change the rules after the software has
been installed, but as my software is used by many different customers each
one may want a different set of rules when it is first installed. I can
apply whatever rules a customer wants simply by changing his copy of the
database, and NOT by changing any code.
> Why stop with the password? Why not let the customer change the window
> layout, for instance? Or add tables and columns to the database?
Now you're going off at a tangent. I should quit while you're behind.
> Your code is just bloatware and adds an unnecessary layer of complexity to
> the code.
>
>>>> > It also has the ability to generate forms html to display
>>>> > (read/write or
>>>> > read only). And this is all one function. If I need a different layout
>>>> > for a different page, it's easy to copy/paste a new function and
>>>> > redo the
>>>> > output.
>>>>
>>>> Copy/Paste? That produces duplicate code, not sharable code, and even
>>>> you
>>>> should know that duplicate code violates the DRY principle.
>>>>
>>>
>>> You obviously don't understand the DRY principle. Just because you
>>> copy/paste does not mean it's duplicate code. Once the code has been
>>> modified to do something else, it is no longer duplicate.
>>
>> If you were really clever you wouldn't have to copy/paste/modify, you
>> would have a reusable module. In my MVC implementation I have a fixed
>> set of controllers, and each controller is reusable. Can you say the
>> same in your framework?
>>
>
> Doesn't make any difference. How do you handle displaying the same
> information two entirely different ways on two different windows? Mine is
> simple and straightforward. It is also easy to maintain.
So is mine.
>>>> > It also has a function to populate the object from $_GET or $_POST
>>>> > values
>>>> > (with validation).
>>>>
>>>> I don't need a whole function to do that when a single line will do:-
>>>> $result = $object->insertRecord($_POST);
>>>>
>>>
>>> So what is insertRecord($_POST) then, if it's not a function? Once
>>> again you show your ignorance. Don't even know what a function is!
>>
>> What I'm saying is that I don't have a function which splits the $_POST
>> array into its component parts so I can then use a setter on each
>> component, I simply inject the entire $_POST array in a single operation
>> without the need to split it down into its component parts.
>>
>
> So you do have a function which does the work. That's not what you said
> earlier.
Read what I wrote. I do *NOT* have any function which splits the input
array, be it the $_GET array, the $_POST array, or whatever, into its
component parts. All database data exists in the database table object as an
array of rows and columns.
> I never said I had to split it down into parts, either. I have a member
> function which handles the input. But I guess that's just too much for you
> to understand.
I beg to differ. You specifically wrote that you have getters and setters
for each individual column/field. I do not have code which splits an array
into its component parts as I can access any component part while it is
still sitting in the array.
>>>> This means that the same line will work on any object regardless of
>>>> which
>>>> class it came from. That is what polymorphism is all about.
>>>>
>>>
>>> Nope, that's not at all what polymorphism is about. But you obviously
>>> don't understand polymorphism, either.
>>
>> The definition of polymorphism which I use is "same method, different
>> implementation". What definition do you use?
>>
>
> You've got a *partial* definition. Polymorphism is only applicable when
> the two classes have a parent/child hierarchy, and the child class has a
> method of the same name (and in some languages, the same parameter list) as
> the parent.
The definition of polymorphism does NOT state that the classes have to exist
in a parent/child hierarchy, only that they have the same method signature.
Having said that, it is usually the case that the two classes ARE related.
> When there is no parent/child relationship (as in the case of two different
> database tables), there is no polymorphism.
Then you obviously haven't used an abstract table class which is inherited
by every concrete table class. All my concrete table classes have instant
access to all the methods and properties which are defined just once in the
abstract class.
>>>> >>> However, since each class is pretty much independent, I can easily
>>>> >>> change a class without affecting the rest of the program.
>>>> >>
>>>> >> So can I with my framework.
>>>> >>
>>>> >>> I don't have it where it will work with multiple tables yet
>>>> >>> (something
>>>> >>> I will do one of these days), but it takes a huge amount of the
>>>> >>> repetitive work off of me.
>>>> >>
>>>> >> Removing the need for all this repetitive coding, the "plumbing" as I
>>>> >> call it, is exactly what my framework does.
>>>> >>
>>>> >
>>>> > Not if it only generates a tiny bit of code.
>>>>
>>>> You are missing the point as usual. My framework need only generate a
>>>> small
>>>> amount of code as everything else, especially all the standard
>>>> plumbing, is
>>>> included from standard pre-written functions.
>>>>
>>>
>>> No, I'm missing nothing. But you've clearly shown just how crappy your
>>> code is.
>>
>> Just because it's different from yours does not make it crap.
>>
>
> It's not because it's different that it's crap. It's crap because you've
> shown here it's crap.
Only in your tiny mind.
>>>> >>> And no, I don't try to use it for every project. But where a project
>>>> >>> is database-intensive, it suits my purposes.
>>>> >>
>>>> >> All my applications are database-intensive, which is why I use a
>>>> >> framework which is centred around the database.
>>>> >>
>>>> >
>>>> > Ah, that explains it, then. Database access is easy (although many
>>>> > people
>>>> > can still screw that up). Most of my applications need to do real
>>>> > work.
>>>>
>>>> My framework takes care of all the standard database access, and
>>>> getting
>>>> data in and out of the screen, plus basic data validation. As for the
>>>> "real
>>>> work" as you call - or the "payload" as I call it - that is done by
>>>> adding
>>>> whatever code is necessary in the relevant class to implement each
>>>> business
>>>> rule. The point is that when using my framework the programmer has to
>>>> spend
>>>> little or no time on the standard plumbing, which leaves him with
>>>> much more
>>>> time to spend on the payload.
>>>>
>>>
>>> Yup, you've never done any applications which require real work, as
>>> you once again have shown.
>>
>> Then you obviously have not experienced the complicated things which
>> need to be done in an ERP application.
>>
>
> Obviously neither have you. What you have is not a real ERP application. I
> suspect your customer would do as well with an Excel spreadsheet.
It is real enough for my paying customers, and it is THEIR opinion that
counts, not yours.
> And I wonder what your customer would think if he knew you were taking
> credit for his hard work in building his business.
The comment that my software helped that particular customer in that way was
actually made by one of the directors of that company.
>>>> > But I'm also not so stupid as to think that my frameworks is good for
>>>> > everyone. It works for me. But I don't try to foist it off on someone
>>>> > else without telling them it's my framework. That is just plain
>>>> > dishonest.
>>>>
>>>> I never said that my framework is the perfect solution for everyone.
>>>> If you
>>>> a writing a simple website then it's not good, but if you are writing a
>>>> database application then it's better than most.
>>>>
>>>
>>> Hmmm, you sure seemed to indicate that when you first started pushing
>>> this piece of horse hockey.
>>
>> That may have been the impression that you got, but you have indicated
>> time and time again that your mind works in mysterious ways.
>>
>
> Yea, I live in the real world and have real world experience. Unlike you,
> who seems to live in some alternative universe where you can make up any
> rules you want and can ignore those you don't like. You can call a simple
> database application an ERP and take all the credit for your client's hard
> work.
It is much more than a simple database application which does nothing more
than move data between the user interface and the database. It processes a
large number of business rules, and it is the number and complexity of these
business rules which decides whether an application is actually complex or
not.
>>>> I was never dishonest about the Radicore framework. I never said it was
>>>> written by someone else. I even include a link to the radicore
>>>> website in my
>>>> signature.
>>>>
>>>
>>> And you never said it was written by you, and that you were nowhere
>>> near an unbiased user. The fact you are pushing your own product
>>> without telling people you have a vested interest is dishonest. The
>>> fact you have a link to it in your sig is immaterial - lots of people
>>> have links in their sigs to all kinds of things.
>>>
>>> But then I can see why you don't want to tell people it's your
>>> product. I wouldn't want to admit to having created that piece of
>>> horse hockey, either.
>>
>> You're the expert in horse hockey judging by the amount you write in
>> these posts.
>>
>
> Nope, I know how to program properly. You've obviously never worked in a
> corporate environment, for instance, where you have multiple programmers
> and have to learn good programming techniques.
I worked in several software houses for many years, and I dealt with many
different projects for many different customers. I was also project leader
on a good number of those projects. I also wrote the framework used in one
of those software houses as well as setting the development standards.
>>>> If *your* framework is so good, then why don't you release it as open
>>>> source
>>>> so that we call all have a laugh?
>>>>
>>>
>>> For a lot of reasons. Mainly because I'm not interested in the hassles
>>> of having to support it for a bunch of people who want all kinds of
>>> other features. I created it for my projects, and it serves those
>>> projects well.
>>
>> What you really mean is that you are too ashamed to have it reviewed by
>> your peers, and that you are incapable of writing code which can be used
>> by others.
>>
>
> Not at all. I meant exactly what I said.
Yes, you can't be bothered to release it as it is only useful for your own
personal toy projects.
> Unlike you, I don't need my ego stroked.
That's not the impression I get from reading your comments in this post. You
seem to think that YOUR way is the ONLY way, and anybody who dares to
disagree with you is a stupid moron. I disagree with everything you say, and
as for being a moron, 99% of the emails which I receive on the subject on my
work are nothing but complimentary.
> But my code is reviewed by others quite often. Most projects I work on are
> collaborative. But then I work with programmers who know what they're
> doing, also.
I'd hate to on a team of programmers who all think like you as they would
all be unproductive and full of silly ideas.
--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
|
|
|
|
| Re: Dynamic form generation [message #177798 is a reply to message #177792] |
Sat, 21 April 2012 14:19 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/21/2012 7:22 AM, Tony Marston wrote:
> "Jerry Stuckle" wrote in message news:jmrice$n8h$1(at)dont-email(dot)me...
>>
>> On 4/20/2012 4:27 AM, Tony Marston wrote:
>>> "Jerry Stuckle" wrote in message news:jmp0gb$d8$1(at)dont-email(dot)me...
>>>>
>>>> On 4/19/2012 4:56 AM, Tony Marston wrote:
>>>> > "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message
>>>> > news:jmmabk$67a$1(at)dont-email(dot)me...
>>>> >> On 4/18/2012 4:33 AM, Tony Marston wrote:
>>>> >>> "Jerry Stuckle" wrote in message news:jmk2lu$hgn$1(at)dont-email(dot)me...
>>>> >>>>
>>>> >>>> On 4/17/2012 8:49 AM, Thomas 'PointedEars' Lahn wrote:
>>>> >>>>> Denis McMahon wrote:
>>>> >>>>>
>>>> >>>>>> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote:
>>>> >>>>>>> If you used a proper framework ...
>>>> >>>>>>
>>>> >>>>>> ... then you'd have all the junk and baggage that comes along
>>>> >>>>>> with
>>>> >>>>>> that
>>>> >>>>>> framework, including any security flaws in the framework.
>>>> >>>>>>
>>>> >>>>>> Not saying that frameworks are inherently bad, but they're not
>>>> >>>>>> automatically the solution either.
>>>> >>>>>
>>>> >>>>> TINSTAAFL. If you want complete flexibility of the application as
>>>> >>>>> the
>>>> >>>>> OP
>>>> >>>>> wants, you have to have an abstraction layer in your application,
>>>> >>>>> i.e. it
>>>> >>>>> has to be built on a framework (some people really should
>>>> >>>>> reflect on
>>>> >>>>> the
>>>> >>>>> term "framework" and its etymology). Abstraction layers come at a
>>>> >>>>> price:
>>>> >>>>> Increased overall complexity of the application and decreased
>>>> >>>>> efficiency for
>>>> >>>>> tasks that do not require as much flexibility.
>>>> >>>>>
>>>> >>>>
>>>> >>>> Yup, and when you use a framework you force the application to
>>>> >>>> match
>>>> >>>> the framework, instead of allowing the application to meet the
>>>> >>>> client's needs.
>>>> >>>>
>>>> >>>> It may work - but then it may not, also.
>>>> >>>
>>>> >>> The client's needs are met by screens/reports which have the right
>>>> >>> layout and which perform the right functions. My framework does not
>>>> >>> stand in the way of that at all. When user transactions are
>>>> >>> initially
>>>> >>> generated they have default screens and default behaviour, but
>>>> >>> these can
>>>> >>> be customised to whatever level of sophistication you want.
>>>> >>>
>>>> >>
>>>> >> The client's needs are met by the APPLICATION. This is much more
>>>> >> than the
>>>> >> screens and the layouts. But then if all you do are trivial database
>>>> >> applications, then I can see where something like that can help.
>>>> >
>>>> > An application is nothing more than a collection of individual
>>>> > components,
>>>> > where each component does a "unit of work" from the user's point of
>>>> > view. A
>>>> > small application has a small number of components, while a large
>>>> > application has a large number of components.
>>>> >
>>>>
>>>> I can understand how someone like you who does such simple stuff
>>>> things that way. But then you've never worked on something even
>>>> moderately complex.
>>>
>>> Building an entire ERP system with 1700 transactions is much more than
>>> "simple". I work on business applications for corporations, not toy
>>> systems for hobbyists.
>>>
>>
>> Building a *decent* ERP is complex. SAP, for instance, has a good one.
>> They have several hundred programmers working on it constantly.
>
> That is because they have made it more complex than it need be, and they
> are obviously not using a framework which does all the grunt work for them.
>
No, that's because they build an ERP, not an order entry/tracking system
and call it an ERP.
>> What you call an "ERP" is nothing like that.
>
> My definition of ERP is the same as that found in wikipedia at
> http://en.wikipedia.org/wiki/Enterprise_resource_planning.
>
No, you're is nothing like that.
> Note that an ERP system need not contain all of those modules, just two
> or more would be sufficient.
>
Yours doesn't even contain that.
"Mr. Editor, here's my novel for publication. It's only 3 pages long
because my readers have a short attention span. But I'm calling it a
novel anyway".
Calling an order entry/tracking system an ERP doesn't make it an ERP.
>>>> A large application is much more complex than just having "a large
>>>> number of components".
>>>
>>> I disagree. An application which uses 200 database tables is more
>>> complex than one which uses only 2, and the more tables you have the
>>> more maintenance screens you require.
>>>
>>
>> That's because you've never worked on a complex application. Your
>> claim of an ERP is proof of that.
>
> You obviously don't know what features are available in my ERP system.
>
You've told me - it's an order entry/tracking system.
>> All you do is database stuff. There's nothing complex about that.
>
> Correct. There is nothing complex about writing code which moves data
> between the user interface and the database. That is why I developed the
> Radicore framework, to take care of all that simple "plumbing" stuff for
> me. My valuable time is spent on writing the code which deals with the
> business rules, the "payload" as I call it, some of which are more
> complex than others
>
And nothing you've done in your entire life is even moderately complex.
You wouldn't know where to begin.
>>>> >> However, your example of over 200 tables and 350 relationships is a
>>>> >> perfect example of how bloated such code can become.
>>>> >
>>>> > The term "bloat" implies having things which are not used, and I can
>>>> > assure
>>>> > you that every database table has a purpose and is used in one or more
>>>> > transactions. If a database table ever became redundant then I would
>>>> > remove
>>>> > it.
>>>> >
>>>>
>>>> Not at all. "Bloat" also refers to applications which are overly large
>>>> for what needs to be done.
>>>
>>> My applications are not overly large. While I have a large number of
>>> small transactions each of which does one thing, this is not "bloat", it
>>> is following the Single Responsibility Principle.
>>>
>>>
>>
>> Nope, they aren't, because your applications are just for database
>> access.
>
> They are not "just" for basic database access, they are for applying
> complex business rules as well. The "basic" functionality is provided by
> the framework while the business rules are provided by the programmer.
>
To you a "complex business rule" is "the customer ordered something so
we need to ship it".
You've have no idea what a complex system is. All you do is database
access.
>> But they sure sound like they're bloated.
>
> The term "bloat" has nothing to do with the number of database tables.
> Provided that the database has been properly normalised (you *DO* know
> what the term "properly normalised" means, don't you?) and every table
> is used somewhere then there is no "bloat" whatsoever.
>
It does when you've got way more than you need. And not if it's
*properly* normalized. However, I highly doubt your 200+ tables are
"properly normalized".
Bloat also covers unnecessary crap like your "password validation".
> In my book the term "bloat" is covered by unnecessary code, and I would
> say that any application which you write which contains 3M LOC has much
> more bloat than anything which I write.
>
Like your password validation routine.
And let's see you write an OS in less than 3M LOC. But then you've
never done anything more than database access anyway, so you have no idea.
>>>> My databases are based on the designs in Len Silverston's Data Model
>>>> > Resource book. So far I have implemented the PARTY, PRODUCT, ORDER,
>>>> > INVENTORY, SHIPMENT, INVOICE, REQUEST and WORK-EFFORT databases. If
>>>> > you
>>>> > bother to read his book you wil see that every table serves a purpose.
>>>> >
>>>>
>>>> Yes, that works fine for simple applications. But then you've already
>>>> said that's all you do. You've never worked on anything even
>>>> moderately complex.
>>>
>>> I would like to see *YOU* design and build an ERP application basedon
>>> those databases and then tell me it's simple!
>>>
>>
>> I'd like to see YOU create a REAL ERP application! All you did was
>> build database access to multiple tables. ERP is much more than that.
>
> I know that. It also includes the application of business rules when
> something changes state. An example would be: "when a sales order is
> authorised it must be converted into an invoice, a PDF version of that
> invoice must be created and emailed to the customer. The invoice must
> also be in the language and currency of the customer."
>
What you're describing is an order entry/tracking system, not an ERP.
and multi-language is not at all a big thing to a competent programmer.
I can see why you're making something big out of it, though.
> <snip>
>>>> >>> So you framework generates "a lot" of code, does it? My framework
>>>> >>> generates very small amounts of code which call shared functions or
>>>> >>> which inherit code from abstract classes.
>>>> >>>
>>>> >>
>>>> >> Yup, for instance, it generates all the set and get methods for the
>>>> >> applicable class, as well as database access code
>>>> >> (insert/update/delete
>>>> >> for single rows and single rows and lists of multiple rows for
>>>> >> SELECT).
>>>> >> (Most of the access code is in parent classes).
>>>> >
>>>> > My framework does not bother generating set and get methods as they
>>>> > are
>>>> > inefficient. Data goes in and comes out as an array.
>>>> >
>>>>
>>>> Yea, that's why your code is crap. You obviously know nothing about
>>>> proper OO coding techniques. And that means in order to change one
>>>> item in the object the user has to build an array for the whole thing?
>>>> Bloat... Bloat... Bloat...
>>>
>>> You obviously don't know what "proper OO" actually means. And where did
>>> I say that in order to change one item in the object the user has to
>>> build an array for the whole thing? You are reading things which I did
>>> not write.
>>>
>>
>> Oh, I sure do. You said you don't have SET/GET functions. You said you
>> set the values with an array. It's exactly what you said.
>
> But I don't have to insert any code to create that array as it is
> already provided for me in the form of $_GET or $_POST.
>
> When data comes in from the database it appears as a single variable
> which is an array of rows and columns.
>
And you completely miss the question. How do you change a single
property in the object without building the array?
From the number of times you have ducked the question, my only
assumption can be the program can't change a single property in the object.
>>>> > My framework does not generate any database access code as that is
>>>> > already
>>>> > provided by my Data Access Object (DAO). I have one for MySQL, one for
>>>> > PostgreSQL, one for Oracle and another for SQL Server. I can switch
>>>> > from one
>>>> > to another simply by changing a single line in a config file.
>>>> >
>>>>
>>>> Yes, you always waste a lot of time retrieving all columns, whether
>>>> they are needed or not. And you update all columns, whether you need
>>>> to or not. Bloatware.
>>>
>>> You are jumping to the wrong conclusion AGAIN! The default is to read
>>> all columns simply because by default all columns are displayed on the
>>> screen. The defaults can be changed.
>>>
>>
>> Ah, so you have to write code to change those defaults. Once again not
>> what you claimed earlier.
>
> Any person with more than two brain cells to rub together knows that if
> the default behaviour is not what you want then you have to write code
> to change those defaults. I have never claimed otherwise. My framework
> generates working transactions based on a lot of default behaviour, and
> in a lot of cases the default behaviour is good enough. When it isn't
> you can change it.
>
That's not what you claimed earlier. Read back at what you said. But
then you're good at back-pedaling. And you're doing it again.
>>>> >> It also generates the code necessary to validate a field. Some stock
>>>> >> fields (like "must be integer") have predefined validation functions.
>>>> >
>>>> > My framework does not generate any code to perform basic field
>>>> > validation as
>>>> > that is performed by a validation class which I wrote years ago.
>>>> >
>>>>
>>>> More bloat. And tell me how your class handles a rule such as "8-16
>>>> characters, must have both upper and lower case and at least one
>>>> digit".
>>>
>>> Easy peasy. I just set these values in the database:
>>> min_length = 8
>>> max_length = 16
>>> upper_case = 1
>>> lower_case = 1
>>> num_digits = 1
>>>
>>
>> Bloatware. The code has to needlessly query the database, parse the
>> results then apply them to the password, when a regex would do the job
>> simply.
>
> But where do you store the regex? In thin air? Different customers have
> different rules, so each customer can specify the rules that they want
> on their copy of the database. That is not bloat, it is sensible design.
>
Nope, it's in the code. Another customer wants another rule? Change
the regex. And if you want to be anal about it (you're good at that,
also), put it in a function in a separate file.
Your way is plain bloat.
>> Bloat, bloat, bloat.
>>
>>
>>>> Or how about the bloat of calling a class to verify the input is an
>>>> integer when a simple one line statement works. More bloat.
>>>
>>> I have a validation class which is capable of validating every data
>>> type. This means that I do not have to write the line of code which
>>> tests that a piece of input is an integer. Not having to write that line
>>> is not bloat.
>>>
>>
>> Again, bloatware, when a simple function call like intval() will do
>> it. You've added an additional and unnecessary layer of complexity to
>> the application.
>
> You are missing the point AGAIN. In your applications you have to write
> code to call the intval() function. In my applications I don't have to
> write any validation code because I wrote a general purpose validation
> class many years ago, and it deals with that level of validation
> automatically.
>
More bloat. No, the intval() function call is inherent to the set()
function. I have to write nothing. And I don't have the bloat of a
"general validation class".
More bloat.
> Again you are writing code to do something which my framework does
> automatically. And you have the nerve to say that my methods are crap!
>
Nope, my framework automatically handles simple rules based on
datatypes. If I need more complex rules, they are easy to enter.
>>>> >> Others, like passwords where the rules may change, allow the
>>>> >> validation
>>>> >> to be handled by a regex, function call or similar.
>>>> >
>>>> > In my framework any password rues - such as minimum length, the
>>>> > number of
>>>> > uppercase characters, the number of lowercase characters, the
>>>> > number of
>>>> > digits - is controlled from a database record. Each customer can
>>>> > therefore
>>>> > change the rules without me having to change any code.
>>>> >
>>>>
>>>> More bloat. And unnecessary.
>>>
>>> It is necessary if I want to allow the customer to change the password
>>> validation rules without having to write any code. Not having to write
>>> code is not bloat.
>>>
>>
>> More bloat. And unnecessary. How often does the customer want to
>> change the password rules? In about 35 years of programming for
>> clients, I've never had that happen. And what about the existing
>> passwords which don't match the new rules?
>
> A customer may or may not want to change the rules after the software
> has been installed, but as my software is used by many different
> customers each one may want a different set of rules when it is first
> installed. I can apply whatever rules a customer wants simply by
> changing his copy of the database, and NOT by changing any code.
>
Changing one line of code is not a problem. Your way is pure bloat.
It's interesting that this feature you think is slicker than snot on a
doorknob hasn't been implemented by any other systems I'm aware of -
including mainframe applications. The rest of the world knows bloat
when they see it.
>> Why stop with the password? Why not let the customer change the window
>> layout, for instance? Or add tables and columns to the database?
>
> Now you're going off at a tangent. I should quit while you're behind.
>
Nope, you brought up the subject of allowing the customer to change the
rules. This is just an extension of the same subject. After all, CMS's
allow customer's to change the screen layout to suit them; CMS's don't
force all customers to use the same screen layout.
There are many more systems which allow the user to change the page
layout than there are the password. The rest of the world knows bloat
when they see it.
I guess that's all the bloat you're capable of, though. Even a simple
CMS would be beyond your capabilities.
>> Your code is just bloatware and adds an unnecessary layer of
>> complexity to the code.
>>
>>>> >> It also has the ability to generate forms html to display
>>>> >> (read/write or
>>>> >> read only). And this is all one function. If I need a different
>>>> >> layout
>>>> >> for a different page, it's easy to copy/paste a new function and
>>>> >> redo the
>>>> >> output.
>>>> >
>>>> > Copy/Paste? That produces duplicate code, not sharable code, and even
>>>> > you
>>>> > should know that duplicate code violates the DRY principle.
>>>> >
>>>>
>>>> You obviously don't understand the DRY principle. Just because you
>>>> copy/paste does not mean it's duplicate code. Once the code has been
>>>> modified to do something else, it is no longer duplicate.
>>>
>>> If you were really clever you wouldn't have to copy/paste/modify, you
>>> would have a reusable module. In my MVC implementation I have a fixed
>>> set of controllers, and each controller is reusable. Can you say the
>>> same in your framework?
>>>
>>
>> Doesn't make any difference. How do you handle displaying the same
>> information two entirely different ways on two different windows? Mine
>> is simple and straightforward. It is also easy to maintain.
>
> So is mine.
>
Yes? So how do you display the same data in different formats then?
>>>> >> It also has a function to populate the object from $_GET or $_POST
>>>> >> values
>>>> >> (with validation).
>>>> >
>>>> > I don't need a whole function to do that when a single line will do:-
>>>> > $result = $object->insertRecord($_POST);
>>>> >
>>>>
>>>> So what is insertRecord($_POST) then, if it's not a function? Once
>>>> again you show your ignorance. Don't even know what a function is!
>>>
>>> What I'm saying is that I don't have a function which splits the $_POST
>>> array into its component parts so I can then use a setter on each
>>> component, I simply inject the entire $_POST array in a single operation
>>> without the need to split it down into its component parts.
>>>
>>
>> So you do have a function which does the work. That's not what you
>> said earlier.
>
> Read what I wrote. I do *NOT* have any function which splits the input
> array, be it the $_GET array, the $_POST array, or whatever, into its
> component parts. All database data exists in the database table object
> as an array of rows and columns.
>
I never said you had a function which splits the input array. I know
English is not your first language, but you really should learn to read.
>> I never said I had to split it down into parts, either. I have a
>> member function which handles the input. But I guess that's just too
>> much for you to understand.
>
> I beg to differ. You specifically wrote that you have getters and
> setters for each individual column/field. I do not have code which
> splits an array into its component parts as I can access any component
> part while it is still sitting in the array.
>
That's right. That's an implicit part of OO (encapsulation). I didn't
say it was the ONLY thing I did - I also said that I had functions to
display and handle forms (where do you thing $_GET and $_POST come from,
anyway?).
But unlike you, I can get or set a single property, also, as needed.
Something I do all the time.
>>>> > This means that the same line will work on any object regardless of
>>>> > which
>>>> > class it came from. That is what polymorphism is all about.
>>>> >
>>>>
>>>> Nope, that's not at all what polymorphism is about. But you obviously
>>>> don't understand polymorphism, either.
>>>
>>> The definition of polymorphism which I use is "same method, different
>>> implementation". What definition do you use?
>>>
>>
>> You've got a *partial* definition. Polymorphism is only applicable
>> when the two classes have a parent/child hierarchy, and the child
>> class has a method of the same name (and in some languages, the same
>> parameter list) as the parent.
>
> The definition of polymorphism does NOT state that the classes have to
> exist in a parent/child hierarchy, only that they have the same method
> signature. Having said that, it is usually the case that the two classes
> ARE related.
>
Once again you show you have no knowledge of OO. Polymorphism cannot
exist without inheritance - which requires a parent/child hierarchy.
In most languages the method signature must also be the same (in fact I
don't know of any language which doesn't), but that's not a requirement
of polymorphism (unlike the parent/child relationship).
>> When there is no parent/child relationship (as in the case of two
>> different database tables), there is no polymorphism.
>
> Then you obviously haven't used an abstract table class which is
> inherited by every concrete table class. All my concrete table classes
> have instant access to all the methods and properties which are defined
> just once in the abstract class.
>
I've used them much longer than you've even known they existed. When
you have a class derived from the abstract class, there is a
parent/child relationship. But there is no such relationship between
two classes derived from the same one.
>>>> >>>> However, since each class is pretty much independent, I can easily
>>>> >>>> change a class without affecting the rest of the program.
>>>> >>>
>>>> >>> So can I with my framework.
>>>> >>>
>>>> >>>> I don't have it where it will work with multiple tables yet
>>>> >>>> (something
>>>> >>>> I will do one of these days), but it takes a huge amount of the
>>>> >>>> repetitive work off of me.
>>>> >>>
>>>> >>> Removing the need for all this repetitive coding, the "plumbing"
>>>> >>> as I
>>>> >>> call it, is exactly what my framework does.
>>>> >>>
>>>> >>
>>>> >> Not if it only generates a tiny bit of code.
>>>> >
>>>> > You are missing the point as usual. My framework need only generate a
>>>> > small
>>>> > amount of code as everything else, especially all the standard
>>>> > plumbing, is
>>>> > included from standard pre-written functions.
>>>> >
>>>>
>>>> No, I'm missing nothing. But you've clearly shown just how crappy your
>>>> code is.
>>>
>>> Just because it's different from yours does not make it crap.
>>>
>>
>> It's not because it's different that it's crap. It's crap because
>> you've shown here it's crap.
>
> Only in your tiny mind.
>
So you wish, anyway.
>>>> >>>> And no, I don't try to use it for every project. But where a
>>>> >>>> project
>>>> >>>> is database-intensive, it suits my purposes.
>>>> >>>
>>>> >>> All my applications are database-intensive, which is why I use a
>>>> >>> framework which is centred around the database.
>>>> >>>
>>>> >>
>>>> >> Ah, that explains it, then. Database access is easy (although many
>>>> >> people
>>>> >> can still screw that up). Most of my applications need to do real
>>>> >> work.
>>>> >
>>>> > My framework takes care of all the standard database access, and
>>>> > getting
>>>> > data in and out of the screen, plus basic data validation. As for the
>>>> > "real
>>>> > work" as you call - or the "payload" as I call it - that is done by
>>>> > adding
>>>> > whatever code is necessary in the relevant class to implement each
>>>> > business
>>>> > rule. The point is that when using my framework the programmer has to
>>>> > spend
>>>> > little or no time on the standard plumbing, which leaves him with
>>>> > much more
>>>> > time to spend on the payload.
>>>> >
>>>>
>>>> Yup, you've never done any applications which require real work, as
>>>> you once again have shown.
>>>
>>> Then you obviously have not experienced the complicated things which
>>> need to be done in an ERP application.
>>>
>>
>> Obviously neither have you. What you have is not a real ERP
>> application. I suspect your customer would do as well with an Excel
>> spreadsheet.
>
> It is real enough for my paying customers, and it is THEIR opinion that
> counts, not yours.
>
And it shows just how little you understand ERP systems. Just because
you call it an ERP doesn't mean it is an ERP. But it shows the rest of
the world how ignorant you are.
All you have is a simple order entry/tracking system, not an ERP.
>> And I wonder what your customer would think if he knew you were taking
>> credit for his hard work in building his business.
>
> The comment that my software helped that particular customer in that way
> was actually made by one of the directors of that company.
>
And I wonder what your customer would think if he knew you were taking
credit for his hard work in building his business.
>>>> >> But I'm also not so stupid as to think that my frameworks is good for
>>>> >> everyone. It works for me. But I don't try to foist it off on someone
>>>> >> else without telling them it's my framework. That is just plain
>>>> >> dishonest.
>>>> >
>>>> > I never said that my framework is the perfect solution for everyone.
>>>> > If you
>>>> > a writing a simple website then it's not good, but if you are
>>>> > writing a
>>>> > database application then it's better than most.
>>>> >
>>>>
>>>> Hmmm, you sure seemed to indicate that when you first started pushing
>>>> this piece of horse hockey.
>>>
>>> That may have been the impression that you got, but you have indicated
>>> time and time again that your mind works in mysterious ways.
>>>
>>
>> Yea, I live in the real world and have real world experience. Unlike
>> you, who seems to live in some alternative universe where you can make
>> up any rules you want and can ignore those you don't like. You can
>> call a simple database application an ERP and take all the credit for
>> your client's hard work.
>
> It is much more than a simple database application which does nothing
> more than move data between the user interface and the database. It
> processes a large number of business rules, and it is the number and
> complexity of these business rules which decides whether an application
> is actually complex or not.
>
In your world, yes. But then all you've ever done are database
applications. You've never worked on anything even moderately complex,
by your own admission.
>>>> > I was never dishonest about the Radicore framework. I never said it
>>>> > was
>>>> > written by someone else. I even include a link to the radicore
>>>> > website in my
>>>> > signature.
>>>> >
>>>>
>>>> And you never said it was written by you, and that you were nowhere
>>>> near an unbiased user. The fact you are pushing your own product
>>>> without telling people you have a vested interest is dishonest. The
>>>> fact you have a link to it in your sig is immaterial - lots of people
>>>> have links in their sigs to all kinds of things.
>>>>
>>>> But then I can see why you don't want to tell people it's your
>>>> product. I wouldn't want to admit to having created that piece of
>>>> horse hockey, either.
>>>
>>> You're the expert in horse hockey judging by the amount you write in
>>> these posts.
>>>
>>
>> Nope, I know how to program properly. You've obviously never worked in
>> a corporate environment, for instance, where you have multiple
>> programmers and have to learn good programming techniques.
>
> I worked in several software houses for many years, and I dealt with
> many different projects for many different customers. I was also project
> leader on a good number of those projects. I also wrote the framework
> used in one of those software houses as well as setting the development
> standards.
>
Were all of those simple database applications also? I suspect so,
because that's all you've ever done.
But then I can see why you weren't able to keep a job with any of those
software houses.
>>>> > If *your* framework is so good, then why don't you release it as open
>>>> > source
>>>> > so that we call all have a laugh?
>>>> >
>>>>
>>>> For a lot of reasons. Mainly because I'm not interested in the hassles
>>>> of having to support it for a bunch of people who want all kinds of
>>>> other features. I created it for my projects, and it serves those
>>>> projects well.
>>>
>>> What you really mean is that you are too ashamed to have it reviewed by
>>> your peers, and that you are incapable of writing code which can be used
>>> by others.
>>>
>>
>> Not at all. I meant exactly what I said.
>
> Yes, you can't be bothered to release it as it is only useful for your
> own personal toy projects.
>
Nope. I just don't want to have to answer a bunch of anal questions by
the likes of you. I have better things to do with my time.
>> Unlike you, I don't need my ego stroked.
>
> That's not the impression I get from reading your comments in this post.
> You seem to think that YOUR way is the ONLY way, and anybody who dares
> to disagree with you is a stupid moron. I disagree with everything you
> say, and as for being a moron, 99% of the emails which I receive on the
> subject on my work are nothing but complimentary.
>
Nope. I didn't say my way was the only way. I said my way works, does
not contain bloatware and follows recognized OO practices. All you can
claim is yours works.
And knowing how the rest of the world feels about the ability of PHP
programmers, it's not surprising. I've seen some pretty crappy code get
high marks because people don't know any better.
>> But my code is reviewed by others quite often. Most projects I work on
>> are collaborative. But then I work with programmers who know what
>> they're doing, also.
>
> I'd hate to on a team of programmers who all think like you as they
> would all be unproductive and full of silly ideas.
>
We work quite well together and create a lot of GOOD code. Unlike the
crap you put put.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]