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 #177887 is a reply to message #177876] Wed, 25 April 2012 12:29 Go to previous messageGo to previous message
Jerry Stuckle is currently offline  Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
Senior Member
On 4/25/2012 5:04 AM, Tony Marston wrote:
> "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message
> news:jn71ur$o4l$1(at)dont-email(dot)me...
>> 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!
>
> You question was not "how can you set a value which was not included in the
> $_POST array?"
>
> If I have a transaction whose function "set the ship_date to today for all
> selected orders" then all it has to work on is an array of order numbers. I
> would iterate through this array using code similar to the following:
>
> foreach ($order_array as $order) {
> $order['ship_date'] = $today;
> $orderObject->updateRecord($order);
> }
>
> See? Neat and tidy,clean and simple.
>

Yup, and I see that you could just as easily say

$today = 'this is crap';
foreach ($order_array as $order) {
$order['ship_date'] = $today;
$orderObject->updateRecord($order);
}

And it will try to do it just fine - until it comes time to perform the
actual update.

Or even
$today = '2099-12-31';
<same as above>

And it will very happily do it.

>> 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?
>
> That is not the question you asked, therefore it is not the question I
> answered.
>

Sure it was. You just can't understand such a simple question. Or you
evaded it on purpose. Which was it?

>>>> >> 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.
>
> Encapsulation does not mean data hiding. Encapsulation does not mean
> controlled access to data. The defintion of encapsulation does not require
> that either methods or properties have their access limited in any way
> whatsover.
>

You're the only one who claims it is data hiding. It DOES mean
controlling access to the data.

Otherwise why even have encapsulation? What is its purpose?

>>>> 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?
>
> I have already explained that I validate the entire contents of the input
> array with a single call to my validation object before any data gets
> written to the database. Any validation errors cause the table object to
> immediately return to the controller so that the screen can be redisplayed
> with the error message so that the user can correct his error and re-submit.
>

According to your own comments, such a construct will never be
validated, so it will fail validation.

And validating something hundreds of thousands of lines after it has
been set to an incorrect value is almost worthless. It should be done
at the time of the error.

But I also understand that's not a problem for you because you've never
written a complicated program. Just simple database access stuff.

>>>> 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.
>
> How is my design improper? I ensure that all user input is validated before
> it gets written to the database, and I can do so without the programmer
> having to write a single line code.
>

It doesn't implement encapsulation. It doesn't properly use methods. A
change in the database (i.e. changing a column name) requires changing
the program. It exposes the names of the table columns you're using.

I could continue, but I know you'll discount everything I say. Crap
programmers do that when informed why their code is crap. Good
programmers try to learn.

> <snip>
>>>> 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.
>
> Exactly, and that is what my framework achieves. The business rules for each
> entity are coded within the entity's class.
>

And changes to the database require changes to your code. What happens,
for instance, if you change the name of the column 'ship_date'?

Or if you change it to three columns - ship_month, ship_date, ship_year?

> <snip>
>>> 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.
>
> So how is $this->foo = 'bar' or $this->setFoo('bar') any different from
> $this->fieldarray['foo'] = 'bar'? You still have to have a line of code
> which says "set the value of 'foo' to 'bar'". They are just different
> instructions which achieve the same result. You still have to know that the
> table object has a column called 'foo', so how does this expose the internal
> workings of the class?
>

Because $this->setFoo('bar') validates the data right then. And the
table column may or may not be called 'foo', and the internal object may
or may not be called 'foo'. In fact, the table object may be three
different columns. for instance.

>>>> 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.
>
> Encapsulation has nothing to do with data validation.
>

Encapsulation has EVERYTHING do do with ensuring valid data.

> <snip>
>>>> 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.
>
> If you try the line $object->ship_date = "This is stupid!"; then you are not
> updating the data array, and it is the data array which is used to update
> the database. This means that your line of code will achieve nothing as the
> property 'ship_date' will never be referenced anywhere.
>

OK, so you say $object->['ship_date'] = "This is stupid!";

But I know you're too stoopid to understand the concept, even if the
actual statement isn't updating the array.

Or how about:

$object = 'Really crap!';

> <snip>
>>> 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.
>
> In my framework the data array is never split into its component parts until
> it appears in the data access object where the SQL statement is constructed
> and executed.
>

So? It has to be split.

>> 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.
>
> Irrelevant. All input is validated before it gets written to the database.
> How I validate and when I validate is irrelevant.
>

Completely relevant, if you're writing a complex program. But you've
never done anything complex, so you wouldn't understand.

In a complicated program the invalid value may be set thousands of lines
before you actually update the database. The error should be detected
when the value is set, not much later.

>>>> 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.
>
> Incorrect. It is *YOU* who keeps saying that I must use getters and setters
> because I should not access an object's properties directly (i.e. the
> properties should be hidden)
>

Which has nothing to do with data hiding. You're the only one who
brings 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.
>
> Incorrect. See above.
>

You're the only one who brings up data hiding.

> <snip>
>>> 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.
>
> If you have "same interface, different implementation" then you have
> polymorphism. The "same interface" can either be inherited or hard-coded.
>
> <snip>
>> Polymorphism does not relate to siblings. Only to parent/child
>> relationships.
>
> You are missing the point. All these siblings have the SAME PARENT therefore
> they inherit all the methods of the parent.
>

No, your understanding of polymorphism is just as bad as your
understanding of encapsulation. There is no polymorphism between
siblings. Only when you have a parent-child relationship.

> <snip>
>>>> 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.
>
> So you don't want to answer anal questions, but you spend your time asking
> them.
>

I'm not asking anal questions. I'm trying to teach a pig to fly. But I
know that's a waste of time. And calling you a stoopid programmer is an
insult to stoopid programmers everywhere.


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================

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: Tue Nov 26 21:57:34 GMT 2024

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

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