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 #177873 is a reply to message #177869] Wed, 25 April 2012 08:23 Go to previous messageGo to previous message
Tony Marston is currently offline  Tony Marston
Messages: 57
Registered: November 2010
Karma:
Member
"Thomas 'PointedEars' Lahn" <PointedEars(at)web(dot)de> wrote in message
news:1430094(dot)ghCgKLUCYl(at)PointedEars(dot)de...
> 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.

That is exactly how my framework works. Each transaction has its own screen
format and possibly requires a different SELECT statement. Each transaction
has its own menu button, so all the user has to do is to press a menu button
in order to run the transaction associated with that button. The user does
not press a button to run a transaction and then have to press another
button to decide which output format he wants.

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

Encapsulation does not mean data hiding. Just because some programmers have
decided that it should, therefore properties should not be public and only
accessible through getters and setters is irrelevant.

Encapsulation does not mean data hiding. I do *NOT* have to hide all the
properties, and I do *NOT* have to use getters and setters.

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

Incorrect. My table object will reject that value before it is passed to the
data access object, and it is the data access object which generates and
executes the SQL query.

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

All that code sounds like bloat to me. I achieve the same result, but with
less code, so I like my method better.

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

How is it harder? I have an array of data and I validate the entire contents
of the array with a single call to my validation object. Surely it can't be
simpler that?

> 2. It is counter-MVC, for the model object is
> supposed to hold only valid data in the first place.

Who says so? Where in any description of the MVC does it say that all data
must be validated BEFORE it gets injected into the model. The only
universally accepted rule is that data must be validated BEFORE it gets
written to the database.

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

By "allowed to " I mean "not prevented". No programming language can ever
prevent a crap programmer from writing crap code. It all comes down to the
skill of te individual programmer.

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

It is not possible to define every possible rule as data in the database so
it can be retrieved and executed at runtime. The execution of business rules
requires code, not data (ask Jerry about validating password rules).

<snip>
> So you are allowing direct, unchecked access. Bad idea.

How so? The line $object->foo = 'bar' achieves the same result as
$object->setFoo('bar'). The contents of $foo are validated before the data
gets written to database, so where's the problem?

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

Encapsulation does not mean information hiding.

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

So how do you prevent such a catastrophe in your code?

--
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 06:20:44 GMT 2024

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

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