| Re: Dynamic form generation [message #177870 is a reply to message #177865] |
Tue, 24 April 2012 20:20   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 4/24/2012 1:21 PM, Tony Marston wrote:
> "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message
> news:jn13eu$4ll$1(at)dont-email(dot)me...
> <snip>
>>>> 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.
>
> If I have a transaction where the only value that can be changed in the ship
> date for an order, then the $POST array will contain "ship_date = whatever".
>
> My update controller has the line $dbobject->updateRecord($_POST) where
> $dbobject is an instance of the order class.
>
> The order class, as with every other table class in my system, will perform
> an update operation using the contents of its input array however many
> fields it contains. It does not matter whether it contains 1 field or 100
> fields, it's all the same.
>
> Why can't you understand such a simple concept?
>
And an intelligent system will just have a button that says "order
shipped" with the program filling in the date. No input field required!
In a real OO system you don't need to use the $_POST array - the program
can update individual items and still ensure the data are valid.
Why can't you understand such a simple concept?
>>>> 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.
>
> Encapsulation does not mean data hiding.
>
I never claimed it does. I said it means CONTROLLED ACCESS.
>> 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".
>
> I've already told you that I don't have a separate class property for each
> column in the table. All the table data is held in a single array, so
> instead of
>
> $object->ship_date = '9999-12-31'
> you would have to use
> $object->fieldarray['ship_date'] = '9999-12-31';
>
> Such duff data would never make it to the database anyway as it would fail
> the validation.
>
According to your comments, such a construct will never be validated.
So how can it fail validation?
>> Proper OO programming doesn't allow such crap programming.
>
> OO does not prevent programmers from writing crap code. It just allows then
> to generate a different class of crap.
>
I never claimed it did. But proper design and implementation means good
code.
> <snip>
>>>> 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.
>
> I don't instantiate my validaton object for each individual value, I do it
> just once to validate the whole array of values.
>
Bloat, bloat, bloat. Also much harder to understand and maintain than a
simple call to intval().
>>> 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.
>
> But the rule has to be coded within the relevant class.
>
That is correct. That's why the class is independent of the rest of the
program. It implements it's own rules and data, which can be changed as
long as the public methods don't change.
>>>> 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 don't have separate getter and setter functions for each entry within the
> array because the data goes in and out as an array.
>
And in order for the program to set an individual item it must build an
array - having to know the internal workings of the class.
>> 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.
>
> I understand encapsulation very well. The validation rules for the person
> entity are defined within the person class. When I call the validation
> object I give it two variables - the array of field values and the array of
> field rules. The validation object will then verify that each field's value
> conforms to its rules.
>
Obviously you don't understand encapsulation at all.
>>>> > 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!";
>
> Because the validation rule for the field called "ship_date" is that it be a
> date, so the value "This is stupid!" will be rejected.
>
It can't be, because you have repeatedly stated the validation is done
on an input array. There is nothing to stop me from putting that in the
variable in the class because you don't have setter functions.
> <snip>
>>>> 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?
>
> That question is orthogonal to the subject of this thread, so I shall ignore
> it.
>
Sure you ignore it because it's a valid question you have no answer to.
> <snip>
>>>>
>>>> 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?
>
> Read on, MacDuff.
>
>>> 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.
>
> You're missing the point again. If you want to have the data from the same
> table displayed in one of several different formats then you need a
> mechanism for the user to choose which format he wants. I do that my having
> a separate transaction, with its own menu button, for each format.
>
> The only different coding that would be required would be in a small screen
> structure file, and that would be also be quick and easy.
>
Gee, it 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 allows me to create either of those methods in
10 minutes or less. How long does yours take? A lot more than 10
minutes, for sure.
>> 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.
>
> Youn said that you had a function which took the $_GET or $_POST array,
> split it into its component parts so that you could use a setter on each
> part.
>
> The fact that the function accepts an array as its input is irrelevant as
> you are still spliting the array into its component parts.
>
So? It has to be split into component parts anyway before inserting
into the database. My way does it on input. The advantage is that ALL
write access to the object is controlled and validated because the
programmer can't access private variables directly. Yours doesn't do that.
>> The lack of getters and setters means your variables must be public, which
>> violates the first principle of OO programming - encapsulation.
>
> Encapsulation does not mean data hiding.
>
You're the only one who keeps bringing up data hiding.
>>>> 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.
>
> There are many others who also think that encapsulation does NOT mean data
> hiding. take a look at the following:
>
> 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/ - the 2nd paragraph titled
> "Encapsulation Wasn't Meant To Mean Data Hiding" written by martin Fowler.
>
You're the only one who keeps bringing up data hiding.
>>> <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.
>
> The fact that my controllers and views do not use getters and setters on
> named items has nothing to do with encapsulation.
>
It has EVERYTHING to do with 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.
>
> It is not a claim it is a fact that it is possible to have the same
> interface in more than one object WITHOUT inheritance.
>
Sure you can. But that is not polymorphism.
>> When you don't even understand encapsulation, no one should expect you to
>> understand a more advanced concept like polymorphism.
>
> My understanding of the concepts of OO are documented in
> http://www.tonymarston.net/php-mysql/what-is-oop.html#what.is.an.oo.languag e
>
Yes, your understanding is sadly lacking in even the most basic concepts.
Once again I refer you to a world-recognized expert on OO. But it might
destroy some of your misconceptions.
>>>> 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.
>
> Each sibling has the same method names inherited from the same parent class,
> which means that I can use the same method name on any sibling. Using the
> same name method name on a number of different objects qualifies as
> polymorhism - same interface, different implementation.
>
Polymorphism does not relate to siblings. Only to parent/child
relationships.
> <snip>
>>> 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.
>
> What do you mean I can't defend my code? I have done nothing BUT defend my
> code for almost all of this thread.
>
> The OP asked if it were possible to create an HTML form to maintain the
> contents of a database table without having to write lots of code. I said
> that this could be done with the open source Radicore framework as this was
> specifically designed to deal with database tables, and can generate a
> series of default HTML forms without the need to write any code whatsover.
> Coding is only required when you want to change the defaults.
>
> You have done nothing but state that my framework works differently from
> your framework, therefore my framework must be crap.
>
> My framework does everything that I claim it does and is available as open
> source for anyone to download and evaluate.
>
> Your framework is not available as open source, so nobody can judge whether
> it works or not, let alone is better than anyone else's. You have not
> provided any code samples at all to back up your claims, so I can only say
> that without any proof to the contrary that all your claims are totally
> unfounded and without substance.
>
I have kept stating that your framework is crap, and it is. You are a
perfect example of why PHP programmers have such a poor reputation
amongst good programmers.
>>>> 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.
>
> Yes it does, and has done for years. You can visit the demo radicore
> application at http://www.radicore.org/demo.php and try it out for yourself.
>
> Where is the link to YOUR framework?
>
Absolutely of no consequence. The fact I do not want to waste my time
answering anal questions from the likes of you is my choice.
--
==================
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
]