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 #177869 is a reply to message #177865] Tue, 24 April 2012 18:56 Go to previous messageGo to previous message
Thomas 'PointedEars' is currently offline  Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma:
Senior Member
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".

It will at least contain the name and value of a submit button (provided the
form was designed with accessibility in mind) as well, but that aside:

In order to make that work you have to have several forms in the HTML
document presenting order data, each which only contains the pertinent
controls (including a submit button), or you have to have to (attempt to)
modify the $_POST array *after* it has been populated by PHP.

However, the established and more sensible approach is to have, if feasible,
only *one* form with *one* `action' URI for one type of object and let the
application decide by the name or value of the submit button which data of
that form to process, and (with few exceptions) leave the request
superglobals as they are.

<http://www.php.net/manual/en/language.variables.external.php>

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

Correct. However, information hiding is a core principle not only in OOP
(and not just of an interpretation of OOP) that publicly accessible object
properties do violate; that makes encapsulation ineffective. For the
problem with such properties is that anyone can modify (and retrieve) them
from anywhere and, given loose and dynamic typing, in any way. There is no
type checking, range checking or access checking. This makes OO programs
less robust than they could be, and essentially results in a maintenance
nightmare because of a missing well-defined interface for the encapsulated
data.

<http://en.wikipedia.org/wiki/Information_hiding>

>> 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';

Now imagine that for some reason it happens that the equivalent of the
following is executed:

$object->fieldarray['ship_date'] = -42;

There is no range checking and no type checking here since PHP is loosely
and dynamically typed and there are no setters for array items. So the
error that has been made will not show up before the query is made, if that.
If instead you had the equivalent of

$object->ship_date = -42;

(which can be triggered by a mapper method from the constructor as I
explained), then that could call implicitly the equivalent of

get_class($object)::__set('ship_date', -42);

which could call

$object->setShip_date(-42);

declared as

public function setShip_date($value)
{
if ($value < 0)
{
throw new InvalidArgumentException(
'Error on ISO/OSI layer 8: Date values cannot be negative');
}

$this->_ship_date = $value;
}

then it would not be attempted to write an invalid value into the database
because the model forbids storing it in volatile memory in the first place.

> Such duff data would never make it to the database anyway as it would fail
> the validation.

AIUI your argument is that you do range checking before accessing the
database, but there are three problems with that approach: 1. It is harder
and less efficient to find invalid values later because the code is too
general at that point. 1. It is counter-MVC, for the model object is
supposed to hold only valid data in the first place.

>> Proper OO programming doesn't allow such crap programming.

ACK.

> OO does not prevent programmers from writing crap code. It just allows
> then to generate a different class of crap.

So your counter-argument is that you are allowed to write "crap code"?

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

No, your approach can be modified so that the model class uses requests
validation information from the database and uses it on assignment. Since
the information would apply to all object of a class and would not change
during the lifetime of the class, it would appear to be best to reuse static
class variables and perhaps the singleton pattern from the constructor for
this. IIRC it has been done before.

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

So you are allowing direct, unchecked access. Bad idea.

>> 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. […]

But apparently you do not understand the concept of information hiding;
without it, encapsulation is ineffective.

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

But until you access the database, the model object stores/refers to invalid
data. Whereas "invalid" includes "inconsistent" if related properties (or
in your case, array elements) are (inadvertently) modified through public
access in a way that the result is does not make sense, like

$object->data['order_date'] = '1942-02-29';
$object->data['ship_date'] = '2012-04-24';
$object->data['shipped'] = false;
$object->data['accepted'] = '2011-04-01';

Please do not tell me this cannot happen; I *know* it can.

> [tl;dr]

--
PointedEars

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: Sat Nov 23 00:59:06 GMT 2024

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

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