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 #177864 is a reply to message #177863] Tue, 24 April 2012 16:54 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: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".

Again, it was _not_ a statement, it was a question.

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

Will you *please* fix your quoting style?

> The array values are always strings.

No, the array _element_ of $_POST and $_GET arrays may easily be an array
itself with any non-trivial HTML form. PHP supports HTML form controls with
the name suffix `[]', where the value of all controls with the same prefix
are arranged in an array.

> What comes in via the $_GET or $_POST array is always a string,

Wrong.

> and what I write into the SQL query is always a string.

So much the worse. What about code injection and Prepared Statements?

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

I seriously doubt that.

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

No, there is just extensive research on OOP, common sense, and experience.

> so I don't have to.

You also don't have to look to the left and right before crossing a busy
street.

> By passing in a collection of values as an array instead of its individual
> components

Same fallacy as before.

> one at a time I use less code, and less code to achieve a given
> result is supposed to be better.

No; less code, faster code or less memory-consuming code is not necessarily
better code.

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

You are mistaken. Look up "false dichotomy", please.

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

Your model objects surely appear to have data access methods, most notably
insertRecord().

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

You implied it.

> I said that I never had to write any code to validate user data as that is
> automatically taken care of by te ramework.

I think the point was not that code is generated, but that validation takes
place.

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

Still with that approach you have to change the *business* logic (not
database access logic) of the application if you change the database and
vice-versa. There is no layer in-between that allows for transparent access
and, therefore, easy adjustment.

> The fact that the field names on the screen are the same as column names
> in the database is irrelevant.

You are very much mistaken.

> Only a masochist would use different names

Or a person considering the limitations of browsers and databases, and the
exploits that can follow from exposing server-side structures as-are to the
client.

> because it would then require a data mapper to translate the names.

Which is the sensible thing to do, believe it or not.

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

You are still winding around the issue.

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

You are missing the point. If someone passes in a request array a value
with a key that matches an *existing* database field that you usually would
not want to have updated, the field would be updated anyway because your
insertRecord() method cannot tell that this field should not be updated at
this time. Whereas "updated" refers to all updates of or requests from the
table, not only UPDATE queries.

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

You should know that "Show me where it breaks" is a typical luser's reply.
I have told you where and basically how, given your description, the
approach presents a vulnerability. It would be up to you to verify that.

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

ISTM you are still thinking too linear. There is no inherent connetion
between the two result values. But I was talking about table *relations*.

If the user of the model has to rebuild the relations of a model with
another models in their code, then that is surely a poorly designed model in
any sense of the "M" in MVC, one that does not scale well on top of that.

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

[x] done

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

OK. How does that look like?

--
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: Tue Nov 26 21:59:32 GMT 2024

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

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