| Re: Dynamic form generation [message #177818 is a reply to message #177816] |
Sun, 22 April 2012 14:09   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 4/22/2012 6:45 AM, Tony Marston wrote:
> "Jerry Stuckle" wrote in message news:jmufmh$peq$1(at)dont-email(dot)me...
>> Yours doesn't even contain that.
>
> My ERP system implements the functionality covered by several of the
> databases described in Len Silverston's Data Model Resource Book,
> specifically PARTY, PRODUCT, ORDER, INVOICE, INVENTORY, SHIPMENT,
> REQUESTS+REQUIREMENTS and WORK-EFFORT. That constitutes multiple
> modules. An ERP system is not required to have every possible module
> that can possibly be conceived, it can be limited to a subset that are
> actually required.
>
Your order entry/tracking system does just that. It someone to enter
orders and tracks those orders. Nothing more, nothing less.
To call this an ERP system proves you are:
a) Stoopid
b) Dishonest
c) All of the above
Which are you?
>>
>> And nothing you've done in your entire life is even moderately
>> complex. You wouldn't know where to begin.
>
> I shall stop arguing on what is complex and what is not as it is a
> complete waste of time.
>
Good thing, since you've never worked on anything other than simple
database applications. You have no idea what a complex program is, and
you're just proving over and over again your stupidity. You should have
quit while you were ahead (not that you ever were).
> <snip>
>> To you a "complex business rule" is "the customer ordered something so
>> we need to ship it".
>>
>> You've have no idea what a complex system is. All you do is database
>> access.
>
> Untrue. My applications do much more than simply move data between the
> database and the user interface. My framework can achieve that without
> me having to write a single line of code whereas yours cannot. It is the
> processing of business rules which turns a simple application into a
> complex one, and my framework allows programmers to spend less time
> writing the boring repetitive code (the "plumbing") and more time on the
> business rules (the "payload").
>
You have no idea what a complex system is - and you just once again
proved it. But once again, you prove your stupidity. You just said you
weren't going to argue what a complex system is in your previous
paragraph. Yet here you are doing it again.
You're just proving your stupidity. You should have quit while you were
ahead (not that you ever were).
>>
>> It does when you've got way more than you need. And not if it's
>> *properly* normalized. However, I highly doubt your 200+ tables are
>> "properly normalized".
>
> You have no basis for that ridiculous accusation.
>
Only your words.
>> Bloat also covers unnecessary crap like your "password validation".
>
> So the fact that in my implementation a customer can change the password
> validation rules by changing values on a screen whereas in yours you
> have to change the code makes my implementation bloated? Where do you
> get these ridiculous ideas?
>
Yup, and the fact you think it's slicker than snot on a doorknob is
hilarious. It IS the shot on the doorknob!
It's unnecessary features like this which create bloated code.
>>
>> And you completely miss the question. How do you change a single
>> property in the object without building the array?
>
> BECAUSE THE ARRAY IS ALREADY INSIDE THE OBJECT, YOU IDIOT!!! I don't
> need code inside the table object to build the array as it is supplied
> as an array, either from the $_GET or $_POST array, or an array of rows
> and columns from the database.
>
So, IOW, you can't change a single property from the program. You
can't, for instance, set just the ship date in an order. You can only
set the entire object. How stupid.
>> From the number of times you have ducked the question, my only
>> assumption can be the program can't change a single property in the
>> object.
>
> Changing a property inside an object is as simple as changing a value in
> an array.
>
Oh, so all of your variables are public? How stupid is that? It
violates the first rule of OO programing - encapsulation.
So you're saying I can say
$object->ship_date = 9999-12-31. Or even
$object->ship_date = "This is completely stupid but OK according to Tony".
Proper OO programming doesn't allow such crap programming.
>>
>> That's not what you claimed earlier. Read back at what you said. But
>> then you're good at back-pedaling. And you're doing it again.
>
> It is EXACTLY what I claimed. I *NEVER* said that when using my
> framework that a programmer *NEVER* has to write any code.
>
ROFLMAO! Back-pedaling again. And you can't even read what you wrote
previously.
>> Your way is plain bloat.
>
> Validating that date fields contain dates, numeric fields contain
> numbers and NOT NULL fields are not empty is never something that a user
> can change because it is standard validation, which is why I put all the
> necessary code in a standard validation class years ago. This means that
> in my framework, unlike yours, I never have to write a line of code to
> perform standard validation.
>
Only you would think instantiating an object to ensure a value is really
an integer is better than just calling intval(). Bloat, bloat, bloat.
> If a customer requires an additional rule, such as comparing dates on
> one database table with dates on another, then that is non-standard, is
> not covered by the standard validation class and will therefore require
> a programmer to write some code.
>
With proper OO principles, the object requiring the rule implements the
rule.
>> More bloat. No, the intval() function call is inherent to the set()
>> function.
>
> I don't have separate setter and getter functions for each column on a
> table.
>
Yea, you allow people to set the variables directly (see above). A
direct violation of the most basic OO principle.
>> I have to write nothing. And I don't have the bloat of a "general
>> validation class".
>
> Having all standard validation performed in a single class is most
> definitely not bloat, especially when compared with YOUR method of
> having a separate method to validate each field individually.
>
Having instantiate the object just to ensure a value is an integer when
a simple call to intval() does the same thing is bloat.
But then you don't validate things set by the program, because you don't
understand encapsulation.
>>> Again you are writing code to do something which my framework does
>>> automatically. And you have the nerve to say that my methods are crap!
>>
>> Nope, my framework automatically handles simple rules based on
>> datatypes. If I need more complex rules, they are easy to enter.
>
> That's exactly how my framework works, but I achieve the same result by
> different means. You seem to think that simply because my methods are
> different that they are automatically wrong. What an arrogant person you
> are!
>
So tell me - how do you prevent
$object->ship_date = "This is stupid!";
> <snip>
>>>> More bloat. And unnecessary. How often does the customer want to
>>>> change the password rules? In about 35 years of programming for
>>>> clients, I've never had that happen. And what about the existing
>>>> passwords which don't match the new rules?
>>>
>>> A customer may or may not want to change the rules after the software
>>> has been installed, but as my software is used by many different
>>> customers each one may want a different set of rules when it is first
>>> installed. I can apply whatever rules a customer wants simply by
>>> changing his copy of the database, and NOT by changing any code.
>>
>> Changing one line of code is not a problem. Your way is pure bloat.
>
> Giving the customer the ability to change the password validation rules
> by changing values on a screen instead of getting the programmer to
> change a line of code is not bloat.
>
Bloat, bloat, bloat. Everyone else in the world understands that, which
is why they haven't implemented it. It is a completely unnecessary
complication to the code, requiring a call to the database, parsing the
output and then applying a rule every time a password is changed.
It can all be done in one line of code, and especially unnecessary since
this is open source.
Bloat, bloat, bloat.
>> It's interesting that this feature you think is slicker than snot on a
>> doorknob hasn't been implemented by any other systems I'm aware of -
>> including mainframe applications. The rest of the world knows bloat
>> when they see it.
>>
>>>> Why stop with the password? Why not let the customer change the window
>>>> layout, for instance? Or add tables and columns to the database?
>>>
>>> Now you're going off at a tangent. I should quit while you're behind.
>>>
>>
>> Nope, you brought up the subject of allowing the customer to change
>> the rules.
>
> Only the password validation rules.
>
And I asked why, when you implemented a function no one else in the
world has found a need for, haven't you implemented a function that
millions of people want and need?
>> This is just an extension of the same subject. After all, CMS's allow
>> customer's to change the screen layout to suit them; CMS's don't force
>> all customers to use the same screen layout.
>
> It is you who is extending this conversation into irrelevant areas.
>
Nope, it's showing just how stupid your "password rules" are.
>> There are many more systems which allow the user to change the page
>> layout than there are the password. The rest of the world knows bloat
>> when they see it.
>>
>> I guess that's all the bloat you're capable of, though. Even a simple
>> CMS would be beyond your capabilities.
>>
>>>> Your code is just bloatware and adds an unnecessary layer of
>>>> complexity to the code.
>
> No, I am simply providing the customer with the ability to change
> password validation rules by changing values on a screen, not by getting
> the programmer to change some code. That is not "an unnecessary layer of
> complexity" as you call it, it is good design.
>
Your code is just bloat. Even the greenest programmers in the rest of
the world understand how unnecessary your bloatware is.
>>>
>>
>> Yes? So how do you display the same data in different formats then?
>
> I have a different transaction based on a different transaction pattern,
> one to output HTML, another for PDF and another for CSV.
>
I asked how do you display the same data in different formats, not
different media. But you can't do that, can you?
> If it is necessary to have the HTML output displayed differently under
> different circumstance then I would still have a separate transaction
> with each having its own screen structure file.
>
Gee, sounds like you have to create a lot of code to just do something
as simple as displaying the same information in a slightly different
format. My way is easy and can be done very quickly.
>>
>> I never said you had a function which splits the input array. I know
>> English is not your first language, but you really should learn to read.
>
> You said that I had a function just like yours which splits the
> $_GET/$_POST array into its component parts so that it can use a setter
> on each of those component parts. I simply said that I don't have any
> function which splits any array into its component parts, and I don't
> have getters or setters for each of those component parts.
>
I never said anything of the type. I said I had a function which took
the input from $_GET or _$POST and processed it. I also said I had
getter and setter functions.
The lack of getters and setters means your variables must be public,
which violates the first principle of OO programming - encapsulation.
> That is what I wrote, but that is not what you read. The error is yours,
> not mine.
>
You still can't read what you write, can you?
>>
>> That's right. That's an implicit part of OO (encapsulation).
>
> Using getters and setters has nothing to do with encapsulation.
>
Only in the alternate universe of Tony Marston. You really should try
reading a book on OO by a recognized expert in the field. Booch would
be a good start.
> <snip>
>> But unlike you, I can get or set a single property, also, as needed.
>> Something I do all the time.
>
> In my implementation of MVC neither the Controller nor the View *EVER*
> needs to obtain a single column value by its name. They only ever deal
> with an array of rows and columns, and they don't care what the array
> contains. That is why my implementation has a small number of
> Controllers and Views which are reusable.
>
Which doesn't answer my question. But then you've already answered it.
You don't even understand the basic OO concept of encapsulation.
>> Once again you show you have no knowledge of OO. Polymorphism cannot
>> exist without inheritance - which requires a parent/child hierarchy.
>
> Yes it can. Polymorphism simply requires that the same interface exist
> in more than one class. That may come from inheritance, or it may not.
> It *IS* possible to define the same interface more than once without
> inheritance.
>
It's not surprising you claim this. When you don't even understand
encapsulation, no one should expect you to understand a more advanced
concept like polymorphism.
>>
>> I've used them much longer than you've even known they existed. When
>> you have a class derived from the abstract class, there is a
>> parent/child relationship. But there is no such relationship between
>> two classes derived from the same one.
>
> Each one of the 200 concrete table classes in my application is derived
> from the same abstract table class, so each one of those 200 classes is
> a sibling of the other, and "sibling" implies a relationship.
>
So there is a sibling relationship? Once again you prove how you don't
understand the concept of polymorphism.
> <snip>
>>> It is much more than a simple database application which does nothing
>>> more than move data between the user interface and the database. It
>>> processes a large number of business rules, and it is the number and
>>> complexity of these business rules which decides whether an application
>>> is actually complex or not.
>>
>> In your world, yes. But then all you've ever done are database
>> applications. You've never worked on anything even moderately complex,
>> by your own admission.
>
> Just because it is a database application does not mean that it can only
> ever be a simple application and never a complex one. It is the number
> and complexity of the business rules which is in addition to the basic
> functionality of moving data between the database and the user interface
> which changes a "simple" data access system into a "complex" one.
>
You've never written a complex application in your life. But then to
you, adding a few business rules makes an application complex. In the
alternate universe of Tony Marston, it does - because you aren't capable
of anything more.
> <snip>
>> But then I can see why you weren't able to keep a job with any of
>> those software houses.
>
> I worked with one for 16 years. My personal development standards were
> adopted as the company standards. A framework which I designed and
> developed for one client was adopted as the company standard. That would
> not have happened if I were such a crap programmer as you seem to think
> I am.
>
ROFLMAO! You mean you found someone even stupider than you? That's
pretty hard to believe.
>>
>> Nope. I just don't want to have to answer a bunch of anal questions by
>> the likes of you. I have better things to do with my time.
>
> All you can do is come up with unfounded criticisms of other people's
> work without having the courage to release your work so that other
> people have the opportunity to criticise your work.
>
All of my criticisms are based on solid programming principles and your
own statements about your code.
> I released my framework as open source but you don't have the courage to
> do the same with yours. That means that you don't have the courage of
> your convictions. You don't want to release your work in case somebody
> tells you that it's crap.
>
No, I don't need to stroke my ego. And I don't need idiots like you
making anal comments about it.
>>>> Unlike you, I don't need my ego stroked.
>
> But you don't like your methods to be criticised, do you? You seem to
> think that anybody whose methods are different from yours is
> automatically an incompetent moron.
>
Nothing of the sort. But then it's pretty common of you - you can't
defend your code so you attack the messenger.
>> Nope. I didn't say my way was the only way. I said my way works, does
>> not contain bloatware and follows recognized OO practices. All you can
>> claim is yours works.
>
> My way works just as your way works. As for "recognised OO practices"
> there is no single set of practices which is recognised by every single
> programmer on the planet. Different groups recognise different
> practices, and I just happen to belong to a different group than you do.
>
No, your way doesn't work.
And yes, there is a single set of practices agreed to by recognized
experts in the field. Unfortunately, Tony Marston isn't one of those
experts.
But he is in the Universe According to Tony Marston. Too bad it's a
universe of one.
>> And knowing how the rest of the world feels about the ability of PHP
>> programmers, it's not surprising. I've seen some pretty crappy code
>> get high marks because people don't know any better.
>
> That sounds like your opinion of your code is because you simply don't
> know any better.
>
It is well recognized by programmers in other languages. You even see
comments about it in this very newsgroup occasionally. And the true
experts here agree with it.
And it has nothing to do with my code. But then you're good at trying
to change the subject when you have no defense.
>>
>> We work quite well together and create a lot of GOOD code. Unlike the
>> crap you put put.
>
> You definition of "crap code" seems to be nothing more than "it is not
> the same as mine, therefore it's crap".
>
Nope. How about it's bloated, overly complicated and doesn't follow
generally recognized principles, for starts?
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]