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 #177861 is a reply to message #177834] Tue, 24 April 2012 09:10 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:

> "Thomas 'PointedEars' Lahn" <PointedEars(at)web(dot)de> wrote in message
> news:16487873(dot)YAfrjsNhc7(at)PointedEars(dot)de...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Please don't, see below.

>> Tony Marston wrote:
>>> "Jerry Stuckle" wrote:
>>>> On 4/18/2012 4:33 AM, Tony Marston wrote:
>>>> >> If a framework attempts to be "all things to all people", then that's
>>>> >> quite true. But the same is true of *any* code.
>>>> >>
>>>> >> However, a limited framework with limited goals doesn't necessarily
>>>> >> have to be the case.
>>>> >>
>>>> >> For instance, in my case - I have a framework which builds PHP
>>>> >> classes to interface to a database. It generates a lot of usable code
>>>> >> for those classes, including form handling.
>>>> >
>>>> > So you framework generates "a lot" of code, does it? My framework
>>>> > generates very small amounts of code which call shared functions or
>>>> > which inherit code from abstract classes.
>>>>
>>>> Yup, for instance, it generates all the set and get methods for the
>>>> applicable class, as well as database access code (insert/update/delete
>>>> for single rows and single rows and lists of multiple rows for SELECT).
>>>> (Most of the access code is in parent classes).
>>>
>>> My framework does not bother generating set and get methods as they are
>>> inefficient. Data goes in and comes out as an array.
>>
>> This means that you perform no type conversion or checking, or range
>> checking in the application, yes?
>
> Incorrect.

It is a yes-or-no question, therefore it cannot be incorrect.

> If my ADD controller contains the line $result => $dbobject-
> insertRecord($_POST); then the entire $_POST array is passed to
> that object. I do not have to break it down into its compnent parts and
> inject each component individually. The contents of the array is then
> validated by the framework to ensure that all columns maked as NOT NULL
> are not empty, all date fields are dates, all numeric fields are numbers
> and within range, et cetera. […]
> Just because I say that the programmer does not have to write code does
> not mean that the data is never validated. It always is, but as an
> automatic function of thre framework.

I see. How do you account for data types in the array that are not provided
by the respective database engine?

>> Setters and getters maybe are less
>> efficient than direct access, but they can provide that functionality.
>> They
>> also provide transparent access to the data model (i. e., if either your
>> requests or your database change, you do not have to change the request
>> for
>> the database or the database for the request; you just change the mapping
>> code). Using arrays does not exclude the possibility for using setters
>> and
>> getters or vice-versa, as setters and getters can be called implicitly,
>> such
>> as from a constructor.

Your quoting (not corrected here for once) sucks big time. The options you
have now are to learn to work around the shortcomings of your newsreader,
use a working one, or be ignored.

<http://insideoe.com/>

> Just because a lot of OOP tutorials show the use of getters and setters
> does not mean that I *HAVE* to use them.

No, it means that this is strong indication that there are good reasons that
you SHOULD use them (I leave it to you to find out what those reasons are;
this newsgroup is not OOP 101). Especially as PHP (by contrast to Java, for
example) provides convenient transparent access to non-public properties
with the __set() and __get() magic methods.

> I don't see why I should pass in a collection of values using multiple
> setters when I can achieve the same result by passing in the entire
> collection as a single array variable.

That is a false dichotomy, as I have explained already.

>> In the MVC-based framework I have written for my latest research, the
>> parent
>> abstract `AbstractModel' class has an inherited public map() method that
>> can
>> be passed an associative array (such as from a query result) and maps
>> array
>> elements to object properties such that either all, only the specified or
>> not the specified elements in the passed array are mapped.
>
> My database table objects do not have a separate property for each column
> within that table, so I don't need getters and setters for each column.

But in MVC, models are not data access objects.

>>>> It also generates the code necessary to validate a field. Some stock
>>>> fields (like "must be integer") have predefined validation functions.
>>> My framework does not generate any code to perform basic field
>>> validation as that is performed by a validation class which I wrote
>>> years ago.
>> So that validation class has become part of the framework, has it not?
>
> Absolutely correct.

(See above.)

So your argument that the validation class is not part of your framework is
effectively void.

>>>> It also has a function to populate the object from $_GET or $_POST
>>>> values
>>>> (with validation).
>>> I don't need a whole function to do that when a single line will do:-
>>> $result = $object->insertRecord($_POST);
>>> This means that the same line will work on any object regardless of
>>> which class it came from. That is what polymorphism is all about.
>> It also means that your HTTP POST requests are inherently bound to the
>> structure of the database (table), does it not?
>
> Why? The $_POST array is simply an associative array, and the only thing
> it is "bound" to is the HTML form which generated it. If the $_POST array
> contains any field names which do not exist in the database table then
> those fields simply will not appear in the sql query which is generated.

AIUI, the keys of the elements of the $_POST array must match that of the
field names in the database as far as they exist in the database then.
Therefore, if you have to change the application logic or if you have to
change the database, you have to change the other part.

Moreover, if at some point you do _not_ want to update a field, but the
$_POST array contains an element with a key matching a field, that field
will be updated anyway. An attacker could use that vulnerability to
manipulate your database through the application in ways that you cannot
conceive yet.

This approach also does not appear to account for the possibility that with
one request several tables need to be updated. Apropos, how you do
implement queries across several tables (JOINs) with your framework?

--
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:45:02 GMT 2024

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

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