Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #5679

Re: Dynamic form generation

Show key headers only | View raw

"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
news:jn15dt$gjl$1@dont-email.me...
> On 4/22/2012 5:27 AM, Tony Marston wrote:
>> "Jerry Stuckle" wrote in message news:jmu1nc$fui$1@dont-email.me...
>>>
>>> On 4/21/2012 5:35 AM, Tony Marston wrote:
>> <snip>
>>> From your description, any good programmer can tell your code is crap.
>>> Only those like yourself can't see crap when it's described.
>>
>> Your definition of crap code seems to be nothing more than "it doesn't
>> follow my rules, therefore it must be crap".
>>
>
> My definition of crap code is that "it is bloated, overly complicated and 
> doesn't follow generally recognized rules".  IOW, everything you've shown 
> your code to be.

You call my code bloated because I have included the option to change the 
password validation rules by changing values on a screen whereas you have to 
change the code. My method may have taken slightly longer to code, but it 
also means that changes are easier to implement.

You call my code overly complicated because it has a pre-written validation 
class whereas to have to write code to validate each piece of user input.

You say that my code does not follow "generally recognized rules" for no 
other reason that the rules which it *DOES* follow are not the same as 
yours. There is no single set of rules that is universally folowed by all 
programmers, so I follow the rules which I consider to be the most 
appropriate.

>>> Yea, right. And what is the experience of those programmers? PHP
>>> programmers as a whole are not known for their intelligence or
>>> competence. In fact, just the opposite is true.
>>
>> So, as this is a newsgroup for PHP programmers you are effectively
>> saying that every member of this group is stupid and incompetent? Do you
>> know how arrogant that makes you sound?
>>
>
> No, you're putting words in my mouth (again).

No I'm not. Your exact words were, and I quote: "PHP programmers as a whole 
are not known for their intelligence or  competence. In fact, just the 
opposite is true." The phrase "as a whole" tends to encompass the entire PHP 
programming fraternity, not just a select few.

> I'm not saying every member of this group is stupid or incompetent.  There 
> are a number of people here who are quite intelligent and competent, whose 
> opinions I regard highly.

Only those who dare not disagree with anything you say. I am the 
founder-member of the "I disagree with everything that Jerry Stuckle says" 
society, so I don't think I'm in that group. Ask me if I care!

<snip>
>>> What do you think a setter is if it's not a method? And you never have
>>> answered how the programmer can change one property without building a
>>> whole array. Or get a single property?
>>
>> The table data already exists in the object as an array, so the
>> programmer can examine or change the contents of the array at will. The
>> programmer does not have to build the array, it is already there! Why
>> can't you understand such a simple concept?
>
> Yes, you've already said you don't understand one of the basic principles 
> of OO programming - encapsulation.

Encapsulation has nothing to do with information hiding, only implementation 
hiding. Encapsulation does not require te use of getters and setters.

>>> Also, the presence of set/get methods does not preclude the parsing of
>>> arrays. I have both, for instance.
>>>
>>>>> If you understood even the very basics of OO programming (one of which
>>>>> is encapsulation), you would know why they are needed.
>>>>
>>>> Getters and setters are NOT required for encapsulation. Encapsulation
>>>> means *implementation* hiding, not *information* hiding.
>>>>
>>>
>>> Yes, and the properties of the class (i.e. variables) are part of the
>>> implementation.
>>
>> Implementation means code, not data.
>
> That's where you don't understand even basic OO.  Implementation means 
> both code and data.

No it does not. On the subject of "Encapsulation is not data hiding" take a 
look at the following articles:

http://www.javaworld.com/javaworld/jw-05-2001/jw-0518-encapsulation.html
http://www.itmweb.com/essay550.htm
http://homepage.mac.com/keithray/blog/2006/02/22/

