468,765 Members | 1,036 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,765 developers. It's quick & easy.

There's got to be a better way

There's got to be a better way:
if (isset($c['s']['a1'])) echo $c['s']['a1']."<br>";
if (isset($c['s']['a2'])) echo $c['s']['a2']."<br>";
if (isset($c['s']['a3'])) echo $c['s']['a3']."<br>";
if (isset($c['s']['a4'])) echo $c['s']['a4']."<br>";
if (isset($c['s']['a5'])) echo $c['s']['a5']."<br>";

but it's late and my brain is frazzled. Any ideas, oh PHP gurus?

--
"Checking identity papers is a complete waste of time. If anyone can
be counted on to have valid papers, it will be the terrorists".
Mar 24 '07 #1
19 1420
Mary Pegg pravi:
There's got to be a better way:
if (isset($c['s']['a1'])) echo $c['s']['a1']."<br>";
if (isset($c['s']['a2'])) echo $c['s']['a2']."<br>";
if (isset($c['s']['a3'])) echo $c['s']['a3']."<br>";
if (isset($c['s']['a4'])) echo $c['s']['a4']."<br>";
if (isset($c['s']['a5'])) echo $c['s']['a5']."<br>";

but it's late and my brain is frazzled. Any ideas, oh PHP gurus?
Dunno about php but i think theoreticaly this should work:

$counter = 1
while $count < 6 do {
if (isset($c['s']['a.$counter'])) echo $c['s']['a$counter']."<br>";

$counter++;
}

regards,
Mar 24 '07 #2
Mary Pegg wrote:
There's got to be a better way:
if (isset($c['s']['a1'])) echo $c['s']['a1']."<br>";
if (isset($c['s']['a2'])) echo $c['s']['a2']."<br>";
if (isset($c['s']['a3'])) echo $c['s']['a3']."<br>";
if (isset($c['s']['a4'])) echo $c['s']['a4']."<br>";
if (isset($c['s']['a5'])) echo $c['s']['a5']."<br>";

but it's late and my brain is frazzled. Any ideas, oh PHP gurus?
Perhaps like this?

foreach ($c['s'] as $item) {
echo $item."<br>";
}

If you want an extra check, you could also surround it with this:
if (isset($c['s']) and is_array($c['s'])) {
}

--
Kim André Akerĝ
- ki******@NOSPAMbetadome.com
(remove NOSPAM to contact me directly)
Mar 24 '07 #3
Snahad00 kirjoitti:
Mary Pegg pravi:
>There's got to be a better way:
if (isset($c['s']['a1'])) echo $c['s']['a1']."<br>";
if (isset($c['s']['a2'])) echo $c['s']['a2']."<br>";
if (isset($c['s']['a3'])) echo $c['s']['a3']."<br>";
if (isset($c['s']['a4'])) echo $c['s']['a4']."<br>";
if (isset($c['s']['a5'])) echo $c['s']['a5']."<br>";

but it's late and my brain is frazzled. Any ideas, oh PHP gurus?

Dunno about php but i think theoreticaly this should work:

$counter = 1
while $count < 6 do {
if (isset($c['s']['a.$counter'])) echo $c['s']['a$counter']."<br>";

$counter++;
}
Let's try again, shall we.

for($counter=1;$counter<6;$counter++)
if (isset($c['s']['a'.$counter]))
echo $c['s']['a'.$counter]."<br>";

--
Ra*********@gmail.com
"Olemme apinoiden planeetalla."
Mar 24 '07 #4
Rami Elomaa wrote:
Let's try again, shall we.

for($counter=1;$counter<6;$counter++)
if (isset($c['s']['a'.$counter]))
echo $c['s']['a'.$counter]."<br>";
Thanks. In the clear light of day, I think I'm going to stick with
what I've got anyway. There's lots of other things coming out of
$c['s'], and the existing way is arguably more readable.

--
"Checking identity papers is a complete waste of time. If anyone can
be counted on to have valid papers, it will be the terrorists".
Mar 24 '07 #5
On 24 Mar, 15:37, Mary Pegg <inva...@invalid.comwrote:
Rami Elomaa wrote:
Let's try again, shall we.
for($counter=1;$counter<6;$counter++)
if (isset($c['s']['a'.$counter]))
echo $c['s']['a'.$counter]."<br>";
what I've got anyway. There's lots of other things coming out of
which is why you shouldnt be doing it this way
$c['s'], and the existing way is arguably more readable.
that's a daft reason, its completely unmaintainable and unextensible
no more readable to someone familiar with other basic php constructs
what if you start learning about XSS and decide you need to protect
yourself against it, then you will have to find examples such as this
and change them all to
if (isset($c['s']['a5'])) echo htmlentities($c['s']['a1'])."<br>";
..
..
..
if (isset($c['s']['a5'])) echo htmlentities($c['s']['a5'])."<br>";
that's alot of work for sake of sticking with what _you_ find more
readable
and what if you then decide you need your pages to validate to xhtml?
oh dear another trip through all your scripts:
if (isset($c['s']['a5'])) echo htmlentities($c['s']['a1'])."<br />";
..
..
..
if (isset($c['s']['a5'])) echo htmlentities($c['s']['a5'])."<br />";
what if you add more tha a5, or if you change the keys
uh oh!

there are standards in programming, designed to make code more
acceptable to others coming after you
all the chages above and more are so simple with Rani's method. If you
can't take good advice don't ask for it.
Mar 24 '07 #6
shimmyshack wrote:
if (isset($c['s']['a5'])) echo htmlentities($c['s']['a1'])."<br>";
.
.
.
if (isset($c['s']['a5'])) echo htmlentities($c['s']['a5'])."<br>";
that's alot of work for sake of sticking with what _you_ find more
readable
So what you're really arguing in favour of is wrapping it up in a
function, which is what I've done. But the question is whether it's
worth creating a for loop to run through a1 to a5 rather than simply
calling each by name.
all the chages above and more are so simple with Rani's method. If you
No, they're simple if it's wrapped up in a function. Whether or not
a1 to a5 get generated by a for loop I've still got b, c, d, e, f (etc)
to deal with. NB I'm using these as symbols - in reality they are the
field names from a database, so no getting smart and suggesting that I
can generate b to f automagically. OTOH I could stick the field names
in an array and step through the array. This might be worth doing.
can't take good advice don't ask for it.
I know this is Usenet but you don't *have* to be rude and abrasive.

--
"Checking identity papers is a complete waste of time. If anyone can
be counted on to have valid papers, it will be the terrorists".
Mar 25 '07 #7
On 25 Mar, 21:37, Mary Pegg <inva...@invalid.comwrote:
shimmyshack wrote:
if (isset($c['s']['a5'])) echo htmlentities($c['s']['a1'])."<br>";
.
.
.
if (isset($c['s']['a5'])) echo htmlentities($c['s']['a5'])."<br>";
that's alot of work for sake of sticking with what _you_ find more
readable

So what you're really arguing in favour of is wrapping it up in a
function, which is what I've done. But the question is whether it's
worth creating a for loop to run through a1 to a5 rather than simply
calling each by name.
all the chages above and more are so simple with Rani's method. If you

No, they're simple if it's wrapped up in a function. Whether or not
a1 to a5 get generated by a for loop I've still got b, c, d, e, f (etc)
to deal with. NB I'm using these as symbols - in reality they are the
field names from a database, so no getting smart and suggesting that I
can generate b to f automagically. OTOH I could stick the field names
in an array and step through the array. This might be worth doing.
can't take good advice don't ask for it.

I know this is Usenet but you don't *have* to be rude and abrasive.

