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 #177907 is a reply to message #177887] Thu, 26 April 2012 11:45 Go to previous messageGo to previous message
Tony Marston is currently offline  Tony Marston
Messages: 57
Registered: November 2010
Karma:
Member
"Jerry Stuckle" <jstucklex(at)attglobal(dot)net> wrote in message
news:jn8qng$h7u$1(at)dont-email(dot)me...
<snip>
>> 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.

Incorrect. Data that is input into an object is validated before it gets
written to the database. It it fails the validation it doesn't get to the
database.

>>> 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.

Data normally comes from the user as a result of hitting SUBMIT on a form,
which means that it is presented to the script as the $_POST array.

>>> 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?

You did NOT ask the question "How can you update a field which was not
passed in via the $_POST or $_GET array?" Your question actually was "How do
you change a single property in the object without building the array?"
Considering that every page request automatically comes with either the
$_GET or $_POST array I do not have to "build" the array as it is already
there. If I want to I can add as many other values to the array as I want.

<snip>
>>>> > 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 definition 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.

Controlling access means changing a property's visibility from "public"
(visible) to "private" (hidden). A public property can be accessed directly,
whereas a private propery can only be accessed via a getter or a setter.

So, "controlling access" *DOES* mean hiding the data, and encapsulation
*DOES NOT* mean data hiding.

The original definition of encapsulation mentioned "implementation hiding"
which is *NOT* the same thing as "information hiding". I have posted several
links to articles written by other people, including Martin Fowler (the
autor of Patterns of Enterprise Architecture), who say the same thing.

>>>> > 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 never fail validation.

I have already told you that all input *IS* validated before it gets sent to
the database.

> 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.

When I chose to perform the data validation is entirely up to me. I do not
input data one field at a time using a setter, therefore I don't validate
the field's contents within the setter. All the data is injected as a single
array, and I validate the entire contents array in a single call to my
validation object before it is passed to my data access object which updates
the database.

The fact that I do not perform this validation in exactly the same way as
you does not mean that my way is wrong. It is simply different.

> 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
>>>> them 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.

The definition of encapsulation is "The act of placing data and the
operations that perform on that data in the same class". That is exactly
what I do. The fact that *YOUR* definition has been expanded to include
other so-called "rules" is irrelevant. I am sticking to the original
definition.

> It doesn't properly use methods.

There is no rule as to how methods *SHOULD* be used, just that a class
contains the methods which can opeate on its data.

> A change in the database (i.e. changing a column name) requires changing
> the program.

If you change a column name in your database then some code *HAS* to change
somewhere. This applies to everybody's code, not just mine. And even to
yours (if you ever write any that is).

> It exposes the names of the table columns you're using.

So what? Using the same column names in your screen that appear in the
database is not wrong. In my long career if anyone suggested using different
names they would be fired for stupidity.

> I could continue, but I know you'll discount everything I say.

At last you've said some with which I can agree.

> Crap programmers do that when informed why their code is crap.

The fact that *YOU* think my code is crap does not concern me in the least
as I place absolutely no value on your opinions.

> Good programmers try to learn.

You can't learn anything from a bad teacher.

<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?

Such changes to the database structure would require changes in anybody's
code, even yours. That is an inescapable fact.

<snip>
>> 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.

But I don't have to use a setter to validate data, I can validate it
whenever and however I want. I don't inject variables one at a time using
setters, so I don't validate it in the setter. I inject all the data as a
single array, and I validate the entire contents of the array with a single
call to my validation object before it is sent to the database.

> 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.

You are now adding unecessary complexity, so I shall not waste my time
explaining how I would deal with such a scenario.

<snip>
>>> 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.

There is nothing in the definition of encapsulation which dictates when and
how the data is validated. How I choose to do it and when I choose to do it
is *MY* choice, not yours.

>> <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 put that variable directly into the class instead of its data array
then it will be ignored simply because all the table objects use a single
array for all the table data.

>> 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.

It should be obvious to anyone that if you inject a piece of data into an
object using the wrong name then the object will ignore that data. The
object is coded to look for data with particular names, so if you use the
wrong name the fault is yours and not the object's.

> Or how about:
>
> $object = 'Really crap!';

Now you are being silly!

>> <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.

Not in the table object, only in the data access object. And it is *NOT*
split so that it can be injected into the object one piece at a time using
setters.

>>> 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.

How and when input data is validated is irrelevant. It is only important
that it *IS* validated.

> 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.

I repeat, how and when input data is validated is irrelevant. It is only
important that it *IS* validated.

>>>> > 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.

Controlling access means changing a property's visibility from "public"
(visible) to "private" (hidden). A public property can be accessed directly,
whereas a private propery can only be accessed via a getter or a setter.

So, "controlling access" *DOES* mean hiding the data, and encapsulation
*DOES NOT* mean data hiding.

The original definition of encapsulation mentioned "implementation hiding"
which is *NOT* the same thing as "information hiding".

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.
>>
>>> 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.

Polymorphism requires that different objects have the same interface (method
names). All siblings (i.e. subclasses which all inherit from the same
superclass) inherit all the method names from the superclass, so the same
method names are available in all the siblings. So, because the same method
names can be used on *ANY* of the siblings you automatically have
polymorphism.

--
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: Tue Nov 26 15:09:33 GMT 2024

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

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