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 #177863 is a reply to message #177861] Tue, 24 April 2012 16:11 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:1400277(dot)AFRqVoOGUt(at)PointedEars(dot)de...
> Tony Marston wrote:

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

I answered "incorrect" to the statement "you perform no type conversion or
checking, or range checking in the application".

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

The array values are always strings. What comes in via the $_GET or $_POST
array is always a string, and what I write into the SQL query is always a
string.

I can switch my database between MySQL, PostgreSQL, Oracle and SQL Server,
and I tend to design my databases using common data types, so I never have
any problems.

<snip>
>> 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 repeat, there is no rule that says I must/should use getters and setters
for each of my column values, so I don't have to. By passing in a collection
of values as an array instead of its individual components one at a time I
use less code, and less code to achieve a given result is supposed to be
better.

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

You reason is no more than "that is what I have been taught, and you are not
allowed to be different". I choose to be different when different is better.

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

Neither are they in mine. My data acess object is totally separate from each
table object.

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

I never said that my validation class was not part of my framework. I said
that I never had to write any code to validate user data as that is
automatically taken care of by te ramework.

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

Not all database changes require a programmer to change any code. In a lot
of cases it is a simple matter of re-importing into the data dictionary and
then re-exporting to regenerate the table structure files.

The fact that the field names on the screen are the same as column names in
the database is irrelevant. Only a masochist would use different names
because it would then require a data mapper to translate the names.

Coding changes are usually only required when a business rule changes.

> 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 incorrect assumption. The UPDATE query is edited (by standard code,
naturally) to include only those columns which have actually changed.

> An attacker could use that vulnerability to
> manipulate your database through the application in ways that you cannot
> conceive yet.

Prove it. An example of my framework is available at
http://www.radicore.org/demo.php. Break it if you can.

> This approach also does not appear to account for the possibility that
> with
> one request several tables need to be updated.

Easy peasy. Let's suppose a particular INSERT requires data to be added to
TableA, TableB and TableC. I would start by sending all the data to the
primary table with the statement:

$result - $tableAobject->insertRecord($_POST).

After validation it would create the relevant INSERT query for tableA. It
would automatically filter out any field names which do not exit in that
table.

In the _postInsertRecord method of TableA's class I would have the
following:

$result = $tableBobject->insertRecord($data);
$result = $tableCobject->insertRecord($data);

Where $data at this point is the validated version of the original $_POST
array.

Note that I never have to remove from the $data array those field names
which do not belong in that table as they are automatically filtered out.

This method is ridiculously simple yet ridiculously effective, but I expect
that you'll find a way to tell me that it's wrong.

> Apropos, how you do
> implement queries across several tables (JOINs) with your framework?

SELECT statements can have the necessary JOINS added in automatically by the
framework using information which was exported from the data dictionary. It
is also possible to override the default query with whatever your heart
desires.

--
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 00:43:53 GMT 2024

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

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