| Re: Dynamic form generation [message #177867 is a reply to message #177864] |
Tue, 24 April 2012 17:55   |
Tony Marston
Messages: 57
Registered: November 2010
Karma:
|
Member |
|
|
"Thomas 'PointedEars' Lahn" <PointedEars(at)web(dot)de> wrote in message
news:6244670(dot)rdf3491b2I(at)PointedEars(dot)de...
<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.
It was a statement with a question at the end, as in "you perform no type
conversion or checking, or range checking in the application, yes?"
The question part was "yes?", meaning "is this statement true". I answered
"incorrect", meaning "the statement is not true".
Did you not study Engish grammar at school?
>>>> 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?
No.
>> 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.
So, an array element may be a string or an array of strings. The resulting
values are still strings eventually.
>> What comes in via the $_GET or $_POST array is always a string,
>
> Wrong.
So an array element may be a string or an array of strings. What's the big
deal? The lowest-level values are still strings!
>> and what I write into the SQL query is always a string.
>
> So much the worse. What about code injection and Prepared Statements?
I don't use prepared statements, and I don't have to use prepared statements
to avoid code injection.
>> 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.
You can doubt it as much as you like. But I have copies of my data in a
MySQL database, a PostgreSQL database, an Oracle database, and a SQL Server
database, and the same application can be switched from one to the other
with a single change to a config file.
You can download my radicore framework and try it out for yourself if you
don't believe me.
<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.
Just because a lot of prgrammers do something does not make it the "right"
way.
>> so I don't have to.
>
> You also don't have to look to the left and right before crossing a busy
> street.
Stop changing the subject.
>> 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.
>
> No; less code, faster code or less memory-consuming code is not
> necessarily
> better code.
Where is your proof that passing in a collection of data as a single array
instead of passing in then component parts one at a time is not 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.
>
> You are mistaken. Look up "false dichotomy", please.
According to http://en.wikipedia.org/wiki/False_dilemma it means choosing
between only two possibilities when there may be more than two. I never said
that there were only two choices, only that my choice is obviously different
from yours.
>> <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().
But the insertRecord() method in my table object does not update the
database. To do that it calls the insertRecord() method on a separate data
access object. It is the DAO which actually updates the database, not the
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.
>
> You implied it.
No I didn't. 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 the framework.
>
> I think the point was not that code is generated, but that validation
> takes
> place.
Correct. Data validation takes place without the programmer having to write
any code.
<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.
I only have to change the business logic for a field if the existing logic
becomes invalid after changing the database structure. You would have to do
that in *ANY* application irrespective of how it was written or what
framework it uses.
>> 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.
How so?
>> 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.
How does using the same data names on the screen and the database cause a
problem?
>> because it would then require a data mapper to translate the names.
>
> Which is the sensible thing to do, believe it or not.
Only in your universe. Intelligent programmers don't use different names in
different parts of the system, therefore don't need mappers.
>> Coding changes are usually only required when a business rule changes.
>
> You are still winding around the issue.
What was the issue again? You keep losing me with your ridiculous arguments.
>>> 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.
My framework updates using whatever data it is given.
How does your framework solve this so-called problem?
>>> 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.
No. If you think that there's a vulnerability in my code then it's up to you
to prove it. Put Up or Shut Up!
>>> 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*.
You asked me how I could update several tables with one set of data, and I
have shown you how. The relationshop between tables A, B and C is
irrelevant.
> 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.
You are talking nonsense.
>> 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?
Surely you know what a SELECT statement with JOINS looks like?
--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]