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 #177876 is a reply to message #177870] Wed, 25 April 2012 09:04 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: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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--
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: Sat Nov 23 01:13:21 GMT 2024

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

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