| Re: Dynamic form generation [message #177816 is a reply to message #177798] |
Sun, 22 April 2012 10:45   |
Tony Marston
Messages: 57
Registered: November 2010
Karma:
|
Member |
|
|
"Jerry Stuckle" wrote in message news:jmufmh$peq$1(at)dont-email(dot)me...
>
<snip>
>>
>> My definition of ERP is the same as that found in wikipedia at
>> http://en.wikipedia.org/wiki/Enterprise_resource_planning.
>>
>
> No, you're is nothing like that.
>
>> Note that an ERP system need not contain all of those modules, just two
>> or more would be sufficient.
>>
>
> Yours doesn't even contain that.
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.
<snip>
>
>>> All you do is database stuff. There's nothing complex about that.
>>
>> Correct. There is nothing complex about writing code which moves data
>> between the user interface and the database. That is why I developed the
>> Radicore framework, to take care of all that simple "plumbing" stuff for
>> me. My valuable time is spent on writing the code which deals with the
>> business rules, the "payload" as I call it, some of which are more
>> complex than others
>>
>
> And nothing you've done in your entire life is even moderately complex. You
> wouldn't know where to begin.
I shall stop arguing on what is complex and what is not as it is a complete
waste of time.
<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").
>>> But they sure sound like they're bloated.
>>
>> The term "bloat" has nothing to do with the number of database tables.
>> Provided that the database has been properly normalised (you *DO* know
>> what the term "properly normalised" means, don't you?) and every table
>> is used somewhere then there is no "bloat" whatsoever.
>>
>
> It does when you've got way more than you need. And not if it's *properly*
> normalized. However, I highly doubt your 200+ tables are "properly
> normalized".
You have no basis for that ridiculous accusation.
> 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?
<snip>
>>>> >>>> So you framework generates "a lot" of code, does it? My framework
>>>> >>>> generates very small amounts of code which call shared functions or
>>>> >>>> which inherit code from abstract classes.
>>>> >>>>
>>>> >>>
>>>> >>> Yup, for instance, it generates all the set and get methods for the
>>>> >>> applicable class, as well as database access code
>>>> >>> (insert/update/delete
>>>> >>> for single rows and single rows and lists of multiple rows for
>>>> >>> SELECT).
>>>> >>> (Most of the access code is in parent classes).
>>>> >>
>>>> >> My framework does not bother generating set and get methods as they
>>>> >> are
>>>> >> inefficient. Data goes in and comes out as an array.
>>>> >>
>>>> >
>>>> > Yea, that's why your code is crap. You obviously know nothing about
>>>> > proper OO coding techniques. And that means in order to change one
>>>> > item in the object the user has to build an array for the whole thing?
>>>> > Bloat... Bloat... Bloat...
>>>>
>>>> You obviously don't know what "proper OO" actually means. And where did
>>>> I say that in order to change one item in the object the user has to
>>>> build an array for the whole thing? You are reading things which I did
>>>> not write.
>>>>
>>>
>>> Oh, I sure do. You said you don't have SET/GET functions. You said you
>>> set the values with an array. It's exactly what you said.
>>
>> But I don't have to insert any code to create that array as it is
>> already provided for me in the form of $_GET or $_POST.
>>
>> When data comes in from the database it appears as a single variable
>> which is an array of rows and columns.
>>
>
> And you completely miss the question. How do you change a single property
> in the object without building the array?
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.
> 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.
>>>> >> My framework does not generate any database access code as that is
>>>> >> already
>>>> >> provided by my Data Access Object (DAO). I have one for MySQL, one
>>>> >> for
>>>> >> PostgreSQL, one for Oracle and another for SQL Server. I can switch
>>>> >> from one
>>>> >> to another simply by changing a single line in a config file.
>>>> >>
>>>> >
>>>> > Yes, you always waste a lot of time retrieving all columns, whether
>>>> > they are needed or not. And you update all columns, whether you need
>>>> > to or not. Bloatware.
>>>>
>>>> You are jumping to the wrong conclusion AGAIN! The default is to read
>>>> all columns simply because by default all columns are displayed on the
>>>> screen. The defaults can be changed.
>>>>
>>>
>>> Ah, so you have to write code to change those defaults. Once again not
>>> what you claimed earlier.
>>
>> Any person with more than two brain cells to rub together knows that if
>> the default behaviour is not what you want then you have to write code
>> to change those defaults. I have never claimed otherwise. My framework
>> generates working transactions based on a lot of default behaviour, and
>> in a lot of cases the default behaviour is good enough. When it isn't
>> you can change it.
>
> That's not what you claimed earlier. Read back at what you said. But then
> you're good at back-pedaling. And you're doing it again.
It is EXACTLY what I claimed. I *NEVER* said that when using my framework
that a programmer *NEVER* has to write any code.
>>>> >>> It also generates the code necessary to validate a field. Some stock
>>>> >>> fields (like "must be integer") have predefined validation
>>>> >>> functions.
>>>> >>
>>>> >> My framework does not generate any code to perform basic field
>>>> >> validation as
>>>> >> that is performed by a validation class which I wrote years ago.
>>>> >>
>>>> >
>>>> > More bloat. And tell me how your class handles a rule such as "8-16
>>>> > characters, must have both upper and lower case and at least one
>>>> > digit".
>>>>
>>>> Easy peasy. I just set these values in the database:
>>>> min_length = 8
>>>> max_length = 16
>>>> upper_case = 1
>>>> lower_case = 1
>>>> num_digits = 1
>>>>
>>>
>>> Bloatware. The code has to needlessly query the database, parse the
>>> results then apply them to the password, when a regex would do the job
>>> simply.
>>
>> But where do you store the regex? In thin air? Different customers have
>> different rules, so each customer can specify the rules that they want
>> on their copy of the database. That is not bloat, it is sensible design.
>
> Nope, it's in the code. Another customer wants another rule? Change the
> regex. And if you want to be anal about it (you're good at that, also),
> put it in a function in a separate file.
>
> Your way is plain bloat.
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.
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.
>>>> > Or how about the bloat of calling a class to verify the input is an
>>>> > integer when a simple one line statement works. More bloat.
>>>>
>>>> I have a validation class which is capable of validating every data
>>>> type. This means that I do not have to write the line of code which
>>>> tests that a piece of input is an integer. Not having to write that
>>>> line
>>>> is not bloat.
>>>>
>>>
>>> Again, bloatware, when a simple function call like intval() will do
>>> it. You've added an additional and unnecessary layer of complexity to
>>> the application.
>>
>> You are missing the point AGAIN. In your applications you have to write
>> code to call the intval() function. In my applications I don't have to
>> write any validation code because I wrote a general purpose validation
>> class many years ago, and it deals with that level of validation
>> automatically.
>
> More bloat. No, the intval() function call is inherent to the set()
> function.
I don't have separate setter and getter functions for each column on a
table.
> 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.
>> 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!
<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.
> 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.
> 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.
> 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.
>>>> >>> It also has the ability to generate forms html to display
>>>> >>> (read/write or
>>>> >>> read only). And this is all one function. If I need a different
>>>> >>> layout
>>>> >>> for a different page, it's easy to copy/paste a new function and
>>>> >>> redo the
>>>> >>> output.
>>>> >>
>>>> >> Copy/Paste? That produces duplicate code, not sharable code, and even
>>>> >> you
>>>> >> should know that duplicate code violates the DRY principle.
>>>> >>
>>>> >
>>>> > You obviously don't understand the DRY principle. Just because you
>>>> > copy/paste does not mean it's duplicate code. Once the code has been
>>>> > modified to do something else, it is no longer duplicate.
>>>>
>>>> If you were really clever you wouldn't have to copy/paste/modify, you
>>>> would have a reusable module. In my MVC implementation I have a fixed
>>>> set of controllers, and each controller is reusable. Can you say the
>>>> same in your framework?
>>>>
>>>
>>> Doesn't make any difference. How do you handle displaying the same
>>> information two entirely different ways on two different windows? Mine
>>> is simple and straightforward. It is also easy to maintain.
>>
>> So is mine.
>>
>
> Yes? So how do you display the same data in different formats then?
I have a different transaction based on a different transaction pattern, one
to output HTML, another for PDF and another for CSV.
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.
>>>> >>> It also has a function to populate the object from $_GET or $_POST
>>>> >>> values
>>>> >>> (with validation).
>>>> >>
>>>> >> I don't need a whole function to do that when a single line will do:-
>>>> >> $result = $object->insertRecord($_POST);
>>>> >>
>>>> >
>>>> > So what is insertRecord($_POST) then, if it's not a function? Once
>>>> > again you show your ignorance. Don't even know what a function is!
>>>>
>>>> What I'm saying is that I don't have a function which splits the $_POST
>>>> array into its component parts so I can then use a setter on each
>>>> component, I simply inject the entire $_POST array in a single
>>>> operation
>>>> without the need to split it down into its component parts.
>>>>
>>>
>>> So you do have a function which does the work. That's not what you
>>> said earlier.
>>
>> Read what I wrote. I do *NOT* have any function which splits the input
>> array, be it the $_GET array, the $_POST array, or whatever, into its
>> component parts. All database data exists in the database table object
>> as an array of rows and columns.
>
> I never said you had a function which splits the input array. I know
> English is not your first language, but you really should learn to read.
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.
That is what I wrote, but that is not what you read. The error is yours, not
mine.
>>> I never said I had to split it down into parts, either. I have a
>>> member function which handles the input. But I guess that's just too
>>> much for you to understand.
>>
>> I beg to differ. You specifically wrote that you have getters and
>> setters for each individual column/field. I do not have code which
>> splits an array into its component parts as I can access any component
>> part while it is still sitting in the array.
>>
>
> That's right. That's an implicit part of OO (encapsulation).
Using getters and setters has nothing to do with encapsulation.
<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.
>>>> >> This means that the same line will work on any object regardless of
>>>> >> which
>>>> >> class it came from. That is what polymorphism is all about.
>>>> >>
>>>> >
>>>> > Nope, that's not at all what polymorphism is about. But you obviously
>>>> > don't understand polymorphism, either.
>>>>
>>>> The definition of polymorphism which I use is "same method, different
>>>> implementation". What definition do you use?
>>>>
>>>
>>> You've got a *partial* definition. Polymorphism is only applicable
>>> when the two classes have a parent/child hierarchy, and the child
>>> class has a method of the same name (and in some languages, the same
>>> parameter list) as the parent.
>>
>> The definition of polymorphism does NOT state that the classes have to
>> exist in a parent/child hierarchy, only that they have the same method
>> signature. Having said that, it is usually the case that the two classes
>> ARE related.
>>
>
> Once again you show you have no knowledge of OO. Polymorphism cannot exist
> without inheritance - which requires a parent/child hierarchy.
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.
> In most languages the method signature must also be the same (in fact I
> don't know of any language which doesn't), but that's not a requirement of
> polymorphism (unlike the parent/child relationship).
>
>>> When there is no parent/child relationship (as in the case of two
>>> different database tables), there is no polymorphism.
>>
>> Then you obviously haven't used an abstract table class which is
>> inherited by every concrete table class. All my concrete table classes
>> have instant access to all the methods and properties which are defined
>> just once in the abstract class.
>
> I've used them much longer than you've even known they existed. When you
> have a class derived from the abstract class, there is a parent/child
> relationship. But there is no such relationship between two classes
> derived from the same one.
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.
<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.
<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.
>>>> >> If *your* framework is so good, then why don't you release it as open
>>>> >> source so that we call all have a laugh?
>>>> >
>>>> > For a lot of reasons. Mainly because I'm not interested in the hassles
>>>> > of having to support it for a bunch of people who want all kinds of
>>>> > other features. I created it for my projects, and it serves those
>>>> > projects well.
>>>>
>>>> What you really mean is that you are too ashamed to have it reviewed by
>>>> your peers, and that you are incapable of writing code which can be
>>>> used
>>>> by others.
>>>
>>> Not at all. I meant exactly what I said.
>>
>> Yes, you can't be bothered to release it as it is only useful for your
>> own personal toy projects.
>
> Nope. I just don't want to have to answer a bunch of anal questions by the
> likes of you. I have better things to do with my time.
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.
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.
>>> 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.
>> That's not the impression I get from reading your comments in this post.
>> You seem to think that YOUR way is the ONLY way, and anybody who dares
>> to disagree with you is a stupid moron. I disagree with everything you
>> say, and as for being a moron, 99% of the emails which I receive on the
>> subject on my work are nothing but complimentary.
>
> Nope. I didn't say my way was the only way. I said my way works, does not
> contain bloatware and follows recognized OO practices. All you can claim
> is yours works.
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.
> 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.
>>> But my code is reviewed by others quite often. Most projects I work on
>>> are collaborative. But then I work with programmers who know what
>>> they're doing, also.
>>
>> I'd hate to on a team of programmers who all think like you as they
>> would all be unproductive and full of silly ideas.
>
> We work quite well together and create a lot of GOOD code. Unlike the crap
> you put put.
You definition of "crap code" seems to be nothing more than "it is not the
same as mine, therefore it's crap".
--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]