--
"Checking identity papers is a complete waste of time. If anyone can
be counted on to have valid papers, it will be the terrorists".
it's not rude or abrasive, to notice you don't take advice and say so,
perhaps a little bruusque though, and I apologise if I made you cross.
FYI, I work with annoyingly complex database tables whose structure
changes as my client changes their requirements, to stop this kind of
hard coded approach which started to cost me too much time, I use
DESCRIBE `tablename`, and SHOW FULL COLUMNS FROM `tablename` which can
then be used to get the comments, fieldnames etc... then using a reg
exp on bool enum varchar() int() and so on to get metadata about the
table which is then pumped into the application.
In this way you can use general methods to print and parse data
without ever having to hard code the fieldnames, you can use it to
dynamically generate forms etc...
Instead of repeatedly writing code to format output from the DB, you
just need a vlid link, and some form of instructions what your db
connection is to "get" and "output" and finally the output format -
preventing too much or too little from being drawn from the DB. You
only have to code this once, and after than it can be used everywhere
you need output. It might seem a little extreme to folks, I don't
know, but I find this approach saves time. The class which serves html
markup can end up being very complex but you can control things with a
couple of calls and an array.

Mar 25 '07 #8
shimmyshack wrote:
On 25 Mar, 21:37, Mary Pegg <inva...@invalid.comwrote:
>shimmyshack wrote:
>>if (isset($c['s']['a5'])) echo htmlentities($c['s']['a1'])."<br>";
.
.
.
if (isset($c['s']['a5'])) echo htmlentities($c['s']['a5'])."<br>";
that's alot of work for sake of sticking with what _you_ find more
readable
So what you're really arguing in favour of is wrapping it up in a
function, which is what I've done. But the question is whether it's
worth creating a for loop to run through a1 to a5 rather than simply
calling each by name.
>>all the chages above and more are so simple with Rani's method. If you
No, they're simple if it's wrapped up in a function. Whether or not
a1 to a5 get generated by a for loop I've still got b, c, d, e, f (etc)
to deal with. NB I'm using these as symbols - in reality they are the
field names from a database, so no getting smart and suggesting that I
can generate b to f automagically. OTOH I could stick the field names
in an array and step through the array. This might be worth doing.
>>can't take good advice don't ask for it.
I know this is Usenet but you don't *have* to be rude and abrasive.

--
"Checking identity papers is a complete waste of time. If anyone can
be counted on to have valid papers, it will be the terrorists".

it's not rude or abrasive, to notice you don't take advice and say so,
perhaps a little bruusque though, and I apologise if I made you cross.
FYI, I work with annoyingly complex database tables whose structure
changes as my client changes their requirements, to stop this kind of
hard coded approach which started to cost me too much time, I use
DESCRIBE `tablename`, and SHOW FULL COLUMNS FROM `tablename` which can
then be used to get the comments, fieldnames etc... then using a reg
exp on bool enum varchar() int() and so on to get metadata about the
table which is then pumped into the application.
In this way you can use general methods to print and parse data
without ever having to hard code the fieldnames, you can use it to
dynamically generate forms etc...
Instead of repeatedly writing code to format output from the DB, you
just need a vlid link, and some form of instructions what your db
connection is to "get" and "output" and finally the output format -
preventing too much or too little from being drawn from the DB. You
only have to code this once, and after than it can be used everywhere
you need output. It might seem a little extreme to folks, I don't
know, but I find this approach saves time. The class which serves html
markup can end up being very complex but you can control things with a
couple of calls and an array.
PMJI, but then you aren't much of a programmer.

I've been doing SQL Database work for over 20 years now. I'll bet some
of the databases I've designed would make yours look puny - over 100
tables, over 1,500 columns, for instance. And mostly 3rd normal form.

And yes, these databases do change as customer requirements change. But
I deal with them.

Your problem is that the user actually *cares* about the contents of the
database. They don't. What they do care about is the *data* -
including the relationships. Whether data is contained in one table or
ten is not important.

You can give all the excuses you want for not taking good advice. But
the bottom line is - you haven't given any excuses we haven't heard
hundreds of times. And you aren't explaining a situation most of us
haven't run into multiple times. And we deal with it properly.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Mar 25 '07 #9
On 25 Mar, 23:37, Jerry Stuckle <jstuck...@attglobal.netwrote:
shimmyshack wrote:
On 25 Mar, 21:37, Mary Pegg <inva...@invalid.comwrote:
shimmyshack wrote:
if (isset($c['s']['a5'])) echo htmlentities($c['s']['a1'])."<br>";
.
.
.
if (isset($c['s']['a5'])) echo htmlentities($c['s']['a5'])."<br>";
that's alot of work for sake of sticking with what _you_ find more
readable
So what you're really arguing in favour of is wrapping it up in a
function, which is what I've done. But the question is whether it's
worth creating a for loop to run through a1 to a5 rather than simply
calling each by name.
>all the chages above and more are so simple with Rani's method. If you
No, they're simple if it's wrapped up in a function. Whether or not
a1 to a5 get generated by a for loop I've still got b, c, d, e, f (etc)
to deal with. NB I'm using these as symbols - in reality they are the
field names from a database, so no getting smart and suggesting that I
can generate b to f automagically. OTOH I could stick the field names
in an array and step through the array. This might be worth doing.
>can't take good advice don't ask for it.
I know this is Usenet but you don't *have* to be rude and abrasive.
--
"Checking identity papers is a complete waste of time. If anyone can
be counted on to have valid papers, it will be the terrorists".
it's not rude or abrasive, to notice you don't take advice and say so,
perhaps a little bruusque though, and I apologise if I made you cross.
FYI, I work with annoyingly complex database tables whose structure
changes as my client changes their requirements, to stop this kind of
hard coded approach which started to cost me too much time, I use
DESCRIBE `tablename`, and SHOW FULL COLUMNS FROM `tablename` which can
then be used to get the comments, fieldnames etc... then using a reg
exp on bool enum varchar() int() and so on to get metadata about the
table which is then pumped into the application.
In this way you can use general methods to print and parse data
without ever having to hard code the fieldnames, you can use it to
dynamically generate forms etc...
Instead of repeatedly writing code to format output from the DB, you
just need a vlid link, and some form of instructions what your db
connection is to "get" and "output" and finally the output format -
preventing too much or too little from being drawn from the DB. You
only have to code this once, and after than it can be used everywhere
you need output. It might seem a little extreme to folks, I don't
know, but I find this approach saves time. The class which serves html
markup can end up being very complex but you can control things with a
couple of calls and an array.

PMJI, but then you aren't much of a programmer.

I've been doing SQL Database work for over 20 years now. I'll bet some
of the databases I've designed would make yours look puny - over 100
tables, over 1,500 columns, for instance. And mostly 3rd normal form.

And yes, these databases do change as customer requirements change. But
I deal with them.

Your problem is that the user actually *cares* about the contents of the
database. They don't. What they do care about is the *data* -
including the relationships. Whether data is contained in one table or
ten is not important.

You can give all the excuses you want for not taking good advice. But
the bottom line is - you haven't given any excuses we haven't heard
hundreds of times. And you aren't explaining a situation most of us
haven't run into multiple times. And we deal with it properly.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================
I'm not sure what to make of that Jerry, but I wonder if my point was
clear enough. The idea is to write php classes which auto discover DB
structure, as does say phpmyadmin. The idea is to let the DB structure
be _independent_ of the php code, responding to changes within the DB
such as character encoding, field types, number of columns etc... so
that little or no hard coding and adjusting of the logic is needed,
just an adjustment - if any - to the "display" if one can call it that
- to config that prescribes the way the code interacts with the DB
tables.
I don't then mind how often changes are made to the DB structure,
which as you say always changes as the project grows and the
relationships become clearer, nor do I mind how often the tables are
split (pi$$ing contest avoided), provided a there exists a
data<~>query map.
ALways with programming it's bread and butter, reinventing the wheel
for each new app (even with OO)
forming the query, running it, getting the data, persisting it,
parsing, filtering, displaying and so on...
I wanted something a bit more like a fluent interface, more readable
and "semantic", in that it moves things on from having to write step
by step, and makes things a bit more fluid. I would be nice to get
eventually to a form where anyone could write in words what they
required; perhaps when chicken foot's reg exp parser comes up with
this ;)
I personally hate to see the type of hard coded stuff that gets banged
out, but it exists in the real world - of course.

