Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.php > #5471 > unrolled thread
| Started by | Charles <cchamb2@gmail.com> |
|---|---|
| First post | 2012-04-11 20:48 -0700 |
| Last post | 2012-04-13 15:27 +0200 |
| Articles | 20 on this page of 95 — 16 participants |
Back to article view | Back to comp.lang.php
Dynamic form generation Charles <cchamb2@gmail.com> - 2012-04-11 20:48 -0700
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-12 00:03 -0400
Re: Dynamic form generation The Natural Philosopher <tnp@invalid.invalid> - 2012-04-12 05:46 +0100
Re: Dynamic form generation Michael Vilain <vilain@NOspamcop.net> - 2012-04-11 21:52 -0700
Re: Dynamic form generation Denis McMahon <denismfmcmahon@gmail.com> - 2012-04-12 12:42 +0000
Re: Dynamic form generation Charles <cchamb2@gmail.com> - 2012-04-12 20:43 -0700
Re: Dynamic form generation Michael Vilain <vilain@NOspamcop.net> - 2012-04-12 21:55 -0700
Re: Dynamic form generation Denis McMahon <denismfmcmahon@gmail.com> - 2012-04-13 13:19 +0000
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-13 09:59 +0100
Re: Dynamic form generation Denis McMahon <denismfmcmahon@gmail.com> - 2012-04-13 13:22 +0000
Re: Dynamic form generation Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-17 14:49 +0200
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-17 11:36 -0400
Re: Dynamic form generation "Tony Marston" <TonyMarston@hotmail.com> - 2012-04-18 09:33 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-18 07:59 -0400
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-19 09:56 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-19 08:29 -0400
Re: Dynamic form generation "Tony Marston" <TonyMarston@hotmail.com> - 2012-04-20 09:27 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-20 07:47 -0400
Re: Dynamic form generation "Tony Marston" <TonyMarston@hotmail.com> - 2012-04-21 12:22 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-21 10:19 -0400
Re: Dynamic form generation "Tony Marston" <TonyMarston@hotmail.com> - 2012-04-22 11:45 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-22 10:09 -0400
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-24 18:21 +0100
Re: Dynamic form generation Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-24 20:56 +0200
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-25 09:23 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-24 16:20 -0400
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-25 10:04 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-25 08:29 -0400
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-26 12:45 +0100
Re: Dynamic form generation Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-22 19:21 +0200
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-23 13:50 +0100
Re: Dynamic form generation Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-24 11:10 +0200
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-24 17:11 +0100
Re: Dynamic form generation Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-24 18:54 +0200
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-24 18:55 +0100
[OT] Was: Dynamic form generation Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-04-25 13:22 +0200
Re: [OT] Was: Dynamic form generation The Natural Philosopher <tnp@invalid.invalid> - 2012-04-25 12:46 +0100
Re: [OT] Was: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-26 12:51 +0100
Re: [OT] Was: Dynamic form generation Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-04-27 10:26 +0200
[OT] Yes-or-no questions (was: [OT] Was: Dynamic form generation) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-28 07:56 +0200
Re: Dynamic form generation "Peter H. Coffin" <hellsop@ninehells.com> - 2012-04-14 08:53 -0500
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-15 08:33 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-15 08:51 -0400
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-16 09:31 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-16 08:33 -0400
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-16 15:11 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-16 11:18 -0400
Re: Dynamic form generation "Tony Marston" <TonyMarston@hotmail.com> - 2012-04-17 09:18 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-17 06:07 -0400
Re: Dynamic form generation "Tony Marston" <TonyMarston@hotmail.com> - 2012-04-18 09:10 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-18 08:09 -0400
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-19 09:27 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-19 08:41 -0400
Re: Dynamic form generation "Tony Marston" <TonyMarston@hotmail.com> - 2012-04-20 10:10 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-20 08:09 -0400
Re: Dynamic form generation "Tony Marston" <TonyMarston@hotmail.com> - 2012-04-21 10:35 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-21 06:21 -0400
Re: Dynamic form generation "Tony Marston" <TonyMarston@hotmail.com> - 2012-04-22 10:27 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-22 10:43 -0400
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-23 15:23 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-23 12:24 -0400
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-26 17:29 +0100
Re: Dynamic form generation The Natural Philosopher <tnp@invalid.invalid> - 2012-04-23 20:37 +0100
What Jerry Stuckle thinks of PHP programmers "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-23 14:10 +0100
Re: What Jerry Stuckle thinks of PHP programmers Paul Herber <paul@pherber.com> - 2012-04-23 14:22 +0100
Re: What Jerry Stuckle thinks of PHP programmers "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-23 15:27 +0200
Re: What Jerry Stuckle thinks of PHP programmers Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-23 09:33 -0400
Re: What Jerry Stuckle thinks of PHP programmers "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-23 15:26 +0100
Re: What Jerry Stuckle thinks of PHP programmers Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-23 12:25 -0400
Re: What Jerry Stuckle thinks of PHP programmers Luuk <luuk@invalid.lan> - 2012-04-23 19:45 +0200
Re: What Jerry Stuckle thinks of PHP programmers The Natural Philosopher <tnp@invalid.invalid> - 2012-04-23 20:35 +0100
Re: What Jerry Stuckle thinks of PHP programmers Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-24 19:45 +0200
Re: What Jerry Stuckle thinks of PHP programmers "Tony Marston" <TonyMarston@hotmail.com> - 2012-04-28 08:48 +0100
Re: What Jerry Stuckle thinks of PHP programmers The Natural Philosopher <tnp@invalid.invalid> - 2012-04-28 09:23 +0100
Re: What Jerry Stuckle thinks of PHP programmers Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-28 08:37 -0400
Re: What Jerry Stuckle thinks of PHP programmers Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-28 14:46 +0200
Re: What Jerry Stuckle thinks of PHP programmers The Natural Philosopher <tnp@invalid.invalid> - 2012-04-23 20:31 +0100
Re: What Jerry Stuckle thinks of PHP programmers Ross McKay <au.org.zeta.at.rosko@invalid.invalid> - 2012-04-24 12:32 +1000
Re: What Jerry Stuckle thinks of PHP programmers Tim Streater <timstreater@greenbee.net> - 2012-04-24 19:32 +0100
Re: What Jerry Stuckle thinks of PHP programmers Ross McKay <au.org.zeta.at.rosko@invalid.invalid> - 2012-04-25 19:02 +1000
Re: What Jerry Stuckle thinks of PHP programmers The Natural Philosopher <tnp@invalid.invalid> - 2012-04-25 12:20 +0100
Re: Dynamic form generation Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-22 23:59 +0200
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-23 14:05 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-23 09:35 -0400
Re: Dynamic form generation Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-23 15:41 +0200
Re: Dynamic form generation The Natural Philosopher <tnp@invalid.invalid> - 2012-04-23 20:39 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-23 09:47 -0400
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-25 08:52 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-25 08:34 -0400
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-27 09:52 +0100
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-27 14:16 +0100
Re: Dynamic form generation Charles <cchamb2@gmail.com> - 2012-05-03 15:23 -0700
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-12 10:52 +0100
Re: Dynamic form generation Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-04-13 11:39 +0200
Re: Dynamic form generation Jonathan Stein <jstein@image.dk> - 2012-04-13 15:27 +0200
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | "Tony Marston" <TonyMarston@hotmail.com> |
|---|---|
| Date | 2012-04-22 11:45 +0100 |
| Message-ID | <5jRkr.414639$nm6.220560@fx13.am4> |
| In reply to | #5631 |
"Jerry Stuckle" wrote in message news:jmufmh$peq$1@dont-email.me... > <snip> >> >> My definition of ERP is the same as that found in wikipedia at >> http://en.wikipedia.org/wiki/Enterprise_resource_planning. >> > >No, you're is nothing like that. > >> Note that an ERP system need not contain all of those modules, just two >> or more would be sufficient. >> > >Yours doesn't even contain that. My ERP system implements the functionality covered by several of the databases described in Len Silverston's Data Model Resource Book, specifically PARTY, PRODUCT, ORDER, INVOICE, INVENTORY, SHIPMENT, REQUESTS+REQUIREMENTS and WORK-EFFORT. That constitutes multiple modules. An ERP system is not required to have every possible module that can possibly be conceived, it can be limited to a subset that are actually required. <snip> > >>> All you do is database stuff. There's nothing complex about that. >> >> Correct. There is nothing complex about writing code which moves data >> between the user interface and the database. That is why I developed the >> Radicore framework, to take care of all that simple "plumbing" stuff for >> me. My valuable time is spent on writing the code which deals with the >> business rules, the "payload" as I call it, some of which are more >> complex than others >> > >And nothing you've done in your entire life is even moderately complex. You >wouldn't know where to begin. I shall stop arguing on what is complex and what is not as it is a complete waste of time. <snip> >To you a "complex business rule" is "the customer ordered something so we >need to ship it". > >You've have no idea what a complex system is. All you do is database >access. Untrue. My applications do much more than simply move data between the database and the user interface. My framework can achieve that without me having to write a single line of code whereas yours cannot. It is the processing of business rules which turns a simple application into a complex one, and my framework allows programmers to spend less time writing the boring repetitive code (the "plumbing") and more time on the business rules (the "payload"). >>> But they sure sound like they're bloated. >> >> The term "bloat" has nothing to do with the number of database tables. >> Provided that the database has been properly normalised (you *DO* know >> what the term "properly normalised" means, don't you?) and every table >> is used somewhere then there is no "bloat" whatsoever. >> > >It does when you've got way more than you need. And not if it's *properly* >normalized. However, I highly doubt your 200+ tables are "properly >normalized". You have no basis for that ridiculous accusation. >Bloat also covers unnecessary crap like your "password validation". So the fact that in my implementation a customer can change the password validation rules by changing values on a screen whereas in yours you have to change the code makes my implementation bloated? Where do you get these ridiculous ideas? <snip> >>>>>>>> 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. >>>>>> >>>>> >>>>> Yea, that's why your code is crap. You obviously know nothing about >>>>> proper OO coding techniques. And that means in order to change one >>>>> item in the object the user has to build an array for the whole thing? >>>>> Bloat... Bloat... Bloat... >>>> >>>> You obviously don't know what "proper OO" actually means. And where did >>>> I say that in order to change one item in the object the user has to >>>> build an array for the whole thing? You are reading things which I did >>>> not write. >>>> >>> >>> Oh, I sure do. You said you don't have SET/GET functions. You said you >>> set the values with an array. It's exactly what you said. >> >> But I don't have to insert any code to create that array as it is >> already provided for me in the form of $_GET or $_POST. >> >> When data comes in from the database it appears as a single variable >> which is an array of rows and columns. >> > >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. > 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. >>>>>> My framework does not generate any database access code as that is >>>>>> already >>>>>> provided by my Data Access Object (DAO). I have one for MySQL, one >>>>>> for >>>>>> PostgreSQL, one for Oracle and another for SQL Server. I can switch >>>>>> from one >>>>>> to another simply by changing a single line in a config file. >>>>>> >>>>> >>>>> Yes, you always waste a lot of time retrieving all columns, whether >>>>> they are needed or not. And you update all columns, whether you need >>>>> to or not. Bloatware. >>>> >>>> You are jumping to the wrong conclusion AGAIN! The default is to read >>>> all columns simply because by default all columns are displayed on the >>>> screen. The defaults can be changed. >>>> >>> >>> Ah, so you have to write code to change those defaults. Once again not >>> what you claimed earlier. >> >> Any person with more than two brain cells to rub together knows that if >> the default behaviour is not what you want then you have to write code >> to change those defaults. I have never claimed otherwise. My framework >> generates working transactions based on a lot of default behaviour, and >> in a lot of cases the default behaviour is good enough. When it isn't >> you can change it. > >That's not what you claimed earlier. Read back at what you said. But then >you're good at back-pedaling. And you're doing it again. It is EXACTLY what I claimed. I *NEVER* said that when using my framework that a programmer *NEVER* has to write any code. >>>>>>> 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. >>>>>> >>>>> >>>>> More bloat. And tell me how your class handles a rule such as "8-16 >>>>> characters, must have both upper and lower case and at least one >>>>> digit". >>>> >>>> Easy peasy. I just set these values in the database: >>>> min_length = 8 >>>> max_length = 16 >>>> upper_case = 1 >>>> lower_case = 1 >>>> num_digits = 1 >>>> >>> >>> Bloatware. The code has to needlessly query the database, parse the >>> results then apply them to the password, when a regex would do the job >>> simply. >> >> But where do you store the regex? In thin air? Different customers have >> different rules, so each customer can specify the rules that they want >> on their copy of the database. That is not bloat, it is sensible design. > >Nope, it's in the code. Another customer wants another rule? Change the >regex. And if you want to be anal about it (you're good at that, also), >put it in a function in a separate file. > >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. 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. >>>>> Or how about the bloat of calling a class to verify the input is an >>>>> integer when a simple one line statement works. More bloat. >>>> >>>> I have a validation class which is capable of validating every data >>>> type. This means that I do not have to write the line of code which >>>> tests that a piece of input is an integer. Not having to write that >>>> line >>>> is not bloat. >>>> >>> >>> Again, bloatware, when a simple function call like intval() will do >>> it. You've added an additional and unnecessary layer of complexity to >>> the application. >> >> You are missing the point AGAIN. In your applications you have to write >> code to call the intval() function. In my applications I don't have to >> write any validation code because I wrote a general purpose validation >> class many years ago, and it deals with that level of validation >> automatically. > >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. > I have to write nothing. And I don't have the bloat of a "general > validation class". Having all standard validation performed in a single class is most definitely not bloat, especially when compared with YOUR method of having a separate method to validate each field individually. >> 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! <snip> >>> More bloat. And unnecessary. How often does the customer want to >>> change the password rules? In about 35 years of programming for >>> clients, I've never had that happen. And what about the existing >>> passwords which don't match the new rules? >> >> A customer may or may not want to change the rules after the software >> has been installed, but as my software is used by many different >> customers each one may want a different set of rules when it is first >> installed. I can apply whatever rules a customer wants simply by >> changing his copy of the database, and NOT by changing any code. > >Changing one line of code is not a problem. Your way is pure bloat. Giving the customer the ability to change the password validation rules by changing values on a screen instead of getting the programmer to change a line of code is not bloat. >It's interesting that this feature you think is slicker than snot on a >doorknob hasn't been implemented by any other systems I'm aware of - >including mainframe applications. The rest of the world knows bloat when >they see it. > >>> Why stop with the password? Why not let the customer change the window >>> layout, for instance? Or add tables and columns to the database? >> >> Now you're going off at a tangent. I should quit while you're behind. >> > >Nope, you brought up the subject of allowing the customer to change the >rules. Only the password validation rules. >This is just an extension of the same subject. After all, CMS's allow >customer's to change the screen layout to suit them; CMS's don't force all >customers to use the same screen layout. It is you who is extending this conversation into irrelevant areas. >There are many more systems which allow the user to change the page layout >than there are the password. The rest of the world knows bloat when they >see it. > >I guess that's all the bloat you're capable of, though. Even a simple CMS >would be beyond your capabilities. > >>> Your code is just bloatware and adds an unnecessary layer of >>> complexity to the code. No, I am simply providing the customer with the ability to change password validation rules by changing values on a screen, not by getting the programmer to change some code. That is not "an unnecessary layer of complexity" as you call it, it is good design. >>>>>>> It also has the ability to generate forms html to display >>>>>>> (read/write or >>>>>>> read only). And this is all one function. If I need a different >>>>>>> layout >>>>>>> for a different page, it's easy to copy/paste a new function and >>>>>>> redo the >>>>>>> output. >>>>>> >>>>>> Copy/Paste? That produces duplicate code, not sharable code, and even >>>>>> you >>>>>> should know that duplicate code violates the DRY principle. >>>>>> >>>>> >>>>> You obviously don't understand the DRY principle. Just because you >>>>> copy/paste does not mean it's duplicate code. Once the code has been >>>>> modified to do something else, it is no longer duplicate. >>>> >>>> If you were really clever you wouldn't have to copy/paste/modify, you >>>> would have a reusable module. In my MVC implementation I have a fixed >>>> set of controllers, and each controller is reusable. Can you say the >>>> same in your framework? >>>> >>> >>> Doesn't make any difference. How do you handle displaying the same >>> information two entirely different ways on two different windows? Mine >>> is simple and straightforward. It is also easy to maintain. >> >> So is mine. >> > >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. 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. >>>>>>> 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); >>>>>> >>>>> >>>>> So what is insertRecord($_POST) then, if it's not a function? Once >>>>> again you show your ignorance. Don't even know what a function is! >>>> >>>> What I'm saying is that I don't have a function which splits the $_POST >>>> array into its component parts so I can then use a setter on each >>>> component, I simply inject the entire $_POST array in a single >>>> operation >>>> without the need to split it down into its component parts. >>>> >>> >>> So you do have a function which does the work. That's not what you >>> said earlier. >> >> Read what I wrote. I do *NOT* have any function which splits the input >> array, be it the $_GET array, the $_POST array, or whatever, into its >> component parts. All database data exists in the database table object >> as an array of rows and columns. > >I never said you had a function which splits the input array. I know >English is not your first language, but you really should learn to read. You said that I had a function just like yours which splits the $_GET/$_POST array into its component parts so that it can use a setter on each of those component parts. I simply said that I don't have any function which splits any array into its component parts, and I don't have getters or setters for each of those component parts. That is what I wrote, but that is not what you read. The error is yours, not mine. >>> I never said I had to split it down into parts, either. I have a >>> member function which handles the input. But I guess that's just too >>> much for you to understand. >> >> I beg to differ. You specifically wrote that you have getters and >> setters for each individual column/field. I do not have code which >> splits an array into its component parts as I can access any component >> part while it is still sitting in the array. >> > >That's right. That's an implicit part of OO (encapsulation). Using getters and setters has nothing to do with encapsulation. <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. >>>>>> 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. >>>>>> >>>>> >>>>> Nope, that's not at all what polymorphism is about. But you obviously >>>>> don't understand polymorphism, either. >>>> >>>> The definition of polymorphism which I use is "same method, different >>>> implementation". What definition do you use? >>>> >>> >>> You've got a *partial* definition. Polymorphism is only applicable >>> when the two classes have a parent/child hierarchy, and the child >>> class has a method of the same name (and in some languages, the same >>> parameter list) as the parent. >> >> The definition of polymorphism does NOT state that the classes have to >> exist in a parent/child hierarchy, only that they have the same method >> signature. Having said that, it is usually the case that the two classes >> ARE related. >> > >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. >In most languages the method signature must also be the same (in fact I >don't know of any language which doesn't), but that's not a requirement of >polymorphism (unlike the parent/child relationship). > >>> When there is no parent/child relationship (as in the case of two >>> different database tables), there is no polymorphism. >> >> Then you obviously haven't used an abstract table class which is >> inherited by every concrete table class. All my concrete table classes >> have instant access to all the methods and properties which are defined >> just once in the abstract class. > >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. <snip> >> It is much more than a simple database application which does nothing >> more than move data between the user interface and the database. It >> processes a large number of business rules, and it is the number and >> complexity of these business rules which decides whether an application >> is actually complex or not. > >In your world, yes. But then all you've ever done are database >applications. You've never worked on anything even moderately complex, by >your own admission. Just because it is a database application does not mean that it can only ever be a simple application and never a complex one. It is the number and complexity of the business rules which is in addition to the basic functionality of moving data between the database and the user interface which changes a "simple" data access system into a "complex" one. <snip> >But then I can see why you weren't able to keep a job with any of those >software houses. I worked with one for 16 years. My personal development standards were adopted as the company standards. A framework which I designed and developed for one client was adopted as the company standard. That would not have happened if I were such a crap programmer as you seem to think I am. >>>>>> If *your* framework is so good, then why don't you release it as open >>>>>> source so that we call all have a laugh? >>>>> >>>>> For a lot of reasons. Mainly because I'm not interested in the hassles >>>>> of having to support it for a bunch of people who want all kinds of >>>>> other features. I created it for my projects, and it serves those >>>>> projects well. >>>> >>>> What you really mean is that you are too ashamed to have it reviewed by >>>> your peers, and that you are incapable of writing code which can be >>>> used >>>> by others. >>> >>> Not at all. I meant exactly what I said. >> >> Yes, you can't be bothered to release it as it is only useful for your >> own personal toy projects. > >Nope. I just don't want to have to answer a bunch of anal questions by the >likes of you. I have better things to do with my time. All you can do is come up with unfounded criticisms of other people's work without having the courage to release your work so that other people have the opportunity to criticise your work. I released my framework as open source but you don't have the courage to do the same with yours. That means that you don't have the courage of your convictions. You don't want to release your work in case somebody tells you that it's crap. >>> Unlike you, I don't need my ego stroked. 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. >> That's not the impression I get from reading your comments in this post. >> You seem to think that YOUR way is the ONLY way, and anybody who dares >> to disagree with you is a stupid moron. I disagree with everything you >> say, and as for being a moron, 99% of the emails which I receive on the >> subject on my work are nothing but complimentary. > >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. >And knowing how the rest of the world feels about the ability of PHP >programmers, it's not surprising. I've seen some pretty crappy code get >high marks because people don't know any better. That sounds like your opinion of your code is because you simply don't know any better. >>> But my code is reviewed by others quite often. Most projects I work on >>> are collaborative. But then I work with programmers who know what >>> they're doing, also. >> >> I'd hate to on a team of programmers who all think like you as they >> would all be unproductive and full of silly ideas. > >We work quite well together and create a lot of GOOD code. Unlike the crap >you put put. You definition of "crap code" seems to be nothing more than "it is not the same as mine, therefore it's crap". -- Tony Marston http://www.tonymarston.net http://www.radicore.org
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-04-22 10:09 -0400 |
| Message-ID | <jn13eu$4ll$1@dont-email.me> |
| In reply to | #5651 |
On 4/22/2012 6:45 AM, Tony Marston wrote: > "Jerry Stuckle" wrote in message news:jmufmh$peq$1@dont-email.me... >> Yours doesn't even contain that. > > My ERP system implements the functionality covered by several of the > databases described in Len Silverston's Data Model Resource Book, > specifically PARTY, PRODUCT, ORDER, INVOICE, INVENTORY, SHIPMENT, > REQUESTS+REQUIREMENTS and WORK-EFFORT. That constitutes multiple > modules. An ERP system is not required to have every possible module > that can possibly be conceived, it can be limited to a subset that are > actually required. > Your order entry/tracking system does just that. It someone to enter orders and tracks those orders. Nothing more, nothing less. To call this an ERP system proves you are: a) Stoopid b) Dishonest c) All of the above Which are you? >> >> And nothing you've done in your entire life is even moderately >> complex. You wouldn't know where to begin. > > I shall stop arguing on what is complex and what is not as it is a > complete waste of time. > Good thing, since you've never worked on anything other than simple database applications. You have no idea what a complex program is, and you're just proving over and over again your stupidity. You should have quit while you were ahead (not that you ever were). > <snip> >> To you a "complex business rule" is "the customer ordered something so >> we need to ship it". >> >> You've have no idea what a complex system is. All you do is database >> access. > > Untrue. My applications do much more than simply move data between the > database and the user interface. My framework can achieve that without > me having to write a single line of code whereas yours cannot. It is the > processing of business rules which turns a simple application into a > complex one, and my framework allows programmers to spend less time > writing the boring repetitive code (the "plumbing") and more time on the > business rules (the "payload"). > You have no idea what a complex system is - and you just once again proved it. But once again, you prove your stupidity. You just said you weren't going to argue what a complex system is in your previous paragraph. Yet here you are doing it again. You're just proving your stupidity. You should have quit while you were ahead (not that you ever were). >> >> It does when you've got way more than you need. And not if it's >> *properly* normalized. However, I highly doubt your 200+ tables are >> "properly normalized". > > You have no basis for that ridiculous accusation. > Only your words. >> Bloat also covers unnecessary crap like your "password validation". > > So the fact that in my implementation a customer can change the password > validation rules by changing values on a screen whereas in yours you > have to change the code makes my implementation bloated? Where do you > get these ridiculous ideas? > Yup, and the fact you think it's slicker than snot on a doorknob is hilarious. It IS the shot on the doorknob! It's unnecessary features like this which create bloated code. >> >> 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. >> 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. 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". Proper OO programming doesn't allow such crap programming. >> >> That's not what you claimed earlier. Read back at what you said. But >> then you're good at back-pedaling. And you're doing it again. > > It is EXACTLY what I claimed. I *NEVER* said that when using my > framework that a programmer *NEVER* has to write any code. > ROFLMAO! Back-pedaling again. And you can't even read what you wrote previously. >> 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. > 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. >> 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 have to write nothing. And I don't have the bloat of a "general >> validation class". > > Having all standard validation performed in a single class is most > definitely not bloat, especially when compared with YOUR method of > having a separate method to validate each field individually. > 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. >>> 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!"; > <snip> >>>> More bloat. And unnecessary. How often does the customer want to >>>> change the password rules? In about 35 years of programming for >>>> clients, I've never had that happen. And what about the existing >>>> passwords which don't match the new rules? >>> >>> A customer may or may not want to change the rules after the software >>> has been installed, but as my software is used by many different >>> customers each one may want a different set of rules when it is first >>> installed. I can apply whatever rules a customer wants simply by >>> changing his copy of the database, and NOT by changing any code. >> >> Changing one line of code is not a problem. Your way is pure bloat. > > Giving the customer the ability to change the password validation rules > by changing values on a screen instead of getting the programmer to > change a line of code is not bloat. > Bloat, bloat, bloat. Everyone else in the world understands that, which is why they haven't implemented it. It is a completely unnecessary complication to the code, requiring a call to the database, parsing the output and then applying a rule every time a password is changed. It can all be done in one line of code, and especially unnecessary since this is open source. Bloat, bloat, bloat. >> It's interesting that this feature you think is slicker than snot on a >> doorknob hasn't been implemented by any other systems I'm aware of - >> including mainframe applications. The rest of the world knows bloat >> when they see it. >> >>>> Why stop with the password? Why not let the customer change the window >>>> layout, for instance? Or add tables and columns to the database? >>> >>> Now you're going off at a tangent. I should quit while you're behind. >>> >> >> 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? >> This is just an extension of the same subject. After all, CMS's allow >> customer's to change the screen layout to suit them; CMS's don't force >> all customers to use the same screen layout. > > It is you who is extending this conversation into irrelevant areas. > Nope, it's showing just how stupid your "password rules" are. >> There are many more systems which allow the user to change the page >> layout than there are the password. The rest of the world knows bloat >> when they see it. >> >> I guess that's all the bloat you're capable of, though. Even a simple >> CMS would be beyond your capabilities. >> >>>> Your code is just bloatware and adds an unnecessary layer of >>>> complexity to the code. > > No, I am simply providing the customer with the ability to change > password validation rules by changing values on a screen, not by getting > the programmer to change some code. That is not "an unnecessary layer of > complexity" as you call it, it is good design. > Your code is just bloat. Even the greenest programmers in the rest of the world understand how unnecessary your bloatware is. >>> >> >> 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? > 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. >> >> I never said you had a function which splits the input array. I know >> English is not your first language, but you really should learn to read. > > You said that I had a function just like yours which splits the > $_GET/$_POST array into its component parts so that it can use a setter > on each of those component parts. I simply said that I don't have any > function which splits any array into its component parts, and I don't > have getters or setters for each of those component parts. > 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. The lack of getters and setters means your variables must be public, which violates the first principle of OO programming - encapsulation. > That is what I wrote, but that is not what you read. The error is yours, > not mine. > You still can't read what you write, can you? >> >> 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. > <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. >> 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. When you don't even understand encapsulation, no one should expect you to understand a more advanced concept like polymorphism. >> >> 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. > <snip> >>> It is much more than a simple database application which does nothing >>> more than move data between the user interface and the database. It >>> processes a large number of business rules, and it is the number and >>> complexity of these business rules which decides whether an application >>> is actually complex or not. >> >> In your world, yes. But then all you've ever done are database >> applications. You've never worked on anything even moderately complex, >> by your own admission. > > Just because it is a database application does not mean that it can only > ever be a simple application and never a complex one. It is the number > and complexity of the business rules which is in addition to the basic > functionality of moving data between the database and the user interface > which changes a "simple" data access system into a "complex" one. > You've never written a complex application in your life. But then to you, adding a few business rules makes an application complex. In the alternate universe of Tony Marston, it does - because you aren't capable of anything more. > <snip> >> But then I can see why you weren't able to keep a job with any of >> those software houses. > > I worked with one for 16 years. My personal development standards were > adopted as the company standards. A framework which I designed and > developed for one client was adopted as the company standard. That would > not have happened if I were such a crap programmer as you seem to think > I am. > ROFLMAO! You mean you found someone even stupider than you? That's pretty hard to believe. >> >> Nope. I just don't want to have to answer a bunch of anal questions by >> the likes of you. I have better things to do with my time. > > All you can do is come up with unfounded criticisms of other people's > work without having the courage to release your work so that other > people have the opportunity to criticise your work. > All of my criticisms are based on solid programming principles and your own statements about your code. > I released my framework as open source but you don't have the courage to > do the same with yours. That means that you don't have the courage of > your convictions. You don't want to release your work in case somebody > tells you that it's crap. > No, I don't need to stroke my ego. And I don't need idiots like you making anal comments about it. >>>> Unlike you, I don't need my ego stroked. > > 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. >> 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. And yes, there is a single set of practices agreed to by recognized experts in the field. Unfortunately, Tony Marston isn't one of those experts. But he is in the Universe According to Tony Marston. Too bad it's a universe of one. >> And knowing how the rest of the world feels about the ability of PHP >> programmers, it's not surprising. I've seen some pretty crappy code >> get high marks because people don't know any better. > > That sounds like your opinion of your code is because you simply don't > know any better. > It is well recognized by programmers in other languages. You even see comments about it in this very newsgroup occasionally. And the true experts here agree with it. And it has nothing to do with my code. But then you're good at trying to change the subject when you have no defense. >> >> We work quite well together and create a lot of GOOD code. Unlike the >> crap you put put. > > You definition of "crap code" seems to be nothing more than "it is not > the same as mine, therefore it's crap". > Nope. How about it's bloated, overly complicated and doesn't follow generally recognized principles, for starts? -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | "Tony Marston" <tony@NOSPAM.demon.co.uk> |
|---|---|
| Date | 2012-04-24 18:21 +0100 |
| Message-ID | <biBlr.160241$gk1.13851@fx26.am4> |
| In reply to | #5653 |
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message news:jn13eu$4ll$1@dont-email.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.language >>> 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
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2012-04-24 20:56 +0200 |
| Message-ID | <1430094.ghCgKLUCYl@PointedEars.de> |
| In reply to | #5701 |
Tony Marston wrote:
> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
> news:jn13eu$4ll$1@dont-email.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".
It will at least contain the name and value of a submit button (provided the
form was designed with accessibility in mind) as well, but that aside:
In order to make that work you have to have several forms in the HTML
document presenting order data, each which only contains the pertinent
controls (including a submit button), or you have to have to (attempt to)
modify the $_POST array *after* it has been populated by PHP.
However, the established and more sensible approach is to have, if feasible,
only *one* form with *one* `action' URI for one type of object and let the
application decide by the name or value of the submit button which data of
that form to process, and (with few exceptions) leave the request
superglobals as they are.
<http://www.php.net/manual/en/language.variables.external.php>
>>>> 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.
Correct. However, information hiding is a core principle not only in OOP
(and not just of an interpretation of OOP) that publicly accessible object
properties do violate; that makes encapsulation ineffective. For the
problem with such properties is that anyone can modify (and retrieve) them
from anywhere and, given loose and dynamic typing, in any way. There is no
type checking, range checking or access checking. This makes OO programs
less robust than they could be, and essentially results in a maintenance
nightmare because of a missing well-defined interface for the encapsulated
data.
<http://en.wikipedia.org/wiki/Information_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';
Now imagine that for some reason it happens that the equivalent of the
following is executed:
$object->fieldarray['ship_date'] = -42;
There is no range checking and no type checking here since PHP is loosely
and dynamically typed and there are no setters for array items. So the
error that has been made will not show up before the query is made, if that.
If instead you had the equivalent of
$object->ship_date = -42;
(which can be triggered by a mapper method from the constructor as I
explained), then that could call implicitly the equivalent of
get_class($object)::__set('ship_date', -42);
which could call
$object->setShip_date(-42);
declared as
public function setShip_date($value)
{
if ($value < 0)
{
throw new InvalidArgumentException(
'Error on ISO/OSI layer 8: Date values cannot be negative');
}
$this->_ship_date = $value;
}
then it would not be attempted to write an invalid value into the database
because the model forbids storing it in volatile memory in the first place.
> Such duff data would never make it to the database anyway as it would fail
> the validation.
AIUI your argument is that you do range checking before accessing the
database, but there are three problems with that approach: 1. It is harder
and less efficient to find invalid values later because the code is too
general at that point. 1. It is counter-MVC, for the model object is
supposed to hold only valid data in the first place.
>> Proper OO programming doesn't allow such crap programming.
ACK.
> OO does not prevent programmers from writing crap code. It just allows
> then to generate a different class of crap.
So your counter-argument is that you are allowed to write "crap code"?
>>> 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.
No, your approach can be modified so that the model class uses requests
validation information from the database and uses it on assignment. Since
the information would apply to all object of a class and would not change
during the lifetime of the class, it would appear to be best to reuse static
class variables and perhaps the singleton pattern from the constructor for
this. IIRC it has been done before.
>>>> 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.
So you are allowing direct, unchecked access. Bad idea.
>> 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. […]
But apparently you do not understand the concept of information hiding;
without it, encapsulation is ineffective.
>>>>> 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.
But until you access the database, the model object stores/refers to invalid
data. Whereas "invalid" includes "inconsistent" if related properties (or
in your case, array elements) are (inadvertently) modified through public
access in a way that the result is does not make sense, like
$object->data['order_date'] = '1942-02-29';
$object->data['ship_date'] = '2012-04-24';
$object->data['shipped'] = false;
$object->data['accepted'] = '2011-04-01';
Please do not tell me this cannot happen; I *know* it can.
> [tl;dr]
--
PointedEars
[toc] | [prev] | [next] | [standalone]
| From | "Tony Marston" <tony@NOSPAM.demon.co.uk> |
|---|---|
| Date | 2012-04-25 09:23 +0100 |
| Message-ID | <9wOlr.228004$IU.187164@fx28.am4> |
| In reply to | #5705 |
"Thomas 'PointedEars' Lahn" <PointedEars@web.de> wrote in message
news:1430094.ghCgKLUCYl@PointedEars.de...
> Tony Marston wrote:
>
>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
>> news:jn13eu$4ll$1@dont-email.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".
>
> It will at least contain the name and value of a submit button (provided
> the
> form was designed with accessibility in mind) as well, but that aside:
>
> In order to make that work you have to have several forms in the HTML
> document presenting order data, each which only contains the pertinent
> controls (including a submit button), or you have to have to (attempt to)
> modify the $_POST array *after* it has been populated by PHP.
>
> However, the established and more sensible approach is to have, if
> feasible,
> only *one* form with *one* `action' URI for one type of object and let the
> application decide by the name or value of the submit button which data of
> that form to process, and (with few exceptions) leave the request
> superglobals as they are.
That is exactly how my framework works. Each transaction has its own screen
format and possibly requires a different SELECT statement. Each transaction
has its own menu button, so all the user has to do is to press a menu button
in order to run the transaction associated with that button. The user does
not press a button to run a transaction and then have to press another
button to decide which output format he wants.
>>>>> 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.
>
> Correct. However, information hiding is a core principle not only in OOP
> (and not just of an interpretation of OOP) that publicly accessible object
> properties do violate; that makes encapsulation ineffective.
Encapsulation does not mean data hiding. Just because some programmers have
decided that it should, therefore properties should not be public and only
accessible through getters and setters is irrelevant.
Encapsulation does not mean data hiding. I do *NOT* have to hide all the
properties, and I do *NOT* have to use getters and setters.
<snip>
> Now imagine that for some reason it happens that the equivalent of the
> following is executed:
>
> $object->fieldarray['ship_date'] = -42;
>
> There is no range checking and no type checking here since PHP is loosely
> and dynamically typed and there are no setters for array items. So the
> error that has been made will not show up before the query is made, if
> that.
Incorrect. My table object will reject that value before it is passed to the
data access object, and it is the data access object which generates and
executes the SQL query.
> If instead you had the equivalent of
>
> $object->ship_date = -42;
>
> (which can be triggered by a mapper method from the constructor as I
> explained), then that could call implicitly the equivalent of
>
> get_class($object)::__set('ship_date', -42);
>
> which could call
>
> $object->setShip_date(-42);
>
> declared as
>
> public function setShip_date($value)
> {
> if ($value < 0)
> {
> throw new InvalidArgumentException(
> 'Error on ISO/OSI layer 8: Date values cannot be negative');
> }
>
> $this->_ship_date = $value;
> }
All that code sounds like bloat to me. I achieve the same result, but with
less code, so I like my method better.
> then it would not be attempted to write an invalid value into the database
> because the model forbids storing it in volatile memory in the first
> place.
>
>> Such duff data would never make it to the database anyway as it would
>> fail
>> the validation.
>
> AIUI your argument is that you do range checking before accessing the
> database, but there are three problems with that approach: 1. It is harder
> and less efficient to find invalid values later because the code is too
> general at that point.
How is it harder? I have an array of data and I validate the entire contents
of the array with a single call to my validation object. Surely it can't be
simpler that?
> 2. It is counter-MVC, for the model object is
> supposed to hold only valid data in the first place.
Who says so? Where in any description of the MVC does it say that all data
must be validated BEFORE it gets injected into the model. The only
universally accepted rule is that data must be validated BEFORE it gets
written to the database.
>>> Proper OO programming doesn't allow such crap programming.
>
> ACK.
>
>> OO does not prevent programmers from writing crap code. It just allows
>> then to generate a different class of crap.
>
> So your counter-argument is that you are allowed to write "crap code"?
By "allowed to " I mean "not prevented". No programming language can ever
prevent a crap programmer from writing crap code. It all comes down to the
skill of te individual programmer.
>>>> 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.
>
> No, your approach can be modified so that the model class uses requests
> validation information from the database and uses it on assignment. Since
> the information would apply to all object of a class and would not change
> during the lifetime of the class, it would appear to be best to reuse
> static
> class variables and perhaps the singleton pattern from the constructor for
> this. IIRC it has been done before.
It is not possible to define every possible rule as data in the database so
it can be retrieved and executed at runtime. The execution of business rules
requires code, not data (ask Jerry about validating password rules).
<snip>
> So you are allowing direct, unchecked access. Bad idea.
How so? The line $object->foo = 'bar' achieves the same result as
$object->setFoo('bar'). The contents of $foo are validated before the data
gets written to database, so where's the problem?
>>> 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. [.]
>
> But apparently you do not understand the concept of information hiding;
> without it, encapsulation is ineffective.
Encapsulation does not mean information hiding.
>>>>>> 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.
>
> But until you access the database, the model object stores/refers to
> invalid
> data. Whereas "invalid" includes "inconsistent" if related properties (or
> in your case, array elements) are (inadvertently) modified through public
> access in a way that the result is does not make sense, like
>
> $object->data['order_date'] = '1942-02-29';
> $object->data['ship_date'] = '2012-04-24';
> $object->data['shipped'] = false;
> $object->data['accepted'] = '2011-04-01';
>
> Please do not tell me this cannot happen; I *know* it can.
So how do you prevent such a catastrophe in your code?
--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-04-24 16:20 -0400 |
| Message-ID | <jn71ur$o4l$1@dont-email.me> |
| In reply to | #5701 |
On 4/24/2012 1:21 PM, Tony Marston wrote: > "Jerry Stuckle"<jstucklex@attglobal.net> wrote in message > news:jn13eu$4ll$1@dont-email.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? > And an intelligent system will just have a button that says "order shipped" with the program filling in the date. No input field required! In a real OO system you don't need to use the $_POST array - the program can update individual items and still ensure the data are valid. 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. > I never claimed it does. I said it means CONTROLLED ACCESS. >> 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. > According to your comments, such a construct will never be validated. So how can it fail 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. > I never claimed it did. But proper design and implementation means good code. > <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. > Bloat, bloat, bloat. Also much harder to understand and maintain than a simple call to intval(). >>> 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. > That is correct. That's why the class is independent of the rest of the program. It implements it's own rules and data, which can be changed as long as the public methods don't change. >>>> 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. > And in order for the program to set an individual item it must build an array - having to know the internal workings of the class. >> 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. > Obviously you don't understand encapsulation at all. >>>>> 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. > It can't be, because you have repeatedly stated the validation is done on an input array. There is nothing to stop me from putting that in the variable in the class because you don't have setter functions. > <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. > Sure you ignore it because it's a valid question you have no answer to. > <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. > Gee, it 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 allows me to create either of those methods in 10 minutes or less. How long does yours take? A lot more than 10 minutes, for sure. >> 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. > So? It has to be split into component parts anyway before inserting into the database. My way does it on input. The advantage is that ALL write access to the object is controlled and validated because the programmer can't access private variables directly. Yours doesn't do that. >> 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. > You're the only one who keeps bringing up 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. > You're the only one who keeps bringing up data hiding. >>> <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. > It has EVERYTHING 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. > Sure you can. But that is not polymorphism. >> 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.language > Yes, your understanding is sadly lacking in even the most basic concepts. Once again I refer you to a world-recognized expert on OO. But it might destroy some of your misconceptions. >>>> 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. > Polymorphism does not relate to siblings. Only to parent/child relationships. > <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. > I have kept stating that your framework is crap, and it is. You are a perfect example of why PHP programmers have such a poor reputation amongst good programmers. >>>> 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? > Absolutely of no consequence. The fact I do not want to waste my time answering anal questions from the likes of you is my choice. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | "Tony Marston" <tony@NOSPAM.demon.co.uk> |
|---|---|
| Date | 2012-04-25 10:04 +0100 |
| Message-ID | <76Plr.488417$xD4.206274@fx06.am4> |
| In reply to | #5706 |
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
news:jn71ur$o4l$1@dont-email.me...
> On 4/24/2012 1:21 PM, Tony Marston wrote:
>> "Jerry Stuckle"<jstucklex@attglobal.net> wrote in message
>> news:jn13eu$4ll$1@dont-email.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?
>
> And an intelligent system will just have a button that says "order
> shipped" with the program filling in the date. No input field required!
You question was not "how can you set a value which was not included in the
$_POST array?"
If I have a transaction whose function "set the ship_date to today for all
selected orders" then all it has to work on is an array of order numbers. I
would iterate through this array using code similar to the following:
foreach ($order_array as $order) {
$order['ship_date'] = $today;
$orderObject->updateRecord($order);
}
See? Neat and tidy,clean and simple.
> In a real OO system you don't need to use the $_POST array - the program
> can update individual items and still ensure the data are valid.
>
> Why can't you understand such a simple concept?
That is not the question you asked, therefore it is not the question I
answered.
>>>>> 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.
>>
>
> I never claimed it does. I said it means CONTROLLED ACCESS.
Encapsulation does not mean data hiding. Encapsulation does not mean
controlled access to data. The defintion of encapsulation does not require
that either methods or properties have their access limited in any way
whatsover.
>>> 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.
>
> According to your comments, such a construct will never be validated. So
> how can it fail validation?
I have already explained that I validate the entire contents of the input
array with a single call to my validation object before any data gets
written to the database. Any validation errors cause the table object to
immediately return to the controller so that the screen can be redisplayed
with the error message so that the user can correct his error and re-submit.
>>> 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.
>
> I never claimed it did. But proper design and implementation means good
> code.
How is my design improper? I ensure that all user input is validated before
it gets written to the database, and I can do so without the programmer
having to write a single line code.
<snip>
>>> With proper OO principles, the object requiring the rule implements the
>>> rule.
>>
>> But the rule has to be coded within the relevant class.
>
> That is correct. That's why the class is independent of the rest of the
> program. It implements it's own rules and data, which can be changed as
> long as the public methods don't change.
Exactly, and that is what my framework achieves. The business rules for each
entity are coded within the entity's class.
<snip>
>> 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.
>
> And in order for the program to set an individual item it must build an
> array - having to know the internal workings of the class.
So how is $this->foo = 'bar' or $this->setFoo('bar') any different from
$this->fieldarray['foo'] = 'bar'? You still have to have a line of code
which says "set the value of 'foo' to 'bar'". They are just different
instructions which achieve the same result. You still have to know that the
table object has a column called 'foo', so how does this expose the internal
workings of the class?
>>> 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.
>
> Obviously you don't understand encapsulation at all.
Encapsulation has nothing to do with data validation.
<snip>
>>> 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.
>
> It can't be, because you have repeatedly stated the validation is done on
> an input array. There is nothing to stop me from putting that in the
> variable in the class because you don't have setter functions.
If you try the line $object->ship_date = "This is stupid!"; then you are not
updating the data array, and it is the data array which is used to update
the database. This means that your line of code will achieve nothing as the
property 'ship_date' will never be referenced anywhere.
<snip>
>> The fact that the function accepts an array as its input is irrelevant as
>> you are still spliting the array into its component parts.
>
> So? It has to be split into component parts anyway before inserting into
> the database. My way does it on input.
In my framework the data array is never split into its component parts until
it appears in the data access object where the SQL statement is constructed
and executed.
> The advantage is that ALL write access to the object is controlled and
> validated because the programmer can't access private variables directly.
> Yours doesn't do that.
Irrelevant. All input is validated before it gets written to the database.
How I validate and when I validate is irrelevant.
>>> 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.
>
> You're the only one who keeps bringing up data hiding.
Incorrect. It is *YOU* who keeps saying that I must use getters and setters
because I should not access an object's properties directly (i.e. the
properties should be hidden)
>>>>> 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.
>
> You're the only one who keeps bringing up data hiding.
Incorrect. See above.
<snip>
>> 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.
>
> Sure you can. But that is not polymorphism.
If you have "same interface, different implementation" then you have
polymorphism. The "same interface" can either be inherited or hard-coded.
<snip>
> Polymorphism does not relate to siblings. Only to parent/child
> relationships.
You are missing the point. All these siblings have the SAME PARENT therefore
they inherit all the methods of the parent.
<snip>
>>> 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?
>
> Absolutely of no consequence. The fact I do not want to waste my time
> answering anal questions from the likes of you is my choice.
So you don't want to answer anal questions, but you spend your time asking
them.
--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-04-25 08:29 -0400 |
| Message-ID | <jn8qng$h7u$1@dont-email.me> |
| In reply to | #5712 |
On 4/25/2012 5:04 AM, Tony Marston wrote:
> "Jerry Stuckle"<jstucklex@attglobal.net> wrote in message
> news:jn71ur$o4l$1@dont-email.me...
>> On 4/24/2012 1:21 PM, Tony Marston wrote:
>>> "Jerry Stuckle"<jstucklex@attglobal.net> wrote in message
>>> news:jn13eu$4ll$1@dont-email.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?
>>
>> And an intelligent system will just have a button that says "order
>> shipped" with the program filling in the date. No input field required!
>
> You question was not "how can you set a value which was not included in the
> $_POST array?"
>
> If I have a transaction whose function "set the ship_date to today for all
> selected orders" then all it has to work on is an array of order numbers. I
> would iterate through this array using code similar to the following:
>
> foreach ($order_array as $order) {
> $order['ship_date'] = $today;
> $orderObject->updateRecord($order);
> }
>
> See? Neat and tidy,clean and simple.
>
Yup, and I see that you could just as easily say
$today = 'this is crap';
foreach ($order_array as $order) {
$order['ship_date'] = $today;
$orderObject->updateRecord($order);
}
And it will try to do it just fine - until it comes time to perform the
actual update.
Or even
$today = '2099-12-31';
<same as above>
And it will very happily do it.
>> In a real OO system you don't need to use the $_POST array - the program
>> can update individual items and still ensure the data are valid.
>>
>> Why can't you understand such a simple concept?
>
> That is not the question you asked, therefore it is not the question I
> answered.
>
Sure it was. You just can't understand such a simple question. Or you
evaded it on purpose. Which was it?
>>>>>> 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.
>>>
>>
>> I never claimed it does. I said it means CONTROLLED ACCESS.
>
> Encapsulation does not mean data hiding. Encapsulation does not mean
> controlled access to data. The defintion of encapsulation does not require
> that either methods or properties have their access limited in any way
> whatsover.
>
You're the only one who claims it is data hiding. It DOES mean
controlling access to the data.
Otherwise why even have encapsulation? What is its purpose?
>>>> 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.
>>
>> According to your comments, such a construct will never be validated. So
>> how can it fail validation?
>
> I have already explained that I validate the entire contents of the input
> array with a single call to my validation object before any data gets
> written to the database. Any validation errors cause the table object to
> immediately return to the controller so that the screen can be redisplayed
> with the error message so that the user can correct his error and re-submit.
>
According to your own comments, such a construct will never be
validated, so it will fail validation.
And validating something hundreds of thousands of lines after it has
been set to an incorrect value is almost worthless. It should be done
at the time of the error.
But I also understand that's not a problem for you because you've never
written a complicated program. Just simple database access stuff.
>>>> 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.
>>
>> I never claimed it did. But proper design and implementation means good
>> code.
>
> How is my design improper? I ensure that all user input is validated before
> it gets written to the database, and I can do so without the programmer
> having to write a single line code.
>
It doesn't implement encapsulation. It doesn't properly use methods. A
change in the database (i.e. changing a column name) requires changing
the program. It exposes the names of the table columns you're using.
I could continue, but I know you'll discount everything I say. Crap
programmers do that when informed why their code is crap. Good
programmers try to learn.
> <snip>
>>>> With proper OO principles, the object requiring the rule implements the
>>>> rule.
>>>
>>> But the rule has to be coded within the relevant class.
>>
>> That is correct. That's why the class is independent of the rest of the
>> program. It implements it's own rules and data, which can be changed as
>> long as the public methods don't change.
>
> Exactly, and that is what my framework achieves. The business rules for each
> entity are coded within the entity's class.
>
And changes to the database require changes to your code. What happens,
for instance, if you change the name of the column 'ship_date'?
Or if you change it to three columns - ship_month, ship_date, ship_year?
> <snip>
>>> 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.
>>
>> And in order for the program to set an individual item it must build an
>> array - having to know the internal workings of the class.
>
> So how is $this->foo = 'bar' or $this->setFoo('bar') any different from
> $this->fieldarray['foo'] = 'bar'? You still have to have a line of code
> which says "set the value of 'foo' to 'bar'". They are just different
> instructions which achieve the same result. You still have to know that the
> table object has a column called 'foo', so how does this expose the internal
> workings of the class?
>
Because $this->setFoo('bar') validates the data right then. And the
table column may or may not be called 'foo', and the internal object may
or may not be called 'foo'. In fact, the table object may be three
different columns. for instance.
>>>> 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.
>>
>> Obviously you don't understand encapsulation at all.
>
> Encapsulation has nothing to do with data validation.
>
Encapsulation has EVERYTHING do do with ensuring valid data.
> <snip>
>>>> 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.
>>
>> It can't be, because you have repeatedly stated the validation is done on
>> an input array. There is nothing to stop me from putting that in the
>> variable in the class because you don't have setter functions.
>
> If you try the line $object->ship_date = "This is stupid!"; then you are not
> updating the data array, and it is the data array which is used to update
> the database. This means that your line of code will achieve nothing as the
> property 'ship_date' will never be referenced anywhere.
>
OK, so you say $object->['ship_date'] = "This is stupid!";
But I know you're too stoopid to understand the concept, even if the
actual statement isn't updating the array.
Or how about:
$object = 'Really crap!';
> <snip>
>>> The fact that the function accepts an array as its input is irrelevant as
>>> you are still spliting the array into its component parts.
>>
>> So? It has to be split into component parts anyway before inserting into
>> the database. My way does it on input.
>
> In my framework the data array is never split into its component parts until
> it appears in the data access object where the SQL statement is constructed
> and executed.
>
So? It has to be split.
>> The advantage is that ALL write access to the object is controlled and
>> validated because the programmer can't access private variables directly.
>> Yours doesn't do that.
>
> Irrelevant. All input is validated before it gets written to the database.
> How I validate and when I validate is irrelevant.
>
Completely relevant, if you're writing a complex program. But you've
never done anything complex, so you wouldn't understand.
In a complicated program the invalid value may be set thousands of lines
before you actually update the database. The error should be detected
when the value is set, not much later.
>>>> 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.
>>
>> You're the only one who keeps bringing up data hiding.
>
> Incorrect. It is *YOU* who keeps saying that I must use getters and setters
> because I should not access an object's properties directly (i.e. the
> properties should be hidden)
>
Which has nothing to do with data hiding. You're the only one who
brings up 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.
>>
>> You're the only one who keeps bringing up data hiding.
>
> Incorrect. See above.
>
You're the only one who brings up data hiding.
> <snip>
>>> 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.
>>
>> Sure you can. But that is not polymorphism.
>
> If you have "same interface, different implementation" then you have
> polymorphism. The "same interface" can either be inherited or hard-coded.
>
> <snip>
>> Polymorphism does not relate to siblings. Only to parent/child
>> relationships.
>
> You are missing the point. All these siblings have the SAME PARENT therefore
> they inherit all the methods of the parent.
>
No, your understanding of polymorphism is just as bad as your
understanding of encapsulation. There is no polymorphism between
siblings. Only when you have a parent-child relationship.
> <snip>
>>>> 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?
>>
>> Absolutely of no consequence. The fact I do not want to waste my time
>> answering anal questions from the likes of you is my choice.
>
> So you don't want to answer anal questions, but you spend your time asking
> them.
>
I'm not asking anal questions. I'm trying to teach a pig to fly. But I
know that's a waste of time. And calling you a stoopid programmer is an
insult to stoopid programmers everywhere.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | "Tony Marston" <tony@NOSPAM.demon.co.uk> |
|---|---|
| Date | 2012-04-26 12:45 +0100 |
| Message-ID | <Ezamr.232809$IU.217432@fx28.am4> |
| In reply to | #5723 |
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
news:jn8qng$h7u$1@dont-email.me...
<snip>
>> If I have a transaction whose function "set the ship_date to today for
>> all
>> selected orders" then all it has to work on is an array of order numbers.
>> I
>> would iterate through this array using code similar to the following:
>>
>> foreach ($order_array as $order) {
>> $order['ship_date'] = $today;
>> $orderObject->updateRecord($order);
>> }
>>
>> See? Neat and tidy,clean and simple.
>
> Yup, and I see that you could just as easily say
>
> $today = 'this is crap';
> foreach ($order_array as $order) {
> $order['ship_date'] = $today;
> $orderObject->updateRecord($order);
> }
>
> And it will try to do it just fine - until it comes time to perform the
> actual update.
>
> Or even
> $today = '2099-12-31';
> <same as above>
>
> And it will very happily do it.
Incorrect. Data that is input into an object is validated before it gets
written to the database. It it fails the validation it doesn't get to the
database.
>>> In a real OO system you don't need to use the $_POST array - the program
>>> can update individual items and still ensure the data are valid.
Data normally comes from the user as a result of hitting SUBMIT on a form,
which means that it is presented to the script as the $_POST array.
>>> Why can't you understand such a simple concept?
>>
>> That is not the question you asked, therefore it is not the question I
>> answered.
>
> Sure it was. You just can't understand such a simple question. Or you
> evaded it on purpose. Which was it?
You did NOT ask the question "How can you update a field which was not
passed in via the $_POST or $_GET array?" Your question actually was "How do
you change a single property in the object without building the array?"
Considering that every page request automatically comes with either the
$_GET or $_POST array I do not have to "build" the array as it is already
there. If I want to I can add as many other values to the array as I want.
<snip>
>>>>> 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.
>>>
>>> I never claimed it does. I said it means CONTROLLED ACCESS.
>>
>> Encapsulation does not mean data hiding. Encapsulation does not mean
>> controlled access to data. The definition of encapsulation does not
>> require
>> that either methods or properties have their access limited in any way
>> whatsover.
>
> You're the only one who claims it is data hiding. It DOES mean
> controlling access to the data.
Controlling access means changing a property's visibility from "public"
(visible) to "private" (hidden). A public property can be accessed directly,
whereas a private propery can only be accessed via a getter or a setter.
So, "controlling access" *DOES* mean hiding the data, and encapsulation
*DOES NOT* mean data hiding.
The original definition of encapsulation mentioned "implementation hiding"
which is *NOT* the same thing as "information hiding". I have posted several
links to articles written by other people, including Martin Fowler (the
autor of Patterns of Enterprise Architecture), who say the same thing.
>>>>> 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.
>>>
>>> According to your comments, such a construct will never be validated. So
>>> how can it fail validation?
>>
>> I have already explained that I validate the entire contents of the input
>> array with a single call to my validation object before any data gets
>> written to the database. Any validation errors cause the table object to
>> immediately return to the controller so that the screen can be
>> redisplayed
>> with the error message so that the user can correct his error and
>> re-submit.
>
> According to your own comments, such a construct will never be validated,
> so it will never fail validation.
I have already told you that all input *IS* validated before it gets sent to
the database.
> And validating something hundreds of thousands of lines after it has been
> set to an incorrect value is almost worthless. It should be done at the
> time of the error.
When I chose to perform the data validation is entirely up to me. I do not
input data one field at a time using a setter, therefore I don't validate
the field's contents within the setter. All the data is injected as a single
array, and I validate the entire contents array in a single call to my
validation object before it is passed to my data access object which updates
the database.
The fact that I do not perform this validation in exactly the same way as
you does not mean that my way is wrong. It is simply different.
> But I also understand that's not a problem for you because you've never
> written a complicated program. Just simple database access stuff.
>
>>>>> Proper OO programming doesn't allow such crap programming.
>>>>
>>>> OO does not prevent programmers from writing crap code. It just allows
>>>> them to generate a different class of crap.
>>>
>>> I never claimed it did. But proper design and implementation means good
>>> code.
>>
>> How is my design improper? I ensure that all user input is validated
>> before
>> it gets written to the database, and I can do so without the programmer
>> having to write a single line code.
>
> It doesn't implement encapsulation.
The definition of encapsulation is "The act of placing data and the
operations that perform on that data in the same class". That is exactly
what I do. The fact that *YOUR* definition has been expanded to include
other so-called "rules" is irrelevant. I am sticking to the original
definition.
> It doesn't properly use methods.
There is no rule as to how methods *SHOULD* be used, just that a class
contains the methods which can opeate on its data.
> A change in the database (i.e. changing a column name) requires changing
> the program.
If you change a column name in your database then some code *HAS* to change
somewhere. This applies to everybody's code, not just mine. And even to
yours (if you ever write any that is).
> It exposes the names of the table columns you're using.
So what? Using the same column names in your screen that appear in the
database is not wrong. In my long career if anyone suggested using different
names they would be fired for stupidity.
> I could continue, but I know you'll discount everything I say.
At last you've said some with which I can agree.
> Crap programmers do that when informed why their code is crap.
The fact that *YOU* think my code is crap does not concern me in the least
as I place absolutely no value on your opinions.
> Good programmers try to learn.
You can't learn anything from a bad teacher.
<snip>
>>>>> With proper OO principles, the object requiring the rule implements
>>>>> the
>>>>> rule.
>>>>
>>>> But the rule has to be coded within the relevant class.
>>>
>>> That is correct. That's why the class is independent of the rest of the
>>> program. It implements it's own rules and data, which can be changed as
>>> long as the public methods don't change.
>>
>> Exactly, and that is what my framework achieves. The business rules for
>> each
>> entity are coded within the entity's class.
>
> And changes to the database require changes to your code. What happens,
> for instance, if you change the name of the column 'ship_date'?
>
> Or if you change it to three columns - ship_month, ship_date, ship_year?
Such changes to the database structure would require changes in anybody's
code, even yours. That is an inescapable fact.
<snip>
>> So how is $this->foo = 'bar' or $this->setFoo('bar') any different from
>> $this->fieldarray['foo'] = 'bar'? You still have to have a line of code
>> which says "set the value of 'foo' to 'bar'". They are just different
>> instructions which achieve the same result. You still have to know that
>> the
>> table object has a column called 'foo', so how does this expose the
>> internal
>> workings of the class?
>
> Because $this->setFoo('bar') validates the data right then.
But I don't have to use a setter to validate data, I can validate it
whenever and however I want. I don't inject variables one at a time using
setters, so I don't validate it in the setter. I inject all the data as a
single array, and I validate the entire contents of the array with a single
call to my validation object before it is sent to the database.
> And the table column may or may not be called 'foo', and the internal
> object may or may not be called 'foo'. In fact, the table object may be
> three different columns. for instance.
You are now adding unecessary complexity, so I shall not waste my time
explaining how I would deal with such a scenario.
<snip>
>>> Obviously you don't understand encapsulation at all.
>>
>> Encapsulation has nothing to do with data validation.
>
> Encapsulation has EVERYTHING do do with ensuring valid data.
There is nothing in the definition of encapsulation which dictates when and
how the data is validated. How I choose to do it and when I choose to do it
is *MY* choice, not yours.
>> <snip>
>>>>> 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.
>>>
>>> It can't be, because you have repeatedly stated the validation is done
>>> on
>>> an input array. There is nothing to stop me from putting that in the
>>> variable in the class because you don't have setter functions.
If you put that variable directly into the class instead of its data array
then it will be ignored simply because all the table objects use a single
array for all the table data.
>> If you try the line $object->ship_date = "This is stupid!"; then you are
>> not
>> updating the data array, and it is the data array which is used to update
>> the database. This means that your line of code will achieve nothing as
>> the
>> property 'ship_date' will never be referenced anywhere.
>
> OK, so you say $object->['ship_date'] = "This is stupid!";
>
> But I know you're too stoopid to understand the concept, even if the
> actual statement isn't updating the array.
It should be obvious to anyone that if you inject a piece of data into an
object using the wrong name then the object will ignore that data. The
object is coded to look for data with particular names, so if you use the
wrong name the fault is yours and not the object's.
> Or how about:
>
> $object = 'Really crap!';
Now you are being silly!
>> <snip>
>>>> The fact that the function accepts an array as its input is irrelevant
>>>> as
>>>> you are still spliting the array into its component parts.
>>>
>>> So? It has to be split into component parts anyway before inserting
>>> into
>>> the database. My way does it on input.
>>
>> In my framework the data array is never split into its component parts
>> until
>> it appears in the data access object where the SQL statement is
>> constructed
>> and executed.
>
> So? It has to be split.
Not in the table object, only in the data access object. And it is *NOT*
split so that it can be injected into the object one piece at a time using
setters.
>>> The advantage is that ALL write access to the object is controlled and
>>> validated because the programmer can't access private variables
>>> directly.
>>> Yours doesn't do that.
>>
>> Irrelevant. All input is validated before it gets written to the
>> database.
>> How I validate and when I validate is irrelevant.
>
> Completely relevant, if you're writing a complex program. But you've
> never done anything complex, so you wouldn't understand.
How and when input data is validated is irrelevant. It is only important
that it *IS* validated.
> In a complicated program the invalid value may be set thousands of lines
> before you actually update the database. The error should be detected
> when the value is set, not much later.
I repeat, how and when input data is validated is irrelevant. It is only
important that it *IS* validated.
>>>>> 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.
>>>
>>> You're the only one who keeps bringing up data hiding.
>>
>> Incorrect. It is *YOU* who keeps saying that I must use getters and
>> setters
>> because I should not access an object's properties directly (i.e. the
>> properties should be hidden)
>
> Which has nothing to do with data hiding. You're the only one who brings
> up data hiding.
Controlling access means changing a property's visibility from "public"
(visible) to "private" (hidden). A public property can be accessed directly,
whereas a private propery can only be accessed via a getter or a setter.
So, "controlling access" *DOES* mean hiding the data, and encapsulation
*DOES NOT* mean data hiding.
The original definition of encapsulation mentioned "implementation hiding"
which is *NOT* the same thing as "information hiding".
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.
>>> You're the only one who keeps bringing up data hiding.
>>
>> Incorrect. See above.
>>
>
> You're the only one who brings up data hiding.
>
>> <snip>
>>>> 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.
>>>
>>> Sure you can. But that is not polymorphism.
>>
>> If you have "same interface, different implementation" then you have
>> polymorphism. The "same interface" can either be inherited or hard-coded.
>>
>>> Polymorphism does not relate to siblings. Only to parent/child
>>> relationships.
>>
>> You are missing the point. All these siblings have the SAME PARENT
>> therefore
>> they inherit all the methods of the parent.
>
> No, your understanding of polymorphism is just as bad as your
> understanding of encapsulation. There is no polymorphism between
> siblings. Only when you have a parent-child relationship.
Polymorphism requires that different objects have the same interface (method
names). All siblings (i.e. subclasses which all inherit from the same
superclass) inherit all the method names from the superclass, so the same
method names are available in all the siblings. So, because the same method
names can be used on *ANY* of the siblings you automatically have
polymorphism.
--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2012-04-22 19:21 +0200 |
| Message-ID | <16487873.YAfrjsNhc7@PointedEars.de> |
| In reply to | #5570 |
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? 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.
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. That method is
called from the constructor so that I can write
$modelObj = new MyModel($array);
but if, and only if, I declare
public function setProperty($value)
{
$this->_property = convertPseudo($value);
return $this;
}
in the `MyModel' class, I can also add
$modelObj->setProperty($foo);
or
$modelObj->property = $foo;
to set the protected `_property' property of the object referred by
$modelObj to the value of $foo converted to a value of a type that
`_property' accepts, whereas the corresponding setter is called by the magic
`__set' method then. Likewise for read access and `__get'.
I have found that to be an effective, efficient and flexible combination.
>> 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?
>> 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?
> 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
[toc] | [prev] | [next] | [standalone]
| From | "Tony Marston" <tony@NOSPAM.demon.co.uk> |
|---|---|
| Date | 2012-04-23 13:50 +0100 |
| Message-ID | <Keclr.421390$nm6.195140@fx13.am4> |
| In reply to | #5659 |
"Thomas 'PointedEars' Lahn" <PointedEars@web.de> wrote in message news:16487873.YAfrjsNhc7@PointedEars.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
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2012-04-24 11:10 +0200 |
| Message-ID | <1400277.AFRqVoOGUt@PointedEars.de> |
| In reply to | #5670 |
Tony Marston wrote: > "Thomas 'PointedEars' Lahn" <PointedEars@web.de> wrote in message > news:16487873.YAfrjsNhc7@PointedEars.de... ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Please don't, see below. >> 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. It is a yes-or-no question, therefore it cannot be 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. […] > 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? >> 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. Your quoting (not corrected here for once) sucks big time. The options you have now are to learn to work around the shortcomings of your newsreader, use a working one, or be ignored. <http://insideoe.com/> > 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 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. >> 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. But in MVC, models are not data access objects. >>>> 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. >>>> 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. 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. 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 attacker could use that vulnerability to manipulate your database through the application in ways that you cannot conceive yet. This approach also does not appear to account for the possibility that with one request several tables need to be updated. Apropos, how you do implement queries across several tables (JOINs) with your framework? -- PointedEars
[toc] | [prev] | [next] | [standalone]
| From | "Tony Marston" <tony@NOSPAM.demon.co.uk> |
|---|---|
| Date | 2012-04-24 17:11 +0100 |
| Message-ID | <FgAlr.33422$636.32550@fx30.am4> |
| In reply to | #5697 |
"Thomas 'PointedEars' Lahn" <PointedEars@web.de> wrote in message news:1400277.AFRqVoOGUt@PointedEars.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
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2012-04-24 18:54 +0200 |
| Message-ID | <6244670.rdf3491b2I@PointedEars.de> |
| In reply to | #5699 |
Tony Marston wrote: > > "Thomas 'PointedEars' Lahn" <PointedEars@web.de> wrote in message > news:1400277.AFRqVoOGUt@PointedEars.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
[toc] | [prev] | [next] | [standalone]
| From | "Tony Marston" <tony@NOSPAM.demon.co.uk> |
|---|---|
| Date | 2012-04-24 18:55 +0100 |
| Message-ID | <MOBlr.160243$gk1.93088@fx26.am4> |
| In reply to | #5700 |
"Thomas 'PointedEars' Lahn" <PointedEars@web.de> wrote in message news:6244670.rdf3491b2I@PointedEars.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
[toc] | [prev] | [next] | [standalone]
| From | Erwin Moller <erwinmollerusenet@xs4all.nl> |
|---|---|
| Date | 2012-04-25 13:22 +0200 |
| Subject | [OT] Was: Dynamic form generation |
| Message-ID | <4f97de59$0$6976$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #5697 |
On 4/24/2012 11:10 AM, Thomas 'PointedEars' Lahn wrote: <snip> > It is a yes-or-no question, therefore it cannot be incorrect. > Yes, even yes-or-no questions can be incorrect, in the sense that both "yes" and "no" are incorrect answers. Here is an example: "This sentence is not true. Is the former sentence correct? Yes or no?" Regards, Erwin Moller -- "That which can be asserted without evidence, can be dismissed without evidence." -- Christopher Hitchens
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2012-04-25 12:46 +0100 |
| Subject | Re: [OT] Was: Dynamic form generation |
| Message-ID | <jn8o69$i7h$2@news.albasani.net> |
| In reply to | #5719 |
Erwin Moller wrote: > On 4/24/2012 11:10 AM, Thomas 'PointedEars' Lahn wrote: > > <snip> > >> It is a yes-or-no question, therefore it cannot be incorrect. >> > > Yes, even yes-or-no questions can be incorrect, in the sense that both > "yes" and "no" are incorrect answers. > > Here is an example: > "This sentence is not true. Is the former sentence correct? Yes or no?" > "Have you stopped beating your wife?: Yes or no?" There are some good examples of unanswerable questions somewhere on a philosophy forum.. > > Regards, > Erwin Moller > > -- To people who know nothing, anything is possible. To people who know too much, it is a sad fact that they know how little is really possible - and how hard it is to achieve it.
[toc] | [prev] | [next] | [standalone]
| From | "Tony Marston" <tony@NOSPAM.demon.co.uk> |
|---|---|
| Date | 2012-04-26 12:51 +0100 |
| Subject | Re: [OT] Was: Dynamic form generation |
| Message-ID | <EEamr.265212$sE1.211943@fx22.am4> |
| In reply to | #5719 |
"Erwin Moller" <erwinmollerusenet@xs4all.nl> wrote in message news:4f97de59$0$6976$e4fe514c@news2.news.xs4all.nl... > On 4/24/2012 11:10 AM, Thomas 'PointedEars' Lahn wrote: >> It is a yes-or-no question, therefore it cannot be incorrect. > > Yes, even yes-or-no questions can be incorrect, in the sense that both > "yes" and "no" are incorrect answers. > > Here is an example: > "This sentence is not true. Is the former sentence correct? Yes or no?" Your example is irrelevant. The original statement came in 2 parts: (1) "This means that you perform no type conversion or checking, or range checking in the application." followed by the question (2) "yes?". The question (2) I read as "is the statement (1) correct or incorrect?" to which I answered "incorrect". -- Tony Marston http://www.tonymarston.net http://www.radicore.org
[toc] | [prev] | [next] | [standalone]
| From | Erwin Moller <erwinmollerusenet@xs4all.nl> |
|---|---|
| Date | 2012-04-27 10:26 +0200 |
| Subject | Re: [OT] Was: Dynamic form generation |
| Message-ID | <4f9a5844$0$6849$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #5745 |
On 4/26/2012 1:51 PM, Tony Marston wrote: > "Erwin Moller"<erwinmollerusenet@xs4all.nl> wrote in message > news:4f97de59$0$6976$e4fe514c@news2.news.xs4all.nl... >> On 4/24/2012 11:10 AM, Thomas 'PointedEars' Lahn wrote: >>> It is a yes-or-no question, therefore it cannot be incorrect. >> >> Yes, even yes-or-no questions can be incorrect, in the sense that both >> "yes" and "no" are incorrect answers. >> >> Here is an example: >> "This sentence is not true. Is the former sentence correct? Yes or no?" > > Your example is irrelevant. Of course. Hence the added "OT" to the thread subject. OT means "Off Topic". "Off Topic" means I am aware I am adding something that isn't relevant to the discussion. Maybe you don't know what OT means. Maybe you didn't see it in the subject? Why did I add OT? I didn't want to get involved in the discussion itself (but which I am reading with interest). And I was responding to Thomas Lahn, who stated that a yes-or-no question cannot be incorrect, which is not always true. Lahn: "It is a yes-or-no question, therefore it cannot be incorrect." This is a technical newsgroup for programmers. IMHO ALL programmers should at least be mildly interested in the example I gave, and its implications. Regards, Erwin Moller -- "That which can be asserted without evidence, can be dismissed without evidence." -- Christopher Hitchens
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2012-04-28 07:56 +0200 |
| Subject | [OT] Yes-or-no questions (was: [OT] Was: Dynamic form generation) |
| Message-ID | <2276436.MPYeS1zdeI@PointedEars.de> |
| In reply to | #5745 |
Tony Marston wrote:
> "Erwin Moller" [wrote]:
>> On 4/24/2012 11:10 AM, Thomas 'PointedEars' Lahn wrote:
>>> It is a yes-or-no question, therefore it cannot be incorrect.
>>
>> Yes, even yes-or-no questions can be incorrect, in the sense that both
>> "yes" and "no" are incorrect answers.
>>
>> Here is an example:
>> "This sentence is not true. Is the former sentence correct? Yes or no?"
>
> Your example is irrelevant.
It is not irrelevant, but it is wrong. A yes-or-no question that cannot be
answered with a simple "yes" or "no" is _not_ incorrect. But it is harder
to answer. It also *might* indicate a fallacy, in which latter case the Zen
masters have given us the word "mu" to avoid a wrong answer.
> The original statement came in 2 parts:
> (1) "This means that you perform no type conversion or checking, or range
> checking in the application."
> followed by the question
> (2) "yes?".
>
> The question (2) I read as "is the statement (1) correct or incorrect?" to
> which I answered "incorrect".
And there you are wrong. It was _not_ a statement, it was a *question*.
Statements end with a period. Questions end with a question mark. This
sentence ended with a question mark. A reasonable answer to that question,
since it was a yes-or-no question, would have started with "Yes" or "No" or
be a statement having these words as bottom line. But _not_ "Correct" or
"Incorrect". I concede that it was a suggestive question, but that does not
make it incorrect.
The way the Subject header field was changed here is inappropriate. For a
start, it is insufficient to tag a posting as off-topic; the new topic needs
to be provided as well. The common, reasonable and accepted change is
described at <http://www.netmeister.org/news/learn2quote.html>. There you
(Tony) will also find a description on the attribution that you are still
ignoring.
F'up2 poster
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | comp.lang.php
csiph-web