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 #177865 is a reply to message #177818] Tue, 24 April 2012 17:21 Go to previous messageGo to previous message
Tony Marston is currently offline  Tony Marston
Messages: 57
Registered: November 2010
Karma:
Member
"Jerry Stuckle" <jstucklex(at)attglobal(dot)net> wrote in message
news:jn13eu$4ll$1(at)dont-email(dot)me...
<snip>
>>> And you completely miss the question. How do you change a single
>>> property in the object without building the array?
>>
>> BECAUSE THE ARRAY IS ALREADY INSIDE THE OBJECT, YOU IDIOT!!! I don't
>> need code inside the table object to build the array as it is supplied
>> as an array, either from the $_GET or $_POST array, or an array of rows
>> and columns from the database.
>
> So, IOW, you can't change a single property from the program. You can't,
> for instance, set just the ship date in an order. You can only set the
> entire object. How stupid.

If I have a transaction where the only value that can be changed in the ship
date for an order, then the $POST array will contain "ship_date = whatever".

My update controller has the line $dbobject->updateRecord($_POST) where
$dbobject is an instance of the order class.

The order class, as with every other table class in my system, will perform
an update operation using the contents of its input array however many
fields it contains. It does not matter whether it contains 1 field or 100
fields, it's all the same.

Why can't you understand such a simple concept?

>>> From the number of times you have ducked the question, my only
>>> assumption can be the program can't change a single property in the
>>> object.
>>
>> Changing a property inside an object is as simple as changing a value in
>> an array.
>
> Oh, so all of your variables are public? How stupid is that? It violates
> the first rule of OO programing - encapsulation.

Encapsulation does not mean data hiding.

> So you're saying I can say
>
> $object->ship_date = 9999-12-31. Or even
>
> $object->ship_date = "This is completely stupid but OK according to Tony".

I've already told you that I don't have a separate class property for each
column in the table. All the table data is held in a single array, so
instead of

$object->ship_date = '9999-12-31'
you would have to use
$object->fieldarray['ship_date'] = '9999-12-31';

Such duff data would never make it to the database anyway as it would fail
the validation.

> Proper OO programming doesn't allow such crap programming.

OO does not prevent programmers from writing crap code. It just allows then
to generate a different class of crap.

<snip>
>>> Your way is plain bloat.
>>
>> Validating that date fields contain dates, numeric fields contain
>> numbers and NOT NULL fields are not empty is never something that a user
>> can change because it is standard validation, which is why I put all the
>> necessary code in a standard validation class years ago. This means that
>> in my framework, unlike yours, I never have to write a line of code to
>> perform standard validation.
>
> Only you would think instantiating an object to ensure a value is really
> an integer is better than just calling intval(). Bloat, bloat, bloat.

I don't instantiate my validaton object for each individual value, I do it
just once to validate the whole array of values.

>> If a customer requires an additional rule, such as comparing dates on
>> one database table with dates on another, then that is non-standard, is
>> not covered by the standard validation class and will therefore require
>> a programmer to write some code.
>>
>
> With proper OO principles, the object requiring the rule implements the
> rule.

But the rule has to be coded within the relevant class.

>>> More bloat. No, the intval() function call is inherent to the set()
>>> function.
>>
>> I don't have separate setter and getter functions for each column on a
>> table.
>
> Yea, you allow people to set the variables directly (see above). A direct
> violation of the most basic OO principle.

I don't have separate getter and setter functions for each entry within the
array because the data goes in and out as an array.

> Having instantiate the object just to ensure a value is an integer when a
> simple call to intval() does the same thing is bloat.
>
> But then you don't validate things set by the program, because you don't
> understand encapsulation.

I understand encapsulation very well. The validation rules for the person
entity are defined within the person class. When I call the validation
object I give it two variables - the array of field values and the array of
field rules. The validation object will then verify that each field's value
conforms to its rules.

>>>> Again you are writing code to do something which my framework does
>>>> automatically. And you have the nerve to say that my methods are crap!
>>>
>>> Nope, my framework automatically handles simple rules based on
>>> datatypes. If I need more complex rules, they are easy to enter.
>>
>> That's exactly how my framework works, but I achieve the same result by
>> different means. You seem to think that simply because my methods are
>> different that they are automatically wrong. What an arrogant person you
>> are!
>>
>
> So tell me - how do you prevent
>
> $object->ship_date = "This is stupid!";

Because the validation rule for the field called "ship_date" is that it be a
date, so the value "This is stupid!" will be rejected.

<snip>
>>> Nope, you brought up the subject of allowing the customer to change
>>> the rules.
>>
>> Only the password validation rules.
>
> And I asked why, when you implemented a function no one else in the world
> has found a need for, haven't you implemented a function that millions of
> people want and need?

That question is orthogonal to the subject of this thread, so I shall ignore
it.

<snip>
>>>
>>> Yes? So how do you display the same data in different formats then?
>>
>> I have a different transaction based on a different transaction pattern,
>> one to output HTML, another for PDF and another for CSV.
>
> I asked how do you display the same data in different formats, not
> different media. But you can't do that, can you?

Read on, MacDuff.