Mar 25 '07 #10
shimmyshack wrote:
it's not rude or abrasive, to notice you don't take advice and say so,
perhaps a little bruusque though, and I apologise if I made you cross.
Apology gladly accepted!

I thought about this further by taking it to extremes. If I was
calling func(a1), func(a2)... func(a100) then it's a no-brainer,
use a for loop. OTOH if I had only two to do, a for loop would
look a bit silly. So which side of the line is five?

--
"Checking identity papers is a complete waste of time. If anyone can
be counted on to have valid papers, it will be the terrorists".
Mar 25 '07 #11
shimmyshack wrote:
On 25 Mar, 23:37, Jerry Stuckle <jstuck...@attglobal.netwrote:
>shimmyshack wrote:
>>On 25 Mar, 21:37, Mary Pegg <inva...@invalid.comwrote:
shimmyshack wrote:
if (isset($c['s']['a5'])) echo htmlentities($c['s']['a1'])."<br>";
.
.
.
if (isset($c['s']['a5'])) echo htmlentities($c['s']['a5'])."<br>";
that's alot of work for sake of sticking with what _you_ find more
readable
So what you're really arguing in favour of is wrapping it up in a
function, which is what I've done. But the question is whether it's
worth creating a for loop to run through a1 to a5 rather than simply
calling each by name.
all the chages above and more are so simple with Rani's method. If you
No, they're simple if it's wrapped up in a function. Whether or not
a1 to a5 get generated by a for loop I've still got b, c, d, e, f (etc)
to deal with. NB I'm using these as symbols - in reality they are the
field names from a database, so no getting smart and suggesting that I
can generate b to f automagically. OTOH I could stick the field names
in an array and step through the array. This might be worth doing.
can't take good advice don't ask for it.
I know this is Usenet but you don't *have* to be rude and abrasive.
--
"Checking identity papers is a complete waste of time. If anyone can
be counted on to have valid papers, it will be the terrorists".
it's not rude or abrasive, to notice you don't take advice and say so,
perhaps a little bruusque though, and I apologise if I made you cross.
FYI, I work with annoyingly complex database tables whose structure
changes as my client changes their requirements, to stop this kind of
hard coded approach which started to cost me too much time, I use
DESCRIBE `tablename`, and SHOW FULL COLUMNS FROM `tablename` which can
then be used to get the comments, fieldnames etc... then using a reg
exp on bool enum varchar() int() and so on to get metadata about the
table which is then pumped into the application.
In this way you can use general methods to print and parse data
without ever having to hard code the fieldnames, you can use it to
dynamically generate forms etc...
Instead of repeatedly writing code to format output from the DB, you
just need a vlid link, and some form of instructions what your db
connection is to "get" and "output" and finally the output format -
preventing too much or too little from being drawn from the DB. You
only have to code this once, and after than it can be used everywhere
you need output. It might seem a little extreme to folks, I don't
know, but I find this approach saves time. The class which serves html
markup can end up being very complex but you can control things with a
couple of calls and an array.
PMJI, but then you aren't much of a programmer.

I've been doing SQL Database work for over 20 years now. I'll bet some
of the databases I've designed would make yours look puny - over 100
tables, over 1,500 columns, for instance. And mostly 3rd normal form.

And yes, these databases do change as customer requirements change. But
I deal with them.

Your problem is that the user actually *cares* about the contents of the
database. They don't. What they do care about is the *data* -
including the relationships. Whether data is contained in one table or
ten is not important.

You can give all the excuses you want for not taking good advice. But
the bottom line is - you haven't given any excuses we haven't heard
hundreds of times. And you aren't explaining a situation most of us
haven't run into multiple times. And we deal with it properly.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================

I'm not sure what to make of that Jerry, but I wonder if my point was
clear enough. The idea is to write php classes which auto discover DB
structure, as does say phpmyadmin. The idea is to let the DB structure
be _independent_ of the php code, responding to changes within the DB
such as character encoding, field types, number of columns etc... so
that little or no hard coding and adjusting of the logic is needed,
just an adjustment - if any - to the "display" if one can call it that
- to config that prescribes the way the code interacts with the DB
tables.
I don't then mind how often changes are made to the DB structure,
which as you say always changes as the project grows and the
relationships become clearer, nor do I mind how often the tables are
split (pi$$ing contest avoided), provided a there exists a
data<~>query map.
ALways with programming it's bread and butter, reinventing the wheel
for each new app (even with OO)
forming the query, running it, getting the data, persisting it,
parsing, filtering, displaying and so on...
I wanted something a bit more like a fluent interface, more readable
and "semantic", in that it moves things on from having to write step
by step, and makes things a bit more fluid. I would be nice to get
eventually to a form where anyone could write in words what they
required; perhaps when chicken foot's reg exp parser comes up with
this ;)
I personally hate to see the type of hard coded stuff that gets banged
out, but it exists in the real world - of course.
You just don't get it, do you. The DB Structure is not important to the
client. The DB CONTENTS ARE!

For instance - in the case of an order entry system. Does the user want :

order_number product_number quantity

Or do they want:

Customer name
Order_number product_name quantity Price Total_Price

PhPMyAdmin is for administering a MySQL database. The user isn't
interested in the administration of the database. He/she is interested
in the contents. And not just one table, like above. Rather, he's
interested in the joining of at least three tables - maybe more.

Sure, I rewrite code each time I start a new project with a new
database. That's because every database is unique and has unique
requirements.

What you think would be nice really isn't realistic, other than for
simple database admin like PhPMyAdmin.

Programming is all about reinventing the wheel. For instance, almost
every PHP statement has been written at least once. Sure, the variable
names change, but that's about it. But it's how you put the statements
together that counts.

Same with databases. It's not about the access. And it's not about
database design.