<snip>
>> My framework generates less code than yours because it uses more
>> generalised functions. I don't use the copy paste method that you seem
>> to favour.
>
> Your framework generates less code because it's only a half-assed 
> implementation of even basic OO principles (which you have repeatedly 
> shown you don't understand).

My framework is an implementation of MY understanding of the principles of 
OOP just as your framework is an implementation of YOUR understanding of the 
same principles. When you consider the fact that there is no universal 
agreement on what "Object Oriented Programming" actually means then it is 
not surprising that two individuals have a totally different understanding. 
Yet I am not the one who is saying that *MY* understanding is the only 
opinion worth having.

Take a look at these articles to see if you can identify a definition of OOP 
with is universally accepted:

http://c2.com/cgi/wiki?DefinitionsForOo
http://c2.com/cgi/wiki?NobodyAgreesOnWhatOoIs
http://www.devx.com/opinion/Article/26776
http://www.geocities.com/tablizer/oopbad.htm
http://www.geocities.com/tablizer/whypr.htm
http://www.geocities.com/tablizer/core1.htm
http://www.geocities.com/tablizer/beyondhw.htm
http://c2.com/cgi/wiki?ArgumentsAgainstOop
http://c2.com/cgi/wiki?ObjectOrientationIsDead
http://c2.com/cgi/wiki?ObjectOrientationIsaHoax
http://dreamsongs.com/ObjectsHaveFailedNarrative.html
http://www.eetimes.com/design/embedded/4216597/Nuts-to-OOP
http://c2.com/cgi/wiki?ObjectOrientedForDummies

>>> But less code can mean MORE complexity. However, you've never worked
>>> on anything non-trivial, so you wouldn't understand.
>>
>> How can less code be more complex?
>
> Again, it shows how little you know.  Just because there code is smaller 
> does not mean it's easier to understand.  Sometimes it's better to add 
> code to make it more understandable.

I agree that several lines of simple code is easier to understand than one 
line of complex code, which is why I like to keep my code as simple as 
possible. Yet you seem to object that it is "too simple".

>> <snip>
>>>> Take a look at the definition of "ERP" at
>>>> http://en.wikipedia.org/wiki/Enterprise_resource_planning and tell me
>>>> I'm wrong. I don't have all the modules listed there, but SME's don't
>>>> need all those modules.
>>>
>>> I suggest you read it. An ERP system HAS all the modules. You can't
>>> pick and choose. It's an integrated system.
>>
>> If you read the definition properly you will see that it is a set of
>> integrated modules, and not all users require all modules. My ERP system
>> does much more than deal with just sales orders. It does what my users
>> want, and I care more for their opinion than I do yours.
>>
>
> No, not all users require all modules.  However, all ERP systems PROVIDE 
> all modules.

I don't provide modules that have not been requested.

I started off by calling it an order processing system, but my first 
customer insisted that it was much more than. So if a paying customer says 
that it is an ERP system why should I accept your definition?

 <snip>
>>>> No I don't. You told me yourself that you regularly cut, paste and
>>>> modify code. I don't need to do that as the code is defined once in a
>>>> reusable function.
>>>
>>> Exactly. But that's not duplicated code. It's starting with a code
>>> template and modifying it to suit my needs. That way you don't need to
>>> start from scratch every time.
>>
>> If you were really competent you would create a version of that code
>> template that could be reused as a single function instead of having to
>> be copied and modified multiple times.
>
> And you've just proved that once again you have no idea what you're 
> talking about.
>
> A good example - a table with 25 columns.  Most are text/numeric, but one 
> is a 20MB BLOB.
>
> In one form you want to display all columns in a two column table 
> (label/value). This one is easy.
>
> In a second case you want to display 10-16 of those columns in a 4-column 
> table; 6 columns will be displayed or not based on values in other 
> columns.  1 (the BLOB) will be displayed if it is not null.
>
> In the third case, you want to display 5 columns in a 5 column table row 
> (only).  You do not want to retrieve the BLOB column as it is unnecessary 
> overhead (bloat).
>
> Let's see your template do that.

The number of columns which are retrieved from the database is not 
controlled by the template. By default all columns are retrieved, but the 
defaults can be changed whenever needed.

>> <snip>
>>>> An application can be described as "complex" by looking at the volume 
>>>> of
>>>> business rules which have to be implemented. Using the Radicore
>>>> framework I can quickly generate working transactions which already
>>>> handle the boring work of moving data between the database and the user
>>>> interface, which leaves maximum time to spend on the payload, the
>>>> business rules.
>>>>
>>>
>>> You can claim that for your simple database applications. But then you
>>> need to do that to satisfy yourself you're working on "complex"
>>> applications. Those of us who have worked on truly complex
>>> applications know better.
>>
>> A complex application has complex business rules. A simple application
>> has simple business rules. The number of lines of code is irrelevant. If
>> I can take an application that uses 3M LOC and achieve the same result
>> using half as many LOC would that automatically make my version half as
>> complex? I think not.
>>
>
> In your universe, yes.  Anyone who has worked on truly complex 
> applications knows better.   But people who only do simple database 
> applications think a few rules make something complex.  I hate to burst 
> your balloon, but it doesn't.  You can keep deluding yourself, though.

While I agree that an application which does nothing more than move data 
between the database and the user interface and does not have any business 
rules to process is a simple application, it is naive to say that the 
addition of a large number of complex rules does not turn it into a more 
complex application.

Using my framework all the simple stuff can be done without writing any 
code, but the complicated stuff, the processing of business rules, requires 
the programmer to actually add code to the relevant classes. It is the 
volume of code which the programmer has to add to the framework-generated 
code which adds to its complexity.

Just because you think that a database application cannot possibly be 
complicated does not make it so.

>>> So? You've claimed you've worked on "database applications for
>>> decades". That's long before PHP existed. You opened the door. Now
>>> you're backpedaling. Typical.
>>
>> I am not back pedalling. This newsgroup is for people who write database
>> applications in PHP, so comments about writing operating systems or
>> compilers are irrelevant.
>
> You are back-pedalling.  This is not a database newsgroup, nor is it a 
> newsgroup for people who write database applications.  You brought up 
> databases, not me.

If you bother looking at what the OP wrote he wanted a way to generate an 
HTML form from a MySQL table structure. That is why I am talking about 
databases in this post.

>> Before I starting writing database applications with PHP I wrote
>> database applications with a variety of other languages. That shows that
>> my experience of writing database applications has not been confined to
>> the PHP language. Tellme how that is back pedalling?
>>
>
> All database applications.  Trivial to anyone who's ever worked on truly 
> complex applications.  You brought up an irrelevant subject, and now 
> you're back-pedaling because I pointed out the fallacy in your argument.
>
> The fact is all you've EVER done is simple database applications.  You 
> have no idea what a complicated application is.

I shan't bother replying to such a pathetic statement.

>>>> Applications which are NOT web applications and NOT written in PHP are
>>>> irrelevant.
>>>
>>> Only because all you do are trivial applications in PHP - and you do
>>> it poorly, at that.
>>>
>>>>> Even DOS 1.0 was more complex than anything you've written.
>>>>
>>>> DOS is not a web application written in PHP, so it's irrelevant.
>>>
>>> Nope, and neither were the "decades of database applications" you
>>> claimed to have written in the very post I'm replying to.
>>
>> The fact that my experience with other languages meant that I wrote
>> database applications for the desktop does not mean that it is totally
>> irrelevant when using PHP to write database applications for the web. A
>> database application is a database application regardless of whether the
>> user interface is the web or the desktop.
>
> You're bringing up other languages and databases claiming they're 
> relevant - yet when I mention other languages or applications you claim 
> they are irrelevant.

I am constantly talking about "database applications" because they are 
relevant to this topic. Non-database applications, such as operating systems 
and compilers are totally irrelevant.

> The truth is you have no leg to stand on so you keep trying to change the 
> subject and/or claim something is irrelevant.
>
>>> Nor is database normalization (which you also claimed to know how to
>>> do properly - which I also doubt) in that same post.
>>
>> I shall treat that remark with the contempt it deserves.
>
> Good.  You are contemptful.

Of you, yes.

>>> But the incompetent need to have it both ways - ignore the rules when
>>> it benefits them but claim it's off topic when the rules don't suit 
>>> them.
>>
>> You so are saying that I'm incompetent simply because I refuse to follow
>> YOUR rules? Do you know how arrogant that makes you?
>
> No, widely recognized rules by experts.

Who says that the rules that you choose to follow were written by experts? 
What about different sets of rules written by different sets of experts?

> But you refuse to follow them. Do you know how arrogant (and stupid) that 
> makes YOU?
>
> But once again you refuse to discuss the issue and attack back.  You're 
> only showing your stupidity.

No, I'm showing that I don't agree with you.

>>> Which means a mixture of conformant and non-conformant passwords in
>>> your database. Anyone knowledgeable of security would cringe at such a
>>> setup.
>>
>> Any competent person would tell you that if the password validation
>> rules are changed in such a way as to make all exissting passwords
>> non-conformant then you get everybody to change their passwords so that
>> all NEW passwords conform to the NEW rules.
>
> Which is why you set the rules ahead of time.  But that's not what you 
> claimed earlier, so you have to once-again back-pedal.

Password validation rules MAY be set when the application is first 
installed, but it is also possible that they MAY be changed some time later. 
have yiu never heard of customers changing their minds?

>>> But it really doesn't matter - it's all bloatware anyway.

Only in your opinion.

>>> Bloatware. If a customer wants a customized password rule, it's one
>>> line of code to change. And it doesn't add all that unnecessary
>>> complexity (bloatware) to the script.
>>
>> So you are admitting that in YOUR implementation if you want to change
>> the password validation rules then you have to change your code. In MY
>> implementation this can be done by changing a value in the database, and
>> you have the audacity and arrogance to call that bloat!
>
> Sure.  It's a one line change to the code.  Quick, simple, and 
> straightforward.  But once a system is installed, I've NEVER had a 
> customer ask for the rules to be changed.  That's because we discuss the 
> pros and cons of different rules up front.
>
> Plus I don't have to stay on the phone trying to talk the customer through 
> how to implement his new rules.

If you design a simple screen which allows a user to define different 
password validation rules then your are a poor designer.

> Your method is nothing but bloat - which is why you're the only one who's 
> ever implemented such a stupid concept.

It is not boat, it is a valid option. It is also an option that can be 
modified without having to change a single line of code.

>>>>> How many customers have actually demanded the need to change the
>>>>> rules? In over 30 years of programming for clients, none of mine have.
>>>>
>>>> None have had to demand such a facility for the simple reason that it 
>>>> is
>>>> supplied as standard.
>>>
>>> My point exactly. Bloatware. A feature no one wants or cares about.
>>
>> My customers care for it, and their opinion means more to me than yours.
>
> I highly doubt your customers give a damn about it.  Maybe they do because 
> you sold them on how great it is - but then snake oil salesmen are good at 
> that.

I don't sell then anything that doesn't work. I ask then what password 
validation rules they want rom day 1, then I show then how to set those 
rules using the screen provided. They then know how to change the rules 
should they ever want to.

<snip>
>> Your personal insults are adding nothing to this newsgroup. Please try
>> showing a bit more professionalism and maturity.
>
> No personal insult.  Just the truth.

No, just your version of what you assume the truth to be.

-- 
Tony Marston

http://www.tonymarston.net
http://www.radicore.org

Back to comp.lang.php | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Dynamic form generation Charles <cchamb2@gmail.com> - 2012-04-11 20:48 -0700
  Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-12 00:03 -0400
  Re: Dynamic form generation The Natural Philosopher <tnp@invalid.invalid> - 2012-04-12 05:46 +0100
  Re: Dynamic form generation Michael Vilain <vilain@NOspamcop.net> - 2012-04-11 21:52 -0700
    Re: Dynamic form generation Denis McMahon <denismfmcmahon@gmail.com> - 2012-04-12 12:42 +0000
      Re: Dynamic form generation Charles <cchamb2@gmail.com> - 2012-04-12 20:43 -0700
        Re: Dynamic form generation Michael Vilain <vilain@NOspamcop.net> - 2012-04-12 21:55 -0700
          Re: Dynamic form generation Denis McMahon <denismfmcmahon@gmail.com> - 2012-04-13 13:19 +0000
        Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-13 09:59 +0100
          Re: Dynamic form generation Denis McMahon <denismfmcmahon@gmail.com> - 2012-04-13 13:22 +0000
            Re: Dynamic form generation Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-17 14:49 +0200
              Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-17 11:36 -0400
                Re: Dynamic form generation "Tony Marston" <TonyMarston@hotmail.com> - 2012-04-18 09:33 +0100
                Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-18 07:59 -0400
                Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-19 09:56 +0100
                Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-19 08:29 -0400
                Re: Dynamic form generation "Tony Marston" <TonyMarston@hotmail.com> - 2012-04-20 09:27 +0100
                Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-20 07:47 -0400
                Re: Dynamic form generation "Tony Marston" <TonyMarston@hotmail.com> - 2012-04-21 12:22 +0100
                Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-21 10:19 -0400
                Re: Dynamic form generation "Tony Marston" <TonyMarston@hotmail.com> - 2012-04-22 11:45 +0100
                Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-22 10:09 -0400
                Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-24 18:21 +0100
                Re: Dynamic form generation Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-24 20:56 +0200
                Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-25 09:23 +0100
                Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-24 16:20 -0400
                Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-25 10:04 +0100
                Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-25 08:29 -0400
                Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-26 12:45 +0100
                Re: Dynamic form generation Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-22 19:21 +0200
                Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-23 13:50 +0100
                Re: Dynamic form generation Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-24 11:10 +0200
                Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-24 17:11 +0100
                Re: Dynamic form generation Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-24 18:54 +0200
                Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-24 18:55 +0100
                [OT] Was: Dynamic form generation Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-04-25 13:22 +0200
                Re: [OT] Was: Dynamic form generation The Natural Philosopher <tnp@invalid.invalid> - 2012-04-25 12:46 +0100
                Re: [OT] Was: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-26 12:51 +0100
                Re: [OT] Was: Dynamic form generation Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-04-27 10:26 +0200
                [OT] Yes-or-no questions (was: [OT] Was: Dynamic form generation) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-28 07:56 +0200
          Re: Dynamic form generation "Peter H. Coffin" <hellsop@ninehells.com> - 2012-04-14 08:53 -0500
            Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-15 08:33 +0100
              Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-15 08:51 -0400
                Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-16 09:31 +0100
                Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-16 08:33 -0400
                Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-16 15:11 +0100
                Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-16 11:18 -0400
                Re: Dynamic form generation "Tony Marston" <TonyMarston@hotmail.com> - 2012-04-17 09:18 +0100
                Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-17 06:07 -0400
                Re: Dynamic form generation "Tony Marston" <TonyMarston@hotmail.com> - 2012-04-18 09:10 +0100
                Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-18 08:09 -0400
                Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-19 09:27 +0100
                Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-19 08:41 -0400
                Re: Dynamic form generation "Tony Marston" <TonyMarston@hotmail.com> - 2012-04-20 10:10 +0100
                Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-20 08:09 -0400
                Re: Dynamic form generation "Tony Marston" <TonyMarston@hotmail.com> - 2012-04-21 10:35 +0100
                Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-21 06:21 -0400
                Re: Dynamic form generation "Tony Marston" <TonyMarston@hotmail.com> - 2012-04-22 10:27 +0100
                Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-22 10:43 -0400
                Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-23 15:23 +0100
                Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-23 12:24 -0400
                Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-26 17:29 +0100
                Re: Dynamic form generation The Natural Philosopher <tnp@invalid.invalid> - 2012-04-23 20:37 +0100
                What Jerry Stuckle thinks of PHP programmers "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-23 14:10 +0100
                Re: What Jerry Stuckle thinks of PHP programmers Paul Herber <paul@pherber.com> - 2012-04-23 14:22 +0100
                Re: What Jerry Stuckle thinks of PHP programmers "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-23 15:27 +0200
                Re: What Jerry Stuckle thinks of PHP programmers Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-23 09:33 -0400
                Re: What Jerry Stuckle thinks of PHP programmers "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-23 15:26 +0100
                Re: What Jerry Stuckle thinks of PHP programmers Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-23 12:25 -0400
                Re: What Jerry Stuckle thinks of PHP programmers Luuk <luuk@invalid.lan> - 2012-04-23 19:45 +0200
                Re: What Jerry Stuckle thinks of PHP programmers The Natural Philosopher <tnp@invalid.invalid> - 2012-04-23 20:35 +0100
                Re: What Jerry Stuckle thinks of PHP programmers Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-24 19:45 +0200
                Re: What Jerry Stuckle thinks of PHP programmers "Tony Marston" <TonyMarston@hotmail.com> - 2012-04-28 08:48 +0100
                Re: What Jerry Stuckle thinks of PHP programmers The Natural Philosopher <tnp@invalid.invalid> - 2012-04-28 09:23 +0100
                Re: What Jerry Stuckle thinks of PHP programmers Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-28 08:37 -0400
                Re: What Jerry Stuckle thinks of PHP programmers Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-28 14:46 +0200
                Re: What Jerry Stuckle thinks of PHP programmers The Natural Philosopher <tnp@invalid.invalid> - 2012-04-23 20:31 +0100
                Re: What Jerry Stuckle thinks of PHP programmers Ross McKay <au.org.zeta.at.rosko@invalid.invalid> - 2012-04-24 12:32 +1000
                Re: What Jerry Stuckle thinks of PHP programmers Tim Streater <timstreater@greenbee.net> - 2012-04-24 19:32 +0100
                Re: What Jerry Stuckle thinks of PHP programmers Ross McKay <au.org.zeta.at.rosko@invalid.invalid> - 2012-04-25 19:02 +1000
                Re: What Jerry Stuckle thinks of PHP programmers The Natural Philosopher <tnp@invalid.invalid> - 2012-04-25 12:20 +0100
                Re: Dynamic form generation Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-22 23:59 +0200
                Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-23 14:05 +0100
                Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-23 09:35 -0400
                Re: Dynamic form generation Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-23 15:41 +0200
                Re: Dynamic form generation The Natural Philosopher <tnp@invalid.invalid> - 2012-04-23 20:39 +0100
                Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-23 09:47 -0400
                Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-25 08:52 +0100
                Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-25 08:34 -0400
                Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-27 09:52 +0100
                Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-27 14:16 +0100
          Re: Dynamic form generation Charles <cchamb2@gmail.com> - 2012-05-03 15:23 -0700
  Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-12 10:52 +0100
  Re: Dynamic form generation Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-04-13 11:39 +0200
  Re: Dynamic form generation Jonathan Stein <jstein@image.dk> - 2012-04-13 15:27 +0200

csiph-web