>> If it is necessary to have the HTML output displayed differently under
>> different circumstance then I would still have a separate transaction
>> with each having its own screen structure file.
>
> Gee, sounds like you have to create a lot of code to just do something as
> simple as displaying the same information in a slightly different format.
> My way is easy and can be done very quickly.

You're missing the point again. If you want to have the data from the same
table displayed in one of several different formats then you need a
mechanism for the user to choose which format he wants. I do that my having
a separate transaction, with its own menu button, for each format.

The only different coding that would be required would be in a small screen
structure file, and that would be also be quick and easy.

> I never said anything of the type. I said I had a function which took the
> input from $_GET or _$POST and processed it. I also said I had getter and
> setter functions.

Youn said that you had a function which took the $_GET or $_POST array,
split it into its component parts so that you could use a setter on each
part.

The fact that the function accepts an array as its input is irrelevant as
you are still spliting the array into its component parts.

> The lack of getters and setters means your variables must be public, which
> violates the first principle of OO programming - encapsulation.

Encapsulation does not mean data hiding.

>>> That's right. That's an implicit part of OO (encapsulation).
>>
>> Using getters and setters has nothing to do with encapsulation.
>
> Only in the alternate universe of Tony Marston. You really should try
> reading a book on OO by a recognized expert in the field. Booch would be
> a good start.

There are many others who also think that encapsulation does NOT mean data
hiding. take a look at the following:

http://www.javaworld.com/javaworld/jw-05-2001/jw-0518-encapsulation.html
http://www.itmweb.com/essay550.htm
http://homepage.mac.com/keithray/blog/2006/02/22/ - the 2nd paragraph titled
"Encapsulation Wasn't Meant To Mean Data Hiding" written by martin Fowler.

>> <snip>
>>> But unlike you, I can get or set a single property, also, as needed.
>>> Something I do all the time.
>>
>> In my implementation of MVC neither the Controller nor the View *EVER*
>> needs to obtain a single column value by its name. They only ever deal
>> with an array of rows and columns, and they don't care what the array
>> contains. That is why my implementation has a small number of
>> Controllers and Views which are reusable.
>
> Which doesn't answer my question. But then you've already answered it.
> You don't even understand the basic OO concept of encapsulation.

The fact that my controllers and views do not use getters and setters on
named items has nothing to do with encapsulation.

>>> Once again you show you have no knowledge of OO. Polymorphism cannot
>>> exist without inheritance - which requires a parent/child hierarchy.
>>
>> Yes it can. Polymorphism simply requires that the same interface exist
>> in more than one class. That may come from inheritance, or it may not.
>> It *IS* possible to define the same interface more than once without
>> inheritance.
>
> It's not surprising you claim this.

It is not a claim it is a fact that it is possible to have the same
interface in more than one object WITHOUT inheritance.

> When you don't even understand encapsulation, no one should expect you to
> understand a more advanced concept like polymorphism.

My understanding of the concepts of OO are documented in
http://www.tonymarston.net/php-mysql/what-is-oop.html#what.is.an.oo.languag e

>>> I've used them much longer than you've even known they existed. When
>>> you have a class derived from the abstract class, there is a
>>> parent/child relationship. But there is no such relationship between
>>> two classes derived from the same one.
>>
>> Each one of the 200 concrete table classes in my application is derived
>> from the same abstract table class, so each one of those 200 classes is
>> a sibling of the other, and "sibling" implies a relationship.
>
> So there is a sibling relationship? Once again you prove how you don't
> understand the concept of polymorphism.

Each sibling has the same method names inherited from the same parent class,
which means that I can use the same method name on any sibling. Using the
same name method name on a number of different objects qualifies as
polymorhism - same interface, different implementation.

<snip>
>> But you don't like your methods to be criticised, do you? You seem to
>> think that anybody whose methods are different from yours is
>> automatically an incompetent moron.
>
> Nothing of the sort. But then it's pretty common of you - you can't
> defend your code so you attack the messenger.

What do you mean I can't defend my code? I have done nothing BUT defend my
code for almost all of this thread.

The OP asked if it were possible to create an HTML form to maintain the
contents of a database table without having to write lots of code. I said
that this could be done with the open source Radicore framework as this was
specifically designed to deal with database tables, and can generate a
series of default HTML forms without the need to write any code whatsover.
Coding is only required when you want to change the defaults.

You have done nothing but state that my framework works differently from
your framework, therefore my framework must be crap.

My framework does everything that I claim it does and is available as open
source for anyone to download and evaluate.

Your framework is not available as open source, so nobody can judge whether
it works or not, let alone is better than anyone else's. You have not
provided any code samples at all to back up your claims, so I can only say
that without any proof to the contrary that all your claims are totally
unfounded and without substance.

>>> Nope. I didn't say my way was the only way. I said my way works, does
>>> not contain bloatware and follows recognized OO practices. All you can
>>> claim is yours works.
>>
>> My way works just as your way works. As for "recognised OO practices"
>> there is no single set of practices which is recognised by every single
>> programmer on the planet. Different groups recognise different
>> practices, and I just happen to belong to a different group than you do.
>
> No, your way doesn't work.

Yes it does, and has done for years. You can visit the demo radicore
application at http://www.radicore.org/demo.php and try it out for yourself.

Where is the link to YOUR framework?

--
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 01:09:16 GMT 2024

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

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