It's about how things fit together to provide data in a format a person
can use.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Mar 26 '07 #12
On 26 Mar, 02:33, Jerry Stuckle <jstuck...@attglobal.netwrote:
shimmyshack wrote:
On 25 Mar, 23:37, Jerry Stuckle <jstuck...@attglobal.netwrote:
shimmyshack wrote:
On 25 Mar, 21:37, Mary Pegg <inva...@invalid.comwrote:
shimmyshack wrote:
if (isset($c['s']['a5'])) echo htmlentities($c['s']['a1'])."<br>";
.
.
.
if (isset($c['s']['a5'])) echo htmlentities($c['s']['a5'])."<br>";
that's alot of work for sake of sticking with what _you_ find more
readable
So what you're really arguing in favour of is wrapping it up in a
function, which is what I've done. But the question is whether it's
worth creating a for loop to run through a1 to a5 rather than simply
calling each by name.
all the chages above and more are so simple with Rani's method. If you
No, they're simple if it's wrapped up in a function. Whether or not
a1 to a5 get generated by a for loop I've still got b, c, d, e, f (etc)
to deal with. NB I'm using these as symbols - in reality they are the
field names from a database, so no getting smart and suggesting that I
can generate b to f automagically. OTOH I could stick the field names
in an array and step through the array. This might be worth doing.
can't take good advice don't ask for it.
I know this is Usenet but you don't *have* to be rude and abrasive.
--
"Checking identity papers is a complete waste of time. If anyone can
be counted on to have valid papers, it will be the terrorists".
it's not rude or abrasive, to notice you don't take advice and say so,
perhaps a little bruusque though, and I apologise if I made you cross.
FYI, I work with annoyingly complex database tables whose structure
changes as my client changes their requirements, to stop this kind of
hard coded approach which started to cost me too much time, I use
DESCRIBE `tablename`, and SHOW FULL COLUMNS FROM `tablename` which can
then be used to get the comments, fieldnames etc... then using a reg
exp on bool enum varchar() int() and so on to get metadata about the
table which is then pumped into the application.
In this way you can use general methods to print and parse data
without ever having to hard code the fieldnames, you can use it to
dynamically generate forms etc...
Instead of repeatedly writing code to format output from the DB, you
just need a vlid link, and some form of instructions what your db
connection is to "get" and "output" and finally the output format -
preventing too much or too little from being drawn from the DB. You
only have to code this once, and after than it can be used everywhere
you need output. It might seem a little extreme to folks, I don't
know, but I find this approach saves time. The class which serves html
markup can end up being very complex but you can control things with a
couple of calls and an array.
PMJI, but then you aren't much of a programmer.
I've been doing SQL Database work for over 20 years now. I'll bet some
of the databases I've designed would make yours look puny - over 100
tables, over 1,500 columns, for instance. And mostly 3rd normal form.
And yes, these databases do change as customer requirements change. But
I deal with them.
Your problem is that the user actually *cares* about the contents of the
database. They don't. What they do care about is the *data* -
including the relationships. Whether data is contained in one table or
ten is not important.
You can give all the excuses you want for not taking good advice. But
the bottom line is - you haven't given any excuses we haven't heard
hundreds of times. And you aren't explaining a situation most of us
haven't run into multiple times. And we deal with it properly.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================
I'm not sure what to make of that Jerry, but I wonder if my point was
clear enough. The idea is to write php classes which auto discover DB
structure, as does say phpmyadmin. The idea is to let the DB structure
be _independent_ of the php code, responding to changes within the DB
such as character encoding, field types, number of columns etc... so
that little or no hard coding and adjusting of the logic is needed,
just an adjustment - if any - to the "display" if one can call it that
- to config that prescribes the way the code interacts with the DB
tables.
I don't then mind how often changes are made to the DB structure,
which as you say always changes as the project grows and the
relationships become clearer, nor do I mind how often the tables are
split (pi$$ing contest avoided), provided a there exists a
data<~>query map.
ALways with programming it's bread and butter, reinventing the wheel
for each new app (even with OO)
forming the query, running it, getting the data, persisting it,
parsing, filtering, displaying and so on...
I wanted something a bit more like a fluent interface, more readable
and "semantic", in that it moves things on from having to write step
by step, and makes things a bit more fluid. I would be nice to get
eventually to a form where anyone could write in words what they
required; perhaps when chicken foot's reg exp parser comes up with
this ;)
I personally hate to see the type of hard coded stuff that gets banged
out, but it exists in the real world - of course.

You just don't get it, do you. The DB Structure is not important to the
client. The DB CONTENTS ARE!

For instance - in the case of an order entry system. Does the user want :

order_number product_number quantity

Or do they want:

Customer name
Order_number product_name quantity Price Total_Price

PhPMyAdmin is for administering a MySQL database. The user isn't
interested in the administration of the database. He/she is interested
in the contents. And not just one table, like above. Rather, he's
interested in the joining of at least three tables - maybe more.

Sure, I rewrite code each time I start a new project with a new
database. That's because every database is unique and has unique
requirements.

What you think would be nice really isn't realistic, other than for
simple database admin like PhPMyAdmin.

Programming is all about reinventing the wheel. For instance, almost
every PHP statement has been written at least once. Sure, the variable
names change, but that's about it. But it's how you put the statements
together that counts.

Same with databases. It's not about the access. And it's not about
database design.

It's about how things fit together to provide data in a format a person
can use.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================
I think you have missed the point again Jerry; although I would say
that database design and access can be very important for large
projects for optimisation. I am only building on this exact point:
>It's about how things fit together to provide data in a format a person can use.
the rest is just a given. You are cross at someone but it isn't me.

It can only be reiterated: although coding is about reinventing the
wheel, this is pointless, and will change into the future, becoming
more high level and looking and feeling less like C.
Finally resulting in code that looks like a sentence, and compiles to
be equivalent to today's stuff. Until the compilers get cleverer, the
wheel reinvention problem can be solved using clever code.

Your point
>The DB Structure is not important to the client. The DB CONTENTS ARE!
can be widened, the client doesn't care about anything except
functionality on time to budget.
true but that implies fast writing of code, with less skills required
to write it and greater ease of maintainability. One of SQLs great
pluses is that it's not that hard to learn and it can read like a
sentence at the basic level.
The same can and will be true of a scripting lang like php.
The upshot is writing code independent of DB structure, independent of
markup requirements, which takes a config file, rather like Ant builds
an application, means less stress for you - the over worked wheel
reinventor, and less stress for the client, who likes rapid app dev.

I dunno where we are arguing, unless your 20+yrs has blinded you to
the possibility of a world where Joe Bloggs back office boy can
program because Joe Blogg's dad the guru made a compiler that
understood english.
What got my goat was that printing statements out in googlicate was
just the kind of thing that causes problems into the future, while it
might compile to something similar to a judiciously chosen while loop,
it just feels rather intellectually lazy, no offence intended.

In the same way people argued against calculators I guess you can
still disagree. Calculators let anyone leapfrog the grunt work, and
start with the interesting Maths. The metphor is writing code once
that then let's the programmer get on with writing the app, rather
than reinventing the wheel and grinding out lines of the same old
code. Not everyone loves the destination as much as they do the
journey. oo deep

Mar 26 '07 #13
shimmyshack wrote:
On 26 Mar, 02:33, Jerry Stuckle <jstuck...@attglobal.netwrote:
>shimmyshack wrote:
>>On 25 Mar, 23:37, Jerry Stuckle <jstuck...@attglobal.netwrote:
shimmyshack wrote:
On 25 Mar, 21:37, Mary Pegg <inva...@invalid.comwrote:
>shimmyshack wrote:
>>if (isset($c['s']['a5'])) echo htmlentities($c['s']['a1'])."<br>";
>>.
>>.
>>.
>>if (isset($c['s']['a5'])) echo htmlentities($c['s']['a5'])."<br>";
>>that's alot of work for sake of sticking with what _you_ find more
>>readable
>So what you're really arguing in favour of is wrapping it up in a
>function, which is what I've done. But the question is whether it's
>worth creating a for loop to run through a1 to a5 rather than simply
>calling each by name.
>>all the chages above and more are so simple with Rani's method. If you
>No, they're simple if it's wrapped up in a function. Whether or not
>a1 to a5 get generated by a for loop I've still got b, c, d, e, f (etc)
>to deal with. NB I'm using these as symbols - in reality they are the
>field names from a database, so no getting smart and suggesting that I
>can generate b to f automagically. OTOH I could stick the field names
>in an array and step through the array. This might be worth doing.
>>can't take good advice don't ask for it.
>I know this is Usenet but you don't *have* to be rude and abrasive.
>--
>"Checking identity papers is a complete waste of time. If anyone can
>be counted on to have valid papers, it will be the terrorists".
it's not rude or abrasive, to notice you don't take advice and say so,
perhaps a little bruusque though, and I apologise if I made you cross.
FYI, I work with annoyingly complex database tables whose structure
changes as my client changes their requirements, to stop this kind of
hard coded approach which started to cost me too much time, I use
DESCRIBE `tablename`, and SHOW FULL COLUMNS FROM `tablename` which can
then be used to get the comments, fieldnames etc... then using a reg
exp on bool enum varchar() int() and so on to get metadata about the
table which is then pumped into the application.
In this way you can use general methods to print and parse data
without ever having to hard code the fieldnames, you can use it to
dynamically generate forms etc...
Instead of repeatedly writing code to format output from the DB, you
just need a vlid link, and some form of instructions what your db
connection is to "get" and "output" and finally the output format -
preventing too much or too little from being drawn from the DB. You
only have to code this once, and after than it can be used everywhere
you need output. It might seem a little extreme to folks, I don't
know, but I find this approach saves time. The class which serves html
markup can end up being very complex but you can control things with a
couple of calls and an array.
PMJI, but then you aren't much of a programmer.
I've been doing SQL Database work for over 20 years now. I'll bet some
of the databases I've designed would make yours look puny - over 100
tables, over 1,500 columns, for instance. And mostly 3rd normal form.
And yes, these databases do change as customer requirements change. But
I deal with them.
Your problem is that the user actually *cares* about the contents of the
database. They don't. What they do care about is the *data* -
including the relationships. Whether data is contained in one table or
ten is not important.
You can give all the excuses you want for not taking good advice. But
the bottom line is - you haven't given any excuses we haven't heard
hundreds of times. And you aren't explaining a situation most of us
haven't run into multiple times. And we deal with it properly.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================
I'm not sure what to make of that Jerry, but I wonder if my point was
clear enough. The idea is to write php classes which auto discover DB
structure, as does say phpmyadmin. The idea is to let the DB structure
be _independent_ of the php code, responding to changes within the DB
such as character encoding, field types, number of columns etc... so
that little or no hard coding and adjusting of the logic is needed,
just an adjustment - if any - to the "display" if one can call it that
- to config that prescribes the way the code interacts with the DB
tables.
I don't then mind how often changes are made to the DB structure,
which as you say always changes as the project grows and the
relationships become clearer, nor do I mind how often the tables are
split (pi$$ing contest avoided), provided a there exists a
data<~>query map.
ALways with programming it's bread and butter, reinventing the wheel
for each new app (even with OO)
forming the query, running it, getting the data, persisting it,
parsing, filtering, displaying and so on...
I wanted something a bit more like a fluent interface, more readable
and "semantic", in that it moves things on from having to write step
by step, and makes things a bit more fluid. I would be nice to get
eventually to a form where anyone could write in words what they
required; perhaps when chicken foot's reg exp parser comes up with
this ;)
I personally hate to see the type of hard coded stuff that gets banged
out, but it exists in the real world - of course.
You just don't get it, do you. The DB Structure is not important to the
client. The DB CONTENTS ARE!

