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 #177834 is a reply to message #177824] Mon, 23 April 2012 12:50 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:16487873(dot)YAfrjsNhc7(at)PointedEars(dot)de...
> 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. 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. This does not require any code to be written by the
programmer as the standard validation class uses the field specifications
which were exported from my data dictionary which in turn were imported from
the database schema. If any validation fails then an error message is
generated and control returned to the calling object. It is only after the
data has passed all validation rules that it is passed to my data access
object where the relevant sql INSERT statement is constructed and executed.

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.

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

Just because a lot of OOP tutorials show the use of getters and setters does
not mean that I *HAVE* to use them. 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.

> 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. All
the table data passes both in and out as a single array variable which can
contain any number of rows and columns.

Within my table object I can reference any column property with

$this->fieldarray['column1']

just as easily as I can with

$this->column1

This means that I don't need a separate class variable for each column,
which in turn means that I don't ned a separate getter and setter for each
column.

<snip>
>
>>> 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. I wrote the validation class years ago, and it compares
the fielddata array with the contents of the fieldspec array. The fieldspec
array defines how each field is to be validated. The fieldspec array does
not have to be coded by the programmer as it is generated by the framework
using details which were originally extracted from the database schema.

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

>> I was never dishonest about the Radicore framework. I never said it was
>> written by someone else. I even include a link to the radicore website in
>> my signature.
>
> I am going to look into it, then.
>
> --
> PointedEars

I would welcome constructive criticism.

--
Tony Marston

http://www.tonymarston.net
http://www.radicore.org
[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: Fri Nov 22 20:03:39 GMT 2024

Total time taken to generate the page: 0.07077 seconds