FUDforum
Fast Uncompromising Discussions. FUDforum will get your users talking.
Home » Imported messages » comp.lang.php » Dynamic form generation
Show: Today's Messages :: Polls :: Message Navigator
Return to the default flat view Create a new topic Submit Reply
Re: Dynamic form generation [message #177815 is a reply to message #177791] Sun, 22 April 2012 09:27 Go to previous messageGo to previous message
Tony Marston is currently offline  Tony Marston
Messages: 57
Registered: November 2010
Karma:
Member
"Jerry Stuckle" wrote in message news:jmu1nc$fui$1(at)dont-email(dot)me...
>
> On 4/21/2012 5:35 AM, Tony Marston wrote:
<snip>
> From your description, any good programmer can tell your code is crap.
> Only those like yourself can't see crap when it's described.

Your definition of crap code seems to be nothing more than "it doesn't
follow my rules, therefore it must be crap".

>> By "vast majority" I mean the "vast majority of people who send me
>> emails about my work". For every 100 I receive 99 of them are
>> complimentary. The other 1% are nothing but personal insults, sent
>> anonymously and without valid return addresses.
>>
>
> Yea, right. And what is the experience of those programmers? PHP
> programmers as a whole are not known for their intelligence or competence.
> In fact, just the opposite is true.

So, as this is a newsgroup for PHP programmers you are effectively saying
that every member of this group is stupid and incompetent? Do you know how
arrogant that makes you sound?

> But then you're a great example of the latter.

Have you looked in the mirror lately?

<snip>
> Horse hockey. You don't have an ERP system. You don't even know what an
> ERP system is, and have never seen a real one. You've got a simple order
> entry/tracking system. Any competent programmer can do the same in a short
> time.

My system qualifies as an ERP system according to the definition in
wikipedia. The fact that it does not satisfy your personal definition is
irrelevant.

>>>> <snip>
>>>> >> I don't GET/SET individual fields - everything (by this I mean
>>>> >> database
>>>> >> data) goes in as an array, and everything comes out as an array. The
>>>> >> idea of
>>>> >> unpicking the array to inject every value individually strikes me as
>>>> >> being
>>>> >> inefficient, and therefore bad practice.
>>>> >>
>>>> >
>>>> > Gee, which means you have to build an array for the whole object every
>>>> > time you need to change one property. Which means the rest of the
>>>> > program is also dependent on that object. More bloat. More complexity.
>>>>
>>>> I don't need to build an array as the array is provided for me. If it
>>>> comes from the user it is the $_POST array. If it comes from the
>>>> database it is an array of rows and columns.
>>>>
>>>> How is using an array which can contain any number of columns and
>>>> values
>>>> "more complex" than having to define a separate variable for each
>>>> column, and a separate getter/setter for each column. My method uses
>>>> LESS code therefore it is LESS complex.
>>>>
>>>
>>> And if the application needs to change one value without using the
>>> $_POST array, it has to build an entire array just to set the one
>>> value. Bloat!
>>>
>>> There are reasons for SET/GET methods.
>>
>> Just as there are reasons NOT to use them. I may insert data into an
>> object with a setter, or I may use an argument on a method call. I find
>> it much easier (ie: less coding) to insert the $_POST array as a
>> complete array in a single method argument that to split it into its
>> component parts and "set" each component one at a time.
>>
>
> What do you think a setter is if it's not a method? And you never have
> answered how the programmer can change one property without building a
> whole array. Or get a single property?

The table data already exists in the object as an array, so the programmer
can examine or change the contents of the array at will. The programmer does
not have to build the array, it is already there! Why can't you understand
such a simple concept?

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

Implementation means code, not data.

>>> Less code does not mean less complexity. In fact, just the opposite
>>> can be true.
>>
>> Less code to write means less time to write it, less time to test (as
>> the pre-written functions have already been tested), and less
>> maintenance. That has been my experience over 30 years, and nothing you
>> can say will change my opinion.
>>
>
> That also is not necessarily true. Yes, pre-written functions are great.
> That's why I use them in my code generator.

My framework generates less code than yours because it uses more generalised
functions. I don't use the copy paste method that you seem to favour.

> But less code can mean MORE complexity. However, you've never worked on
> anything non-trivial, so you wouldn't understand.

How can less code be more complex?

<snip>
>> Take a look at the definition of "ERP" at
>> http://en.wikipedia.org/wiki/Enterprise_resource_planning and tell me
>> I'm wrong. I don't have all the modules listed there, but SME's don't
>> need all those modules.
>
> I suggest you read it. An ERP system HAS all the modules. You can't pick
> and choose. It's an integrated system.

If you read the definition properly you will see that it is a set of
integrated modules, and not all users require all modules. My ERP system
does much more than deal with just sales orders. It does what my users want,
and I care more for their opinion than I do yours.

<snip>
>> No I don't. You told me yourself that you regularly cut, paste and
>> modify code. I don't need to do that as the code is defined once in a
>> reusable function.
>
> Exactly. But that's not duplicated code. It's starting with a code
> template and modifying it to suit my needs. That way you don't need to
> start from scratch every time.

If you were really competent you would create a version of that code
template that could be reused as a single function instead of having to be
copied and modified multiple times.

<snip>
>> An application can be described as "complex" by looking at the volume of
>> business rules which have to be implemented. Using the Radicore
>> framework I can quickly generate working transactions which already
>> handle the boring work of moving data between the database and the user
>> interface, which leaves maximum time to spend on the payload, the
>> business rules.
>>
>
> You can claim that for your simple database applications. But then you
> need to do that to satisfy yourself you're working on "complex"
> applications. Those of us who have worked on truly complex applications
> know better.