For instance - in the case of an order entry system. Does the user want :

order_number product_number quantity

Or do they want:

Customer name
Order_number product_name quantity Price Total_Price

PhPMyAdmin is for administering a MySQL database. The user isn't
interested in the administration of the database. He/she is interested
in the contents. And not just one table, like above. Rather, he's
interested in the joining of at least three tables - maybe more.

Sure, I rewrite code each time I start a new project with a new
database. That's because every database is unique and has unique
requirements.

What you think would be nice really isn't realistic, other than for
simple database admin like PhPMyAdmin.

Programming is all about reinventing the wheel. For instance, almost
every PHP statement has been written at least once. Sure, the variable
names change, but that's about it. But it's how you put the statements
together that counts.

Same with databases. It's not about the access. And it's not about
database design.

It's about how things fit together to provide data in a format a person
can use.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================

I think you have missed the point again Jerry; although I would say
that database design and access can be very important for large
projects for optimisation. I am only building on this exact point:
Nope, I didn't miss the point at all. The same is true if you only have
a dozen columns across two tables.
>It's about how things fit together to provide data in a format a person can use.

the rest is just a given. You are cross at someone but it isn't me.
Who say's I'm cross? I am getting tired of people claiming to be
programmers who keep coming up with this garbage.
It can only be reiterated: although coding is about reinventing the
wheel, this is pointless, and will change into the future, becoming
more high level and looking and feeling less like C.
Finally resulting in code that looks like a sentence, and compiles to
be equivalent to today's stuff. Until the compilers get cleverer, the
wheel reinvention problem can be solved using clever code.
I've been hearing that "will change in the future" for the 40 years I've
been programming. Hasn't happened yet, and isn't going to happen in the
near future. Only the languages, architectures and tools change. But
we're still writing code must like we did 40 years ago.

And COBOL was the try to get code that "looks like a sentence". That
was around even when I was programming in the late 60's. Nothing new.
Your point
>The DB Structure is not important to the client. The DB CONTENTS ARE!
can be widened, the client doesn't care about anything except
functionality on time to budget.
true but that implies fast writing of code, with less skills required
to write it and greater ease of maintainability. One of SQLs great
pluses is that it's not that hard to learn and it can read like a
sentence at the basic level.
The same can and will be true of a scripting lang like php.
The upshot is writing code independent of DB structure, independent of
markup requirements, which takes a config file, rather like Ant builds
an application, means less stress for you - the over worked wheel
reinventor, and less stress for the client, who likes rapid app dev.
No, that means writing code efficiently. And generally it takes MORE
skills. Less skill means the code will not be as "clean" and will take
longer to write. The result is virtually always a higher cost to the
client.

You really don't understand a lot about programming in the real world.
That's very obvious.
I dunno where we are arguing, unless your 20+yrs has blinded you to
the possibility of a world where Joe Bloggs back office boy can
program because Joe Blogg's dad the guru made a compiler that
understood english.
Try 40 years of programming. And sure, Joe Blogg can throw together
code. I get big bucks straightening it out when he completely screws
things up.
What got my goat was that printing statements out in googlicate was
just the kind of thing that causes problems into the future, while it
might compile to something similar to a judiciously chosen while loop,
it just feels rather intellectually lazy, no offence intended.
Or completely ignorant. Take your pick.
In the same way people argued against calculators I guess you can
still disagree. Calculators let anyone leapfrog the grunt work, and
start with the interesting Maths. The metphor is writing code once
that then let's the programmer get on with writing the app, rather
than reinventing the wheel and grinding out lines of the same old
code. Not everyone loves the destination as much as they do the
journey. oo deep
Sure. And a roller will make painting must faster. So why didn't
Rembrandt use a roller?

Programming is grunt work. Good programming is creative.

Try a few years in a real programming job. Find out what it's really
like. Right now you talk like a teenager who has read a PHP book and
scanned a SQL book. But never done any real-world programming. Some
hobby, maybe. But that's it.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Mar 26 '07 #14
On 26 Mar, 03:29, Jerry Stuckle <jstuck...@attglobal.netwrote:
shimmyshack wrote:
On 26 Mar, 02:33, Jerry Stuckle <jstuck...@attglobal.netwrote:
shimmyshack wrote:
On 25 Mar, 23:37, Jerry Stuckle <jstuck...@attglobal.netwrote:
shimmyshack wrote:
On 25 Mar, 21:37, Mary Pegg <inva...@invalid.comwrote:
shimmyshack wrote:
>if (isset($c['s']['a5'])) echo htmlentities($c['s']['a1'])."<br>";
>.
>.
>.
>if (isset($c['s']['a5'])) echo htmlentities($c['s']['a5'])."<br>";
>that's alot of work for sake of sticking with what _you_ find more
>readable
So what you're really arguing in favour of is wrapping it up in a
function, which is what I've done. But the question is whether it's
worth creating a for loop to run through a1 to a5 rather than simply
calling each by name.
>all the chages above and more are so simple with Rani's method. If you
No, they're simple if it's wrapped up in a function. Whether or not
a1 to a5 get generated by a for loop I've still got b, c, d, e, f (etc)
to deal with. NB I'm using these as symbols - in reality they are the
field names from a database, so no getting smart and suggesting that I
can generate b to f automagically. OTOH I could stick the field names
in an array and step through the array. This might be worth doing.
>can't take good advice don't ask for it.
I know this is Usenet but you don't *have* to be rude and abrasive.
--
"Checking identity papers is a complete waste of time. If anyone can
be counted on to have valid papers, it will be the terrorists".
it's not rude or abrasive, to notice you don't take advice and say so,
perhaps a little bruusque though, and I apologise if I made you cross.
FYI, I work with annoyingly complex database tables whose structure
changes as my client changes their requirements, to stop this kind of
hard coded approach which started to cost me too much time, I use
DESCRIBE `tablename`, and SHOW FULL COLUMNS FROM `tablename` which can
then be used to get the comments, fieldnames etc... then using a reg
exp on bool enum varchar() int() and so on to get metadata about the
table which is then pumped into the application.
In this way you can use general methods to print and parse data
without ever having to hard code the fieldnames, you can use it to
dynamically generate forms etc...
Instead of repeatedly writing code to format output from the DB, you
just need a vlid link, and some form of instructions what your db
connection is to "get" and "output" and finally the output format -
preventing too much or too little from being drawn from the DB. You
only have to code this once, and after than it can be used everywhere
you need output. It might seem a little extreme to folks, I don't
know, but I find this approach saves time. The class which serves html
markup can end up being very complex but you can control things with a
couple of calls and an array.
PMJI, but then you aren't much of a programmer.
I've been doing SQL Database work for over 20 years now. I'll bet some
of the databases I've designed would make yours look puny - over 100
tables, over 1,500 columns, for instance. And mostly 3rd normal form.
And yes, these databases do change as customer requirements change. But
I deal with them.
Your problem is that the user actually *cares* about the contents of the
database. They don't. What they do care about is the *data* -
including the relationships. Whether data is contained in one table or
ten is not important.
You can give all the excuses you want for not taking good advice. But
the bottom line is - you haven't given any excuses we haven't heard
hundreds of times. And you aren't explaining a situation most of us
haven't run into multiple times. And we deal with it properly.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================
I'm not sure what to make of that Jerry, but I wonder if my point was
clear enough. The idea is to write php classes which auto discover DB
structure, as does say phpmyadmin. The idea is to let the DB structure
be _independent_ of the php code, responding to changes within the DB
such as character encoding, field types, number of columns etc... so
that little or no hard coding and adjusting of the logic is needed,
just an adjustment - if any - to the "display" if one can call it that
- to config that prescribes the way the code interacts with the DB
tables.
I don't then mind how often changes are made to the DB structure,
which as you say always changes as the project grows and the
relationships become clearer, nor do I mind how often the tables are
split (pi$$ing contest avoided), provided a there exists a
data<~>query map.
ALways with programming it's bread and butter, reinventing the wheel
for each new app (even with OO)
forming the query, running it, getting the data, persisting it,
parsing, filtering, displaying and so on...
I wanted something a bit more like a fluent interface, more readable
and "semantic", in that it moves things on from having to write step
by step, and makes things a bit more fluid. I would be nice to get
eventually to a form where anyone could write in words what they
required; perhaps when chicken foot's reg exp parser comes up with
this ;)
I personally hate to see the type of hard coded stuff that gets banged
out, but it exists in the real world - of course.
You just don't get it, do you. The DB Structure is not important to the
client. The DB CONTENTS ARE!
For instance - in the case of an order entry system. Does the user want :
order_number product_number quantity
Or do they want:
Customer name
Order_number product_name quantity Price Total_Price
PhPMyAdmin is for administering a MySQL database. The user isn't
interested in the administration of the database. He/she is interested
in the contents. And not just one table, like above. Rather, he's
interested in the joining of at least three tables - maybe more.
Sure, I rewrite code each time I start a new project with a new
database. That's because every database is unique and has unique
requirements.
What you think would be nice really isn't realistic, other than for
simple database admin like PhPMyAdmin.
Programming is all about reinventing the wheel. For instance, almost
every PHP statement has been written at least once. Sure, the variable
names change, but that's about it. But it's how you put the statements
together that counts.
Same with databases. It's not about the access. And it's not about
database design.
It's about how things fit together to provide data in a format a person
can use.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================
I think you have missed the point again Jerry; although I would say
that database design and access can be very important for large
projects for optimisation. I am only building on this exact point:

Nope, I didn't miss the point at all. The same is true if you only have
a dozen columns across two tables.
It's about how things fit together to provide data in a format a person can use.
the rest is just a given. You are cross at someone but it isn't me.

Who say's I'm cross? I am getting tired of people claiming to be
programmers who keep coming up with this garbage.
It can only be reiterated: although coding is about reinventing the
wheel, this is pointless, and will change into the future, becoming
more high level and looking and feeling less like C.
Finally resulting in code that looks like a sentence, and compiles to
be equivalent to today's stuff. Until the compilers get cleverer, the
wheel reinvention problem can be solved using clever code.

I've been hearing that "will change in the future" for the 40 years I've
been programming. Hasn't happened yet, and isn't going to happen in the
near future. Only the languages, architectures and tools change. But
we're still writing code must like we did 40 years ago.

And COBOL was the try to get code that "looks like a sentence". That
was around even when I was programming in the late 60's. Nothing new.
Your point
The DB Structure is not important to the client. The DB CONTENTS ARE!
can be widened, the client doesn't care about anything except
functionality on time to budget.
true but that implies fast writing of code, with less skills required
to write it and greater ease of maintainability. One of SQLs great
pluses is that it's not that hard to learn and it can read like a
sentence at the basic level.
The same can and will be true of a scripting lang like php.
The upshot is writing code independent of DB structure, independent of
markup requirements, which takes a config file, rather like Ant builds
an application, means less stress for you - the over worked wheel
reinventor, and less stress for the client, who likes rapid app dev.

No, that means writing code efficiently. And generally it takes MORE
skills. Less skill means the code will not be as "clean" and will take
longer to write. The result is virtually always a higher cost to the
client.

You really don't understand a lot about programming in the real world.
That's very obvious.
I dunno where we are arguing, unless your 20+yrs has blinded you to
the possibility of a world where Joe Bloggs back office boy can
program because Joe Blogg's dad the guru made a compiler that
understood english.

Try 40 years of programming. And sure, Joe Blogg can throw together
code. I get big bucks straightening it out when he completely screws
things up.
What got my goat was that printing statements out in googlicate was
just the kind of thing that causes problems into the future, while it
might compile to something similar to a judiciously chosen while loop,
it just feels rather intellectually lazy, no offence intended.

Or completely ignorant. Take your pick.
In the same way people argued against calculators I guess you can
still disagree. Calculators let anyone leapfrog the grunt work, and
start with the interesting Maths. The metphor is writing code once
that then let's the programmer get on with writing the app, rather
than reinventing the wheel and grinding out lines of the same old
code. Not everyone loves the destination as much as they do the
journey. oo deep

Sure. And a roller will make painting must faster. So why didn't
Rembrandt use a roller?

Programming is grunt work. Good programming is creative.

Try a few years in a real programming job. Find out what it's really
like. Right now you talk like a teenager who has read a PHP book and
scanned a SQL book. But never done any real-world programming. Some
hobby, maybe. But that's it.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================
I just missed out on the delights of Pascal, and didn't dip my toe
(which weighs as much as a duck) into the programming pool 'til 2002,
I guess that confirms your opinion of me. I think Newton would have
loved a calculator. Babbage wrote an essay on faulty log tables - many
wasted months were had by all those brilliant astonomers (and their
wives and servants) - those wrong predictions set back science on the
back of scoffers. It's tools fit for the job, Rembramdt
notwithstanding. Architecture has brought us from the wattle&daub of
punch cards to the body-heated house. What we (I hasten to apologise
for lumping you in with me) do day to day is extremely simple, and
appropriate tools are around now, I mentioned one which I love,
Chickenfoot+Solvent+PiggyBank, which allows my (technophobic) clients
to mash up websites they use and fix the results in databases I
provide them,their coding being pidgeon english, which a hard core
javascript programmer would spend a long time coding,
document.getElementById this that and the other, grabbing postback,
blah, standing on the shoulders of historical giants to acheive what
no amount of COBOL could ever do, without making mad those who
struggled with it, although I guess you had to be there.