A complex application has complex business rules. A simple application has
simple business rules. The number of lines of code is irrelevant. If I can
take an application that uses 3M LOC and achieve the same result using half
as many LOC would that automatically make my version half as complex? I
think not.

>>>> >>> None of those use frameworks because the frameworks don't work.
>>>> >>
>>>> >> You mean that the frameworks which you have used didn't work. If you
>>>> >> write
>>>> >> an application with> 3M LOC *WITHOUT* using a framework, even if you
>>>> >> have
>>>> >> to build it yourself, then you are not an efficient programmer.
>>>> >>
>>>> >
>>>> > Nope. What kind of framework do you use for an OS, for instance?
>>>>
>>>> What has building an OS got to do with this conversation? This is a PHP
>>>> newsgroup, which means that we are supposed to be talking about web
>>>> applications written in PHP.
>>>>
>>>
>>> An OS is an application. You claim all this knowledge of great
>>> techniques. So have you ever written an OS? Or how about a compiler?
>>
>> I repeat, this is a PHP newsgroup, which means that we are supposed to
>> be talking about web applications written in PHP.
>>
> So? You've claimed you've worked on "database applications for decades".
> That's long before PHP existed. You opened the door. Now you're
> backpedaling. Typical.

I am not back pedalling. This newsgroup is for people who write database
applications in PHP, so comments about writing operating systems or
compilers are irrelevant.

Before I starting writing database applications with PHP I wrote database
applications with a variety of other languages. That shows that my
experience of writing database applications has not been confined to the PHP
language. Tellme how that is back pedalling?

>> Applications which are NOT web applications and NOT written in PHP are
>> irrelevant.
>
> Only because all you do are trivial applications in PHP - and you do it
> poorly, at that.
>
>>> Even DOS 1.0 was more complex than anything you've written.
>>
>> DOS is not a web application written in PHP, so it's irrelevant.
>
> Nope, and neither were the "decades of database applications" you claimed
> to have written in the very post I'm replying to.

The fact that my experience with other languages meant that I wrote database
applications for the desktop does not mean that it is totally irrelevant
when using PHP to write database applications for the web. A database
application is a database application regardless of whether the user
interface is the web or the desktop.

> Nor is database normalization (which you also claimed to know how to do
> properly - which I also doubt) in that same post.

I shall treat that remark with the contempt it deserves.

> But the incompetent need to have it both ways - ignore the rules when it
> benefits them but claim it's off topic when the rules don't suit them.

You so are saying that I'm incompetent simply because I refuse to follow
YOUR rules? Do you know how arrogant that makes you?

<snip>
>>>> > And what about existing passwords which don't follow the new rules?
>>>>
>>>> The password rules only apply to new passwords.
>>>
>>> So then you have a mixture of both old and new rules.
>>
>> No. Validation rules only apply when a value is entered, not read. If a
>> user is forced to change his password after a number of days, or a
>> number of logons, then any change in rules is only applied when he
>> changes his password. A change in validation rules has no effect on
>> existing passwords.
>
> Which means a mixture of conformant and non-conformant passwords in your
> database. Anyone knowledgeable of security would cringe at such a setup.

Any competent person would tell you that if the password validation rules
are changed in such a way as to make all exissting passwords non-conformant
then you get everybody to change their passwords so that all NEW passwords
conform to the NEW rules.

> But it really doesn't matter - it's all bloatware anyway.
>
>>>> > But again, more bloatware.
>>>>
>>>> Wrong. I'm providing the ability for a customer to tailor the password
>>>> rules to his own specifications without the need to make any code
>>>> changes. How is that "bloatware"?
>>>>
>>>
>>> Because it's code that adds unnecessary complexity to the code, for an
>>> unnecessary feature. But you've shown you're good at that.
>>
>> It is not an unnecessary feature. Different customers may have different
>> rules, and I can satisfy those rules without having to change a single
>> line of code.
>>
>
> Bloatware. If a customer wants a customized password rule, it's one line
> of code to change. And it doesn't add all that unnecessary complexity
> (bloatware) to the script.

So you are admitting that in YOUR implementation if you want to change the
password validation rules then you have to change your code. In MY
implementation this can be done by changing a value in the database, and you
have the audacity and arrogance to call that bloat!

>>> How many customers have actually demanded the need to change the
>>> rules? In over 30 years of programming for clients, none of mine have.
>>
>> None have had to demand such a facility for the simple reason that it is
>> supplied as standard.
>>
>
> My point exactly. Bloatware. A feature no one wants or cares about.

My customers care for it, and their opinion means more to me than yours.

<snip>
>> The major customer of my ERP system took a look at various ecommerce
>> packages before deciding that they weren't good enough, which is why I
>> was asked to design and build a "proper" system for them.
>>
>
> You don't have an ERP system. You have a simple order entry/tracking
> system.
>
> And maybe they should have hired a competent consultant who could have
> recommended a proper system for them at a fraction of the cost you charged
> them for your custom system.

Your personal insults are adding nothing to this newsgroup. Please try
showing a bit more professionalism and maturity.

--
Tony Marston

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

Report message to a moderator

[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Data injection problems
Next Topic: Do you want to develop PHP for the Web and make money
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Fri Nov 22 20:08:45 GMT 2024

Total time taken to generate the page: 0.05043 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.1.3.
Copyright ©2001-2023 FUDforum Bulletin Board Software