Mar 26 '07 #15
shimmyshack wrote:
On 26 Mar, 03:29, Jerry Stuckle <jstuck...@attglobal.netwrote:
>shimmyshack wrote:
>>On 26 Mar, 02:33, Jerry Stuckle <jstuck...@attglobal.netwrote:
shimmyshack wrote:
On 25 Mar, 23:37, Jerry Stuckle <jstuck...@attglobal.netwrote:
>shimmyshack wrote:
>>On 25 Mar, 21:37, Mary Pegg <inva...@invalid.comwrote:
>>>shimmyshack wrote:
>>>>if (isset($c['s']['a5'])) echo htmlentities($c['s']['a1'])."<br>";
>>>>.
>>>>.
>>>>.
>>>>if (isset($c['s']['a5'])) echo htmlentities($c['s']['a5'])."<br>";
>>>>that's alot of work for sake of sticking with what _you_ find more
>>>>readable
>>>So what you're really arguing in favour of is wrapping it up in a
>>>function, which is what I've done. But the question is whether it's
>>>worth creating a for loop to run through a1 to a5 rather than simply
>>>calling each by name.
>>>>all the chages above and more are so simple with Rani's method. If you
>>>No, they're simple if it's wrapped up in a function. Whether or not
>>>a1 to a5 get generated by a for loop I've still got b, c, d, e, f (etc)
>>>to deal with. NB I'm using these as symbols - in reality they are the
>>>field names from a database, so no getting smart and suggesting that I
>>>can generate b to f automagically. OTOH I could stick the field names
>>>in an array and step through the array. This might be worth doing.
>>>>can't take good advice don't ask for it.
>>>I know this is Usenet but you don't *have* to be rude and abrasive.
>>>--
>>>"Checking identity papers is a complete waste of time. If anyone can
>>>be counted on to have valid papers, it will be the terrorists".
>>it's not rude or abrasive, to notice you don't take advice and say so,
>>perhaps a little bruusque though, and I apologise if I made you cross.
>>FYI, I work with annoyingly complex database tables whose structure
>>changes as my client changes their requirements, to stop this kind of
>>hard coded approach which started to cost me too much time, I use
>>DESCRIBE `tablename`, and SHOW FULL COLUMNS FROM `tablename` which can
>>then be used to get the comments, fieldnames etc... then using a reg
>>exp on bool enum varchar() int() and so on to get metadata about the
>>table which is then pumped into the application.
>>In this way you can use general methods to print and parse data
>>without ever having to hard code the fieldnames, you can use it to
>>dynamically generate forms etc...
>>Instead of repeatedly writing code to format output from the DB, you
>>just need a vlid link, and some form of instructions what your db
>>connection is to "get" and "output" and finally the output format -
>>preventing too much or too little from being drawn from the DB. You
>>only have to code this once, and after than it can be used everywhere
>>you need output. It might seem a little extreme to folks, I don't
>>know, but I find this approach saves time. The class which serves html
>>markup can end up being very complex but you can control things with a
>>couple of calls and an array.
>PMJI, but then you aren't much of a programmer.
>I've been doing SQL Database work for over 20 years now. I'll bet some
>of the databases I've designed would make yours look puny - over 100
>tables, over 1,500 columns, for instance. And mostly 3rd normal form.
>And yes, these databases do change as customer requirements change. But
>I deal with them.
>Your problem is that the user actually *cares* about the contents of the
>database. They don't. What they do care about is the *data* -
>including the relationships. Whether data is contained in one table or
>ten is not important.
>You can give all the excuses you want for not taking good advice. But
>the bottom line is - you haven't given any excuses we haven't heard
>hundreds of times. And you aren't explaining a situation most of us
>haven't run into multiple times. And we deal with it properly.
>--
>==================
>Remove the "x" from my email address
>Jerry Stuckle
>JDS Computer Training Corp.
>jstuck...@attglobal.net
>==================
I'm not sure what to make of that Jerry, but I wonder if my point was
clear enough. The idea is to write php classes which auto discover DB
structure, as does say phpmyadmin. The idea is to let the DB structure
be _independent_ of the php code, responding to changes within the DB
such as character encoding, field types, number of columns etc... so
that little or no hard coding and adjusting of the logic is needed,
just an adjustment - if any - to the "display" if one can call it that
- to config that prescribes the way the code interacts with the DB
tables.
I don't then mind how often changes are made to the DB structure,
which as you say always changes as the project grows and the
relationships become clearer, nor do I mind how often the tables are
split (pi$$ing contest avoided), provided a there exists a
data<~>query map.
ALways with programming it's bread and butter, reinventing the wheel
for each new app (even with OO)
forming the query, running it, getting the data, persisting it,
parsing, filtering, displaying and so on...
I wanted something a bit more like a fluent interface, more readable
and "semantic", in that it moves things on from having to write step
by step, and makes things a bit more fluid. I would be nice to get
eventually to a form where anyone could write in words what they
required; perhaps when chicken foot's reg exp parser comes up with
this ;)
I personally hate to see the type of hard coded stuff that gets banged
out, but it exists in the real world - of course.
You just don't get it, do you. The DB Structure is not important to the
client. The DB CONTENTS ARE!
For instance - in the case of an order entry system. Does the user want :
order_number product_number quantity
Or do they want:
Customer name
Order_number product_name quantity Price Total_Price
PhPMyAdmin is for administering a MySQL database. The user isn't
interested in the administration of the database. He/she is interested
in the contents. And not just one table, like above. Rather, he's
interested in the joining of at least three tables - maybe more.
Sure, I rewrite code each time I start a new project with a new
database. That's because every database is unique and has unique
requirements.
What you think would be nice really isn't realistic, other than for
simple database admin like PhPMyAdmin.
Programming is all about reinventing the wheel. For instance, almost
every PHP statement has been written at least once. Sure, the variable
names change, but that's about it. But it's how you put the statements
together that counts.
Same with databases. It's not about the access. And it's not about
database design.
It's about how things fit together to provide data in a format a person
can use.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================
I think you have missed the point again Jerry; although I would say
that database design and access can be very important for large
projects for optimisation. I am only building on this exact point:
Nope, I didn't miss the point at all. The same is true if you only have
a dozen columns across two tables.
>>>It's about how things fit together to provide data in a format a person can use.
the rest is just a given. You are cross at someone but it isn't me.
Who say's I'm cross? I am getting tired of people claiming to be
programmers who keep coming up with this garbage.
>>It can only be reiterated: although coding is about reinventing the
wheel, this is pointless, and will change into the future, becoming
more high level and looking and feeling less like C.
Finally resulting in code that looks like a sentence, and compiles to
be equivalent to today's stuff. Until the compilers get cleverer, the
wheel reinvention problem can be solved using clever code.
I've been hearing that "will change in the future" for the 40 years I've
been programming. Hasn't happened yet, and isn't going to happen in the
near future. Only the languages, architectures and tools change. But
we're still writing code must like we did 40 years ago.

And COBOL was the try to get code that "looks like a sentence". That
was around even when I was programming in the late 60's. Nothing new.
>>Your point
The DB Structure is not important to the client. The DB CONTENTS ARE!
can be widened, the client doesn't care about anything except
functionality on time to budget.
true but that implies fast writing of code, with less skills required
to write it and greater ease of maintainability. One of SQLs great
pluses is that it's not that hard to learn and it can read like a
sentence at the basic level.
The same can and will be true of a scripting lang like php.
The upshot is writing code independent of DB structure, independent of
markup requirements, which takes a config file, rather like Ant builds
an application, means less stress for you - the over worked wheel
reinventor, and less stress for the client, who likes rapid app dev.
No, that means writing code efficiently. And generally it takes MORE
skills. Less skill means the code will not be as "clean" and will take
longer to write. The result is virtually always a higher cost to the
client.

You really don't understand a lot about programming in the real world.
That's very obvious.
>>I dunno where we are arguing, unless your 20+yrs has blinded you to
the possibility of a world where Joe Bloggs back office boy can
program because Joe Blogg's dad the guru made a compiler that
understood english.
Try 40 years of programming. And sure, Joe Blogg can throw together
code. I get big bucks straightening it out when he completely screws
things up.
>>What got my goat was that printing statements out in googlicate was
just the kind of thing that causes problems into the future, while it
might compile to something similar to a judiciously chosen while loop,
it just feels rather intellectually lazy, no offence intended.
Or completely ignorant. Take your pick.
>>In the same way people argued against calculators I guess you can
still disagree. Calculators let anyone leapfrog the grunt work, and
start with the interesting Maths. The metphor is writing code once
that then let's the programmer get on with writing the app, rather
than reinventing the wheel and grinding out lines of the same old
code. Not everyone loves the destination as much as they do the
journey. oo deep
Sure. And a roller will make painting must faster. So why didn't
Rembrandt use a roller?

Programming is grunt work. Good programming is creative.

Try a few years in a real programming job. Find out what it's really
like. Right now you talk like a teenager who has read a PHP book and
scanned a SQL book. But never done any real-world programming. Some
hobby, maybe. But that's it.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================

I just missed out on the delights of Pascal, and didn't dip my toe
(which weighs as much as a duck) into the programming pool 'til 2002,
I guess that confirms your opinion of me. I think Newton would have
loved a calculator. Babbage wrote an essay on faulty log tables - many
wasted months were had by all those brilliant astonomers (and their
wives and servants) - those wrong predictions set back science on the
back of scoffers. It's tools fit for the job, Rembramdt
notwithstanding. Architecture has brought us from the wattle&daub of
punch cards to the body-heated house. What we (I hasten to apologise
for lumping you in with me) do day to day is extremely simple, and
appropriate tools are around now, I mentioned one which I love,
Chickenfoot+Solvent+PiggyBank, which allows my (technophobic) clients
to mash up websites they use and fix the results in databases I
provide them,their coding being pidgeon english, which a hard core
javascript programmer would spend a long time coding,
document.getElementById this that and the other, grabbing postback,
blah, standing on the shoulders of historical giants to acheive what
no amount of COBOL could ever do, without making mad those who
struggled with it, although I guess you had to be there.
Please don't understand - I don't think negatively of your abilities,
but I do think you're a bit naive.

Calculators for building log tables are one thing. But that's not
nearly the same as a generic program for displaying information from a
SQL database. And neither is anywhere close to English language
statements to describe programs.

And sure, the tools are very easy to use. So is a paint brush. So does
that mean everyone can be a master painter?

And yes, I've seen sites which are being updated by clients. It's not
hard at all to determine if a professional or a wanna-be has been doing
the updating, even with just the HTML/javascript.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Mar 26 '07 #16
I think we might be getting somewhere
Please don't understand - I don't think negatively of your abilities,
but I do think you're a bit naive.
as you wish, it's fine both ways
>
Calculators for building log tables are one thing. But that's not
nearly the same as a generic program for displaying information from a
SQL database.
that's not actually what I am doing at all, it's more like a program
for displaying the generic info from a database.
And neither is anywhere close to English language statements to describe programs.
that's correct given the above proviso
And sure, the tools are very easy to use. So is a paint brush. So does
that mean everyone can be a master painter?
did I mention tools? I said what we do is easy. The fact is that
reinventing the wheel is easy because the wheel is there as
inspiration, and because it's an everyday druge for so many, it gains
the status of a social norm, there's no need to justify doing it, as
everyone agrees is ok to be doing it, that won't change until the
usual paradign shift shows everyone to be wrong. We're basically
sheep.
>
And yes, I've seen sites which are being updated by clients. It's not
hard at all to determine if a professional or a wanna-be has been doing
the updating, even with just the HTML/javascript.
Ah, now here's where you've been hoisted by your own proverbial. The
clients don't update the /site/, they use tools we provide to update
the data, because that's what they care about, know more about and are
better at doing semantically than us modellers.

perhaps we need to agree to differ; although I will generally defer to
experience and age anyway, so yours is the wreath of laurel :)

prov 26,17
>
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================

Mar 26 '07 #17
shimmyshack wrote:
What got my goat was that printing statements out in googlicate was
just the kind of thing that causes problems into the future, while it
might compile to something similar to a judiciously chosen while loop,
it just feels rather intellectually lazy, no offence intended.
I refer you to the subject line.

--
"Checking identity papers is a complete waste of time. If anyone can
be counted on to have valid papers, it will be the terrorists".
Mar 26 '07 #18
shimmyshack wrote:
I think we might be getting somewhere
>Please don't understand - I don't think negatively of your abilities,
but I do think you're a bit naive.
as you wish, it's fine both ways
>Calculators for building log tables are one thing. But that's not
nearly the same as a generic program for displaying information from a
SQL database.

that's not actually what I am doing at all, it's more like a program
for displaying the generic info from a database.
>And neither is anywhere close to English language statements to describe programs.

that's correct given the above proviso
>And sure, the tools are very easy to use. So is a paint brush. So does
that mean everyone can be a master painter?

did I mention tools? I said what we do is easy. The fact is that
reinventing the wheel is easy because the wheel is there as
inspiration, and because it's an everyday druge for so many, it gains
the status of a social norm, there's no need to justify doing it, as
everyone agrees is ok to be doing it, that won't change until the
usual paradign shift shows everyone to be wrong. We're basically
sheep.
But programming is an art, and the programming language is a tool. Even
HTML is a tool.

A painter uses the same set of brush strokes on every painting. But the
combination of the brush strokes, colors and technique make the
difference between a master and an amateur.

And don't you think the master reinvents the wheel every time? Sure he
does. And it's a drudge for him, too, I would expect.

It's not the 'social norm' - it's the way things are nowadays. We
haven't got the Star Trek computers yet. So we sit down and write code.

There have been tools for years to help things along. Code generators,
tool boxes and the like. But nothing has stopped the "drudge work", as
you call it. And I disagree that we are basically sheep. We do what we
need to do to get the job done.
>And yes, I've seen sites which are being updated by clients. It's not
hard at all to determine if a professional or a wanna-be has been doing
the updating, even with just the HTML/javascript.

Ah, now here's where you've been hoisted by your own proverbial. The
clients don't update the /site/, they use tools we provide to update
the data, because that's what they care about, know more about and are
better at doing semantically than us modellers.
OK, I provide tools to update the data, also. But my tools completely
hide the underlying database. The user has absolutely no idea what's
going on there. Rather, the tools to update the data are in a form that
is natural for the job at hand - and NOT based on the underlying database.

PhPBBS is a great example of that (not I'm not saying it's the best BBS
- just an example of hiding the database structure). There is nothing
in any of the windows that exposes the underlying database. Everything
is done by the person in a natural way.
perhaps we need to agree to differ; although I will generally defer to
experience and age anyway, so yours is the wreath of laurel :)
As I said before - I've seen a lot of good ideas come and go. But
nothing has replaced the drudge work in the long term. Computers and
languages just haven't gotten there yet.
prov 26,17
>--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================



--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Mar 26 '07 #19
Jerry Stuckle wrote:
But programming is an art, and the programming language is a tool. Even
HTML is a tool.

A painter uses the same set of brush strokes on every painting. But the
combination of the brush strokes, colors and technique make the
difference between a master and an amateur.
Actually - the ability to sell themselves is the difference.
Lots of amateurs do great work.

And don't you think the master reinvents the wheel every time? Sure he
does. And it's a drudge for him, too, I would expect.
It's not a drudge.
Any copycat can use other people's wheels.
Only a master can create a newer, better wheel.
Mar 26 '07 #20

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

36 posts views Thread by Andrea Griffini | last post: by
6 posts views Thread by Michael | last post: by
43 posts views Thread by Rob R. Ainscough | last post: by
3 posts views Thread by baibaichen | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by Marin | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.