Home » Imported messages » comp.lang.php » Dynamic form generation

Show: Today's Messages :: Polls :: Message Navigator

Re: Dynamic form generation [message #177815 is a reply to message #177791] Sun, 22 April 2012 09:27   Tony Marston Messages: 57 Registered: November 2010 Karma: 0 Member "Jerry Stuckle" wrote in message news:jmu1nc$fui$1(at)dont-email(dot)me... > > On 4/21/2012 5:35 AM, Tony Marston wrote: <snip> > From your description, any good programmer can tell your code is crap. > Only those like yourself can't see crap when it's described. Your definition of crap code seems to be nothing more than "it doesn't follow my rules, therefore it must be crap". >> By "vast majority" I mean the "vast majority of people who send me >> emails about my work". For every 100 I receive 99 of them are >> complimentary. The other 1% are nothing but personal insults, sent >> anonymously and without valid return addresses. >> > > Yea, right. And what is the experience of those programmers? PHP > programmers as a whole are not known for their intelligence or competence. > In fact, just the opposite is true. So, as this is a newsgroup for PHP programmers you are effectively saying that every member of this group is stupid and incompetent? Do you know how arrogant that makes you sound? > But then you're a great example of the latter. Have you looked in the mirror lately? <snip> > Horse hockey. You don't have an ERP system. You don't even know what an > ERP system is, and have never seen a real one. You've got a simple order > entry/tracking system. Any competent programmer can do the same in a short > time. My system qualifies as an ERP system according to the definition in wikipedia. The fact that it does not satisfy your personal definition is irrelevant. >>>> <snip> >>>> >> I don't GET/SET individual fields - everything (by this I mean >>>> >> database >>>> >> data) goes in as an array, and everything comes out as an array. The >>>> >> idea of >>>> >> unpicking the array to inject every value individually strikes me as >>>> >> being >>>> >> inefficient, and therefore bad practice. >>>> >> >>>> > >>>> > Gee, which means you have to build an array for the whole object every >>>> > time you need to change one property. Which means the rest of the >>>> > program is also dependent on that object. More bloat. More complexity. >>>> >>>> I don't need to build an array as the array is provided for me. If it >>>> comes from the user it is the $_POST array. If it comes from the >>>> database it is an array of rows and columns. >>>> >>>> How is using an array which can contain any number of columns and >>>> values >>>> "more complex" than having to define a separate variable for each >>>> column, and a separate getter/setter for each column. My method uses >>>> LESS code therefore it is LESS complex. >>>> >>> >>> And if the application needs to change one value without using the >>> $_POST array, it has to build an entire array just to set the one >>> value. Bloat! >>> >>> There are reasons for SET/GET methods. >> >> Just as there are reasons NOT to use them. I may insert data into an >> object with a setter, or I may use an argument on a method call. I find >> it much easier (ie: less coding) to insert the $_POST array as a >> complete array in a single method argument that to split it into its >> component parts and "set" each component one at a time. >> > > What do you think a setter is if it's not a method? And you never have > answered how the programmer can change one property without building a > whole array. Or get a single property? The table data already exists in the object as an array, so the programmer can examine or change the contents of the array at will. The programmer does not have to build the array, it is already there! Why can't you understand such a simple concept? > Also, the presence of set/get methods does not preclude the parsing of > arrays. I have both, for instance. > >>> If you understood even the very basics of OO programming (one of which >>> is encapsulation), you would know why they are needed. >> >> Getters and setters are NOT required for encapsulation. Encapsulation >> means *implementation* hiding, not *information* hiding. >> > > Yes, and the properties of the class (i.e. variables) are part of the > implementation. Implementation means code, not data. >>> Less code does not mean less complexity. In fact, just the opposite >>> can be true. >> >> Less code to write means less time to write it, less time to test (as >> the pre-written functions have already been tested), and less >> maintenance. That has been my experience over 30 years, and nothing you >> can say will change my opinion. >> > > That also is not necessarily true. Yes, pre-written functions are great. > That's why I use them in my code generator. My framework generates less code than yours because it uses more generalised functions. I don't use the copy paste method that you seem to favour. > But less code can mean MORE complexity. However, you've never worked on > anything non-trivial, so you wouldn't understand. How can less code be more complex? <snip> >> Take a look at the definition of "ERP" at >> http://en.wikipedia.org/wiki/Enterprise_resource_planning and tell me >> I'm wrong. I don't have all the modules listed there, but SME's don't >> need all those modules. > > I suggest you read it. An ERP system HAS all the modules. You can't pick > and choose. It's an integrated system. If you read the definition properly you will see that it is a set of integrated modules, and not all users require all modules. My ERP system does much more than deal with just sales orders. It does what my users want, and I care more for their opinion than I do yours. <snip> >> No I don't. You told me yourself that you regularly cut, paste and >> modify code. I don't need to do that as the code is defined once in a >> reusable function. > > Exactly. But that's not duplicated code. It's starting with a code > template and modifying it to suit my needs. That way you don't need to > start from scratch every time. If you were really competent you would create a version of that code template that could be reused as a single function instead of having to be copied and modified multiple times. <snip> >> An application can be described as "complex" by looking at the volume of >> business rules which have to be implemented. Using the Radicore >> framework I can quickly generate working transactions which already >> handle the boring work of moving data between the database and the user >> interface, which leaves maximum time to spend on the payload, the >> business rules. >> > > You can claim that for your simple database applications. But then you > need to do that to satisfy yourself you're working on "complex" > applications. Those of us who have worked on truly complex applications > know better. A complex application has complex business rules. A simple application has simple business rules. The number of lines of code is irrelevant. If I can take an application that uses 3M LOC and achieve the same result using half as many LOC would that automatically make my version half as complex? I think not. >>>> >>> None of those use frameworks because the frameworks don't work. >>>> >> >>>> >> You mean that the frameworks which you have used didn't work. If you >>>> >> write >>>> >> an application with> 3M LOC *WITHOUT* using a framework, even if you >>>> >> have >>>> >> to build it yourself, then you are not an efficient programmer. >>>> >> >>>> > >>>> > Nope. What kind of framework do you use for an OS, for instance? >>>> >>>> What has building an OS got to do with this conversation? This is a PHP >>>> newsgroup, which means that we are supposed to be talking about web >>>> applications written in PHP. >>>> >>> >>> An OS is an application. You claim all this knowledge of great >>> techniques. So have you ever written an OS? Or how about a compiler? >> >> I repeat, this is a PHP newsgroup, which means that we are supposed to >> be talking about web applications written in PHP. >> > So? You've claimed you've worked on "database applications for decades". > That's long before PHP existed. You opened the door. Now you're > backpedaling. Typical. I am not back pedalling. This newsgroup is for people who write database applications in PHP, so comments about writing operating systems or compilers are irrelevant. Before I starting writing database applications with PHP I wrote database applications with a variety of other languages. That shows that my experience of writing database applications has not been confined to the PHP language. Tellme how that is back pedalling? >> Applications which are NOT web applications and NOT written in PHP are >> irrelevant. > > Only because all you do are trivial applications in PHP - and you do it > poorly, at that. > >>> Even DOS 1.0 was more complex than anything you've written. >> >> DOS is not a web application written in PHP, so it's irrelevant. > > Nope, and neither were the "decades of database applications" you claimed > to have written in the very post I'm replying to. The fact that my experience with other languages meant that I wrote database applications for the desktop does not mean that it is totally irrelevant when using PHP to write database applications for the web. A database application is a database application regardless of whether the user interface is the web or the desktop. > Nor is database normalization (which you also claimed to know how to do > properly - which I also doubt) in that same post. I shall treat that remark with the contempt it deserves. > But the incompetent need to have it both ways - ignore the rules when it > benefits them but claim it's off topic when the rules don't suit them. You so are saying that I'm incompetent simply because I refuse to follow YOUR rules? Do you know how arrogant that makes you? <snip> >>>> > And what about existing passwords which don't follow the new rules? >>>> >>>> The password rules only apply to new passwords. >>> >>> So then you have a mixture of both old and new rules. >> >> No. Validation rules only apply when a value is entered, not read. If a >> user is forced to change his password after a number of days, or a >> number of logons, then any change in rules is only applied when he >> changes his password. A change in validation rules has no effect on >> existing passwords. > > Which means a mixture of conformant and non-conformant passwords in your > database. Anyone knowledgeable of security would cringe at such a setup. Any competent person would tell you that if the password validation rules are changed in such a way as to make all exissting passwords non-conformant then you get everybody to change their passwords so that all NEW passwords conform to the NEW rules. > But it really doesn't matter - it's all bloatware anyway. > >>>> > But again, more bloatware. >>>> >>>> Wrong. I'm providing the ability for a customer to tailor the password >>>> rules to his own specifications without the need to make any code >>>> changes. How is that "bloatware"? >>>> >>> >>> Because it's code that adds unnecessary complexity to the code, for an >>> unnecessary feature. But you've shown you're good at that. >> >> It is not an unnecessary feature. Different customers may have different >> rules, and I can satisfy those rules without having to change a single >> line of code. >> > > Bloatware. If a customer wants a customized password rule, it's one line > of code to change. And it doesn't add all that unnecessary complexity > (bloatware) to the script. So you are admitting that in YOUR implementation if you want to change the password validation rules then you have to change your code. In MY implementation this can be done by changing a value in the database, and you have the audacity and arrogance to call that bloat! >>> How many customers have actually demanded the need to change the >>> rules? In over 30 years of programming for clients, none of mine have. >> >> None have had to demand such a facility for the simple reason that it is >> supplied as standard. >> > > My point exactly. Bloatware. A feature no one wants or cares about. My customers care for it, and their opinion means more to me than yours. <snip> >> The major customer of my ERP system took a look at various ecommerce >> packages before deciding that they weren't good enough, which is why I >> was asked to design and build a "proper" system for them. >> > > You don't have an ERP system. You have a simple order entry/tracking > system. > > And maybe they should have hired a competent consultant who could have > recommended a proper system for them at a fraction of the cost you charged > them for your custom system. Your personal insults are adding nothing to this newsgroup. Please try showing a bit more professionalism and maturity. -- Tony Marston http://www.tonymarston.net http://www.radicore.org Report message to a moderator

Re: Dynamic form generation [message #177816 is a reply to message #177798] Sun, 22 April 2012 10:45   Tony Marston Messages: 57 Registered: November 2010 Karma: 0 Member "Jerry Stuckle" wrote in message news:jmufmh$peq$1(at)dont-email(dot)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 Report message to a moderator

Re: Dynamic form generation [message #177818 is a reply to message #177816] Sun, 22 April 2012 14:09   Jerry Stuckle Messages: 2598 Registered: September 2010 Karma: 0 Senior Member On 4/22/2012 6:45 AM, Tony Marston wrote: > "Jerry Stuckle" wrote in message news:jmufmh$peq$1(at)dont-email(dot)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(at)attglobal(dot)net ================== Report message to a moderator

Re: Dynamic form generation [message #177821 is a reply to message #177815] Sun, 22 April 2012 14:43   Jerry Stuckle Messages: 2598 Registered: September 2010 Karma: 0 Senior Member On 4/22/2012 5:27 AM, Tony Marston wrote: > "Jerry Stuckle" wrote in message news:jmu1nc$fui$1(at)dont-email(dot)me... >> >> On 4/21/2012 5:35 AM, Tony Marston wrote: > <snip> >> From your description, any good programmer can tell your code is crap. >> Only those like yourself can't see crap when it's described. > > Your definition of crap code seems to be nothing more than "it doesn't > follow my rules, therefore it must be crap". > My definition of crap code is that "it is bloated, overly complicated and doesn't follow generally recognized rules". IOW, everything you've shown your code to be. >>> >> >> Yea, right. And what is the experience of those programmers? PHP >> programmers as a whole are not known for their intelligence or >> competence. In fact, just the opposite is true. > > So, as this is a newsgroup for PHP programmers you are effectively > saying that every member of this group is stupid and incompetent? Do you > know how arrogant that makes you sound? > No, you're putting words in my mouth (again). I'm not saying every member of this group is stupid or incompetent. There are a number of people here who are quite intelligent and competent, whose opinions I regard highly. But there are a few here who are stupid and incompetent. This especially goes for people who think they can ignore any rules they don't feel like implementing, and can call a simple order entry/tracking system an ERP system. You're just continuing to show your stupidity, Tony. You should have quit while you were ahead (not that you ever were). >> But then you're a great example of the latter. > > Have you looked in the mirror lately? > Ah, a comment I would expect from a three-year-old. About your speed. > <snip> >> Horse hockey. You don't have an ERP system. You don't even know what >> an ERP system is, and have never seen a real one. You've got a simple >> order entry/tracking system. Any competent programmer can do the same >> in a short time. > > My system qualifies as an ERP system according to the definition in > wikipedia. The fact that it does not satisfy your personal definition is > irrelevant. > No, it does not. It is a simple order entry/tracking system. But you can lie about it all you want. It just shows you are dishonest as well as stupid. >> >> What do you think a setter is if it's not a method? And you never have >> answered how the programmer can change one property without building a >> whole array. Or get a single property? > > The table data already exists in the object as an array, so the > programmer can examine or change the contents of the array at will. The > programmer does not have to build the array, it is already there! Why > can't you understand such a simple concept? > Yes, you've already said you don't understand one of the basic principles of OO programming - encapsulation. >> Also, the presence of set/get methods does not preclude the parsing of >> arrays. I have both, for instance. >> >>>> If you understood even the very basics of OO programming (one of which >>>> is encapsulation), you would know why they are needed. >>> >>> Getters and setters are NOT required for encapsulation. Encapsulation >>> means *implementation* hiding, not *information* hiding. >>> >> >> Yes, and the properties of the class (i.e. variables) are part of the >> implementation. > > Implementation means code, not data. > That's where you don't understand even basic OO. Implementation means both code and data. >>>> Less code does not mean less complexity. In fact, just the opposite >>>> can be true. >>> >>> Less code to write means less time to write it, less time to test (as >>> the pre-written functions have already been tested), and less >>> maintenance. That has been my experience over 30 years, and nothing you >>> can say will change my opinion. >>> >> >> That also is not necessarily true. Yes, pre-written functions are >> great. That's why I use them in my code generator. > > My framework generates less code than yours because it uses more > generalised functions. I don't use the copy paste method that you seem > to favour. > Your framework generates less code because it's only a half-assed implementation of even basic OO principles (which you have repeatedly shown you don't understand). >> But less code can mean MORE complexity. However, you've never worked >> on anything non-trivial, so you wouldn't understand. > > How can less code be more complex? > Again, it shows how little you know. Just because there code is smaller does not mean it's easier to understand. Sometimes it's better to add code to make it more understandable. > <snip> >>> Take a look at the definition of "ERP" at >>> http://en.wikipedia.org/wiki/Enterprise_resource_planning and tell me >>> I'm wrong. I don't have all the modules listed there, but SME's don't >>> need all those modules. >> >> I suggest you read it. An ERP system HAS all the modules. You can't >> pick and choose. It's an integrated system. > > If you read the definition properly you will see that it is a set of > integrated modules, and not all users require all modules. My ERP system > does much more than deal with just sales orders. It does what my users > want, and I care more for their opinion than I do yours. > No, not all users require all modules. However, all ERP systems PROVIDE all modules. But once again you show how dishonest your are by claiming your code is something it isn't. > <snip> >>> No I don't. You told me yourself that you regularly cut, paste and >>> modify code. I don't need to do that as the code is defined once in a >>> reusable function. >> >> Exactly. But that's not duplicated code. It's starting with a code >> template and modifying it to suit my needs. That way you don't need to >> start from scratch every time. > > If you were really competent you would create a version of that code > template that could be reused as a single function instead of having to > be copied and modified multiple times. > And you've just proved that once again you have no idea what you're talking about. A good example - a table with 25 columns. Most are text/numeric, but one is a 20MB BLOB. In one form you want to display all columns in a two column table (label/value). This one is easy. In a second case you want to display 10-16 of those columns in a 4-column table; 6 columns will be displayed or not based on values in other columns. 1 (the BLOB) will be displayed if it is not null. In the third case, you want to display 5 columns in a 5 column table row (only). You do not want to retrieve the BLOB column as it is unnecessary overhead (bloat). Let's see your template do that. > <snip> >>> An application can be described as "complex" by looking at the volume of >>> business rules which have to be implemented. Using the Radicore >>> framework I can quickly generate working transactions which already >>> handle the boring work of moving data between the database and the user >>> interface, which leaves maximum time to spend on the payload, the >>> business rules. >>> >> >> You can claim that for your simple database applications. But then you >> need to do that to satisfy yourself you're working on "complex" >> applications. Those of us who have worked on truly complex >> applications know better. > > A complex application has complex business rules. A simple application > has simple business rules. The number of lines of code is irrelevant. If > I can take an application that uses 3M LOC and achieve the same result > using half as many LOC would that automatically make my version half as > complex? I think not. > In your universe, yes. Anyone who has worked on truly complex applications knows better. But people who only do simple database applications think a few rules make something complex. I hate to burst your balloon, but it doesn't. You can keep deluding yourself, though. >>> >> So? You've claimed you've worked on "database applications for >> decades". That's long before PHP existed. You opened the door. Now >> you're backpedaling. Typical. > > I am not back pedalling. This newsgroup is for people who write database > applications in PHP, so comments about writing operating systems or > compilers are irrelevant. > You are back-pedalling. This is not a database newsgroup, nor is it a newsgroup for people who write database applications. You brought up databases, not me. > Before I starting writing database applications with PHP I wrote > database applications with a variety of other languages. That shows that > my experience of writing database applications has not been confined to > the PHP language. Tellme how that is back pedalling? > All database applications. Trivial to anyone who's ever worked on truly complex applications. You brought up an irrelevant subject, and now you're back-pedaling because I pointed out the fallacy in your argument. The fact is all you've EVER done is simple database applications. You have no idea what a complicated application is. >>> Applications which are NOT web applications and NOT written in PHP are >>> irrelevant. >> >> Only because all you do are trivial applications in PHP - and you do >> it poorly, at that. >> >>>> Even DOS 1.0 was more complex than anything you've written. >>> >>> DOS is not a web application written in PHP, so it's irrelevant. >> >> Nope, and neither were the "decades of database applications" you >> claimed to have written in the very post I'm replying to. > > The fact that my experience with other languages meant that I wrote > database applications for the desktop does not mean that it is totally > irrelevant when using PHP to write database applications for the web. A > database application is a database application regardless of whether the > user interface is the web or the desktop. > You're bringing up other languages and databases claiming they're relevant - yet when I mention other languages or applications you claim they are irrelevant. The truth is you have no leg to stand on so you keep trying to change the subject and/or claim something is irrelevant. >> Nor is database normalization (which you also claimed to know how to >> do properly - which I also doubt) in that same post. > > I shall treat that remark with the contempt it deserves. > Good. You are contemptful. >> But the incompetent need to have it both ways - ignore the rules when >> it benefits them but claim it's off topic when the rules don't suit them. > > You so are saying that I'm incompetent simply because I refuse to follow > YOUR rules? Do you know how arrogant that makes you? > No, widely recognized rules by experts. But you refuse to follow them. Do you know how arrogant (and stupid) that makes YOU? But once again you refuse to discuss the issue and attack back. You're only showing your stupidity. >> Which means a mixture of conformant and non-conformant passwords in >> your database. Anyone knowledgeable of security would cringe at such a >> setup. > > Any competent person would tell you that if the password validation > rules are changed in such a way as to make all exissting passwords > non-conformant then you get everybody to change their passwords so that > all NEW passwords conform to the NEW rules. > Which is why you set the rules ahead of time. But that's not what you claimed earlier, so you have to once-again back-pedal. >> But it really doesn't matter - it's all bloatware anyway. >> >>> >> >> Bloatware. If a customer wants a customized password rule, it's one >> line of code to change. And it doesn't add all that unnecessary >> complexity (bloatware) to the script. > > So you are admitting that in YOUR implementation if you want to change > the password validation rules then you have to change your code. In MY > implementation this can be done by changing a value in the database, and > you have the audacity and arrogance to call that bloat! > Sure. It's a one line change to the code. Quick, simple, and straightforward. But once a system is installed, I've NEVER had a customer ask for the rules to be changed. That's because we discuss the pros and cons of different rules up front. Plus I don't have to stay on the phone trying to talk the customer through how to implement his new rules. Your method is nothing but bloat - which is why you're the only one who's ever implemented such a stupid concept. >>>> How many customers have actually demanded the need to change the >>>> rules? In over 30 years of programming for clients, none of mine have. >>> >>> None have had to demand such a facility for the simple reason that it is >>> supplied as standard. >>> >> >> My point exactly. Bloatware. A feature no one wants or cares about. > > My customers care for it, and their opinion means more to me than yours. > I highly doubt your customers give a damn about it. Maybe they do because you sold them on how great it is - but then snake oil salesmen are good at that. > <snip> >>> The major customer of my ERP system took a look at various ecommerce >>> packages before deciding that they weren't good enough, which is why I >>> was asked to design and build a "proper" system for them. >>> >> >> You don't have an ERP system. You have a simple order entry/tracking >> system. >> >> And maybe they should have hired a competent consultant who could have >> recommended a proper system for them at a fraction of the cost you >> charged them for your custom system. > > Your personal insults are adding nothing to this newsgroup. Please try > showing a bit more professionalism and maturity. > No personal insult. Just the truth. You want the king of personal insults, look back through your own posts. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex(at)attglobal(dot)net ================== Report message to a moderator

Re: Dynamic form generation [message #177824 is a reply to message #177739] Sun, 22 April 2012 17:21   Thomas 'PointedEars' Messages: 701 Registered: October 2010 Karma: 0 Senior Member 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 Report message to a moderator

Re: Dynamic form generation [message #177829 is a reply to message #177755] Sun, 22 April 2012 21:59   Thomas 'PointedEars' Messages: 701 Registered: October 2010 Karma: 0 Senior Member Tony Marston wrote: > "Jerry Stuckle" wrote: >> On 4/19/2012 4:27 AM, Tony Marston wrote: >>> "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message >>> news:jmmauq$9ke$1(at)dont-email(dot)me... > <snip> >>>> >> You've been doing it that badly all this time? >>>> > >>>> > Not according to my fellow developers and paying customers. >>>> First rule is that customers don't know anything about good coding. >>>> And >>>> your fellow developers could easily be as bad as you. No credibility >>>> there. >>> Delivering code which satisfies the client takes a higher priority than >>> writing code which satisfies other programmers. It is not possible to >>> write code which satisfies EVERY programmer on the plant as they all >>> have different ideas as to what "best practice" actually is. >> >> It is when you're only doing simple stuff. REAL programmers concentrate >> on making their code MAINTAINABLE. Full ACK. I have never cared if the client would accept or even understand my code; indeed, if I told my boss that from now on I would be writing code that way, I would probably be fired on the spot because it does not pay. My clients so far are not programmers; it is difficult for them to understand the basic concepts of programming to begin with. The client has ordered an application for a price, and they are going to get the best application that can I can do for that price, with a profit margin, an error margin, and future maintenance in mind. As a result, my fellow developers are going to get the best maintainable code that I can write under those conditions (which really is not hard to do once you have accustomed yourself to some basic rules and tools of software development). > You have no basis on which to make the statement that my code is > unmaintainable. My code has been reviewed by many others, and the vast > majority have nothing but compliments. This is a common fallacy, a self-fulfilling prophecy, that many developers try to rationalize (their) bad code quality with. For you cannot know how many people have read the code *and* found it so bad that they did not care to point out its flaws to you. Nor can you know how knowledgable the people are who have reviewed the code and found it to be good. However, inevitably there are more people not knowing what they are doing than people knowing what they are doing: for any given field, there are many laymen, fewer intermediates, and very few experts. So the odds are against that from the mere majority of a randomly selected set of opinions a realistic assessment of any subject can be derived. This applies especially to source code as software development is a very special field. And the odds are against that expert in that field would bother complaining about bad code of others as they – being skilled in writing good code – would simply write the code to solve the problem themselves, if need be, or just move on to your competition. HTH PointedEars, with a fitting random signature -- > If you get a bunch of authors […] that state the same "best practices" > in any programming language, then you can bet who is wrong or right... Not with javascript. Nonsense propagates like wildfire in this field. -- Richard Cornford, comp.lang.javascript, 2011-11-14 Report message to a moderator

Re: Dynamic form generation [message #177834 is a reply to message #177824] Mon, 23 April 2012 12:50   Tony Marston Messages: 57 Registered: November 2010 Karma: 0 Member "Thomas 'PointedEars' Lahn" <PointedEars(at)web(dot)de> wrote in message news:16487873(dot)YAfrjsNhc7(at)PointedEars(dot)de... > Tony Marston wrote: > >> "Jerry Stuckle" wrote: >>> On 4/18/2012 4:33 AM, Tony Marston wrote: >>>> > If a framework attempts to be "all things to all people", then that's >>>> > quite true. But the same is true of *any* code. >>>> > >>>> > However, a limited framework with limited goals doesn't necessarily >>>> > have to be the case. >>>> > >>>> > For instance, in my case - I have a framework which builds PHP classes >>>> > to interface to a database. It generates a lot of usable code for >>>> > those classes, including form handling. >>>> >>>> So you framework generates "a lot" of code, does it? My framework >>>> generates very small amounts of code which call shared functions or >>>> which inherit code from abstract classes. >>> >>> Yup, for instance, it generates all the set and get methods for the >>> applicable class, as well as database access code (insert/update/delete >>> for single rows and single rows and lists of multiple rows for SELECT). >>> (Most of the access code is in parent classes). >> >> My framework does not bother generating set and get methods as they are >> inefficient. Data goes in and comes out as an array. > > This means that you perform no type conversion or checking, or range > checking in the application, yes? Incorrect. If my ADD controller contains the line $result = $dbobject->insertRecord($_POST); then the entire $_POST array is passed to that object. I do not have to break it down into its compnent parts and inject each component individually. The contents of the array is then validated by the framework to ensure that all columns maked as NOT NULL are not empty, all date fields are dates, all numeric fields are numbers and within range, et cetera. This does not require any code to be written by the programmer as the standard validation class uses the field specifications which were exported from my data dictionary which in turn were imported from the database schema. If any validation fails then an error message is generated and control returned to the calling object. It is only after the data has passed all validation rules that it is passed to my data access object where the relevant sql INSERT statement is constructed and executed. Just because I say that the programmer does not have to write code does not mean that the data is never validated. It always is, but as an automatic function of thre framework. > Setters and getters maybe are less > efficient than direct access, but they can provide that functionality. > They > also provide transparent access to the data model (i. e., if either your > requests or your database change, you do not have to change the request > for > the database or the database for the request; you just change the mapping > code). Using arrays does not exclude the possibility for using setters > and > getters or vice-versa, as setters and getters can be called implicitly, > such > as from a constructor. Just because a lot of OOP tutorials show the use of getters and setters does not mean that I *HAVE* to use them. I don't see why I should pass in a collection of values using multiple setters when I can achieve the same result by passing in the entire collection as a single array variable. > In the MVC-based framework I have written for my latest research, the > parent > abstract `AbstractModel' class has an inherited public map() method that > can > be passed an associative array (such as from a query result) and maps > array > elements to object properties such that either all, only the specified or > not the specified elements in the passed array are mapped. My database table objects do not have a separate property for each column within that table, so I don't need getters and setters for each column. All the table data passes both in and out as a single array variable which can contain any number of rows and columns. Within my table object I can reference any column property with $this->fieldarray['column1'] just as easily as I can with $this->column1 This means that I don't need a separate class variable for each column, which in turn means that I don't ned a separate getter and setter for each column. <snip> > >>> It also generates the code necessary to validate a field. Some stock >>> fields (like "must be integer") have predefined validation functions. >> >> My framework does not generate any code to perform basic field validation >> as that is performed by a validation class which I wrote years ago. > > So that validation class has become part of the framework, has it not? Absolutely correct. I wrote the validation class years ago, and it compares the fielddata array with the contents of the fieldspec array. The fieldspec array defines how each field is to be validated. The fieldspec array does not have to be coded by the programmer as it is generated by the framework using details which were originally extracted from the database schema. >>> It also has a function to populate the object from $_GET or $_POST >>> values >>> (with validation). >> >> I don't need a whole function to do that when a single line will do:- >> $result = $object->insertRecord($_POST); >> >> This means that the same line will work on any object regardless of which >> class it came from. That is what polymorphism is all about. > > It also means that your HTTP POST requests are inherently bound to the > structure of the database (table), does it not? Why? The $_POST array is simply an associative array, and the only thing it is "bound" to is the HTML form which generated it. If the $_POST array contains any field names which do not exist in the database table then those fields simply will not appear in the sql query which is generated. >> I was never dishonest about the Radicore framework. I never said it was >> written by someone else. I even include a link to the radicore website in >> my signature. > > I am going to look into it, then. > > -- > PointedEars I would welcome constructive criticism. -- Tony Marston http://www.tonymarston.net http://www.radicore.org Report message to a moderator

Re: Dynamic form generation [message #177835 is a reply to message #177829] Mon, 23 April 2012 13:05   Tony Marston Messages: 57 Registered: November 2010 Karma: 0 Member "Thomas 'PointedEars' Lahn" <PointedEars(at)web(dot)de> wrote in message news:2055880(dot)9alNe96dWn(at)PointedEars(dot)de... > Tony Marston wrote: > >> "Jerry Stuckle" wrote: >>> On 4/19/2012 4:27 AM, Tony Marston wrote: >>>> "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message >>>> news:jmmauq$9ke$1(at)dont-email(dot)me... >> <snip> >>>> >>> You've been doing it that badly all this time? >>>> >> >>>> >> Not according to my fellow developers and paying customers. >>>> > First rule is that customers don't know anything about good coding. >>>> > And >>>> > your fellow developers could easily be as bad as you. No credibility >>>> > there. >>>> Delivering code which satisfies the client takes a higher priority than >>>> writing code which satisfies other programmers. It is not possible to >>>> write code which satisfies EVERY programmer on the plant as they all >>>> have different ideas as to what "best practice" actually is. >>> >>> It is when you're only doing simple stuff. REAL programmers concentrate >>> on making their code MAINTAINABLE. > > Full ACK. I have never cared if the client would accept or even > understand > my code; indeed, if I told my boss that from now on I would be writing > code > that way, I would probably be fired on the spot because it does not pay. > My > clients so far are not programmers; it is difficult for them to understand > the basic concepts of programming to begin with. > > The client has ordered an application for a price, and they are going to > get > the best application that can I can do for that price, with a profit > margin, > an error margin, and future maintenance in mind. As a result, my fellow > developers are going to get the best maintainable code that I can write > under those conditions (which really is not hard to do once you have > accustomed yourself to some basic rules and tools of software > development). > >> You have no basis on which to make the statement that my code is >> unmaintainable. My code has been reviewed by many others, and the vast >> majority have nothing but compliments. > > This is a common fallacy, a self-fulfilling prophecy, that many developers > try to rationalize (their) bad code quality with. For you cannot know how > many people have read the code *and* found it so bad that they did not > care > to point out its flaws to you. Nor can you know how knowledgable the > people > are who have reviewed the code and found it to be good. The trouble is that there is no objective method of deciding whether someone's code is "not crap", "mildly crap" or "total crap". It is always subjective, with the only universal rule being "If it's different from mine then it's bo8und to be crap!" If you bother looking at my code you will see that it is properly modularised, properly commented, has meaningful data names and function names, and achieves its results as simply as possible. Other programmers strive to include as many design patters as they can, or as much clever code as they can in the vain hope that it will impress other programmers. I follow the KISS principle, which means that people who look my code for the first time have an easier job than when they look as someone else's "clever" code. > However, inevitably there are more people not knowing what they are doing > than people knowing what they are doing: for any given field, there are > many > laymen, fewer intermediates, and very few experts. So the odds are > against > that from the mere majority of a randomly selected set of opinions a > realistic assessment of any subject can be derived. This applies > especially > to source code as software development is a very special field. And the > odds are against that expert in that field would bother complaining about > bad code of others as they - being skilled in writing good code - would > simply write the code to solve the problem themselves, if need be, or just > move on to your competition. I take exception to people like Jerry Stuckle who are quick to brand my programming style as crap when they obviously don't understand how it works. The only thing that they see is that "my way" is different their "their way, the one true way" therefore it *must* be crap. You should also remember that I have released my development framework as open source so that anyone can download it, review it, criticise it, use it or ignore it. Jerry Stuckle, on the other hand, is too afraid to release his own wonderful framework to the world, even though he reckons that it is far superior to mine. Is it because he is too ashamed of his own framework? Is he afraid that someone (other than me, that is) will brand it as utter crap? -- Tony Marston http://www.tonymarston.net http://www.radicore.org Report message to a moderator

What Jerry Stuckle thinks of PHP programmers [message #177836 is a reply to message #177791] Mon, 23 April 2012 13:10   Tony Marston Messages: 57 Registered: November 2010 Karma: 0 Member "Jerry Stuckle" <jstucklex(at)attglobal(dot)net> wrote in message news:jmu1nc$fui$1(at)dont-email(dot)me... <snip> > Yea, right. And what is the experience of those programmers? PHP > programmers as a whole are not known for their intelligence or competence. > In fact, just the opposite is true. All you PHP programmers in this group now know that Jerry Stuckle, that self-proclaimed guru and OO expert, thinks that you are stupid and incompetent. Anyone care to comment? -- Tony Marston http://www.tonymarston.net http://www.radicore.org Report message to a moderator

Re: What Jerry Stuckle thinks of PHP programmers [message #177837 is a reply to message #177836] Mon, 23 April 2012 13:22   Paul Herber Messages: 26 Registered: February 2011 Karma: 0 Junior Member On Mon, 23 Apr 2012 14:10:00 +0100, "Tony Marston" <tony(at)NOSPAM(dot)demon(dot)co(dot)uk> wrote: > > "Jerry Stuckle" <jstucklex(at)attglobal(dot)net> wrote in message > news:jmu1nc$fui$1(at)dont-email(dot)me... > <snip> >> Yea, right. And what is the experience of those programmers? PHP >> programmers as a whole are not known for their intelligence or competence. >> In fact, just the opposite is true. > > All you PHP programmers in this group now know that Jerry Stuckle, that > self-proclaimed guru and OO expert, thinks that you are stupid and > incompetent. > > Anyone care to comment? Those that can, do. Those that can't, croticise. -- Regards, Paul Herber, Sandrila Ltd. http://www.sandrila.co.uk/ Report message to a moderator

Re: What Jerry Stuckle thinks of PHP programmers [message #177838 is a reply to message #177836] Mon, 23 April 2012 13:27   M. Strobel Messages: 386 Registered: December 2011 Karma: 0 Senior Member Am 23.04.2012 15:10, schrieb Tony Marston: > "Jerry Stuckle" <jstucklex(at)attglobal(dot)net> wrote in message > news:jmu1nc$fui$1(at)dont-email(dot)me... > <snip> >> Yea, right. And what is the experience of those programmers? PHP >> programmers as a whole are not known for their intelligence or competence. >> In fact, just the opposite is true. > > All you PHP programmers in this group now know that Jerry Stuckle, that > self-proclaimed guru and OO expert, thinks that you are stupid and > incompetent. > > Anyone care to comment? This is as much true as saying "English native speakers are not known for their intelligence because the rudimentary grammar only foments basic thoughts.". As to PHP, I would put it that way: PHP is the programming language with the highest rate of people doing "how to build a web application without knowing what the web and an application is". Enough? /Str. Report message to a moderator

Re: What Jerry Stuckle thinks of PHP programmers [message #177839 is a reply to message #177836] Mon, 23 April 2012 13:33   Jerry Stuckle Messages: 2598 Registered: September 2010 Karma: 0 Senior Member On 4/23/2012 9:10 AM, Tony Marston wrote: > "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message > news:jmu1nc$fui$1(at)dont-email(dot)me... > <snip> >> Yea, right. And what is the experience of those programmers? PHP >> programmers as a whole are not known for their intelligence or competence. >> In fact, just the opposite is true. > > All you PHP programmers in this group now know that Jerry Stuckle, that > self-proclaimed guru and OO expert, thinks that you are stupid and > incompetent. > > Anyone care to comment? > ROFLMAO! The last refuge of the incompetent. You can't defend your position so you start with the personal attacks. No, I don't think everyone is either stupid or incompetent. But I KNOW you are! -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex(at)attglobal(dot)net ================== Report message to a moderator

Re: Dynamic form generation [message #177840 is a reply to message #177835] Mon, 23 April 2012 13:35   Jerry Stuckle Messages: 2598 Registered: September 2010 Karma: 0 Senior Member On 4/23/2012 9:05 AM, Tony Marston wrote: > "Thomas 'PointedEars' Lahn"<PointedEars(at)web(dot)de> wrote in message > news:2055880(dot)9alNe96dWn(at)PointedEars(dot)de... >> Tony Marston wrote: >> >>> "Jerry Stuckle" wrote: >>>> On 4/19/2012 4:27 AM, Tony Marston wrote: >>>> > "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message >>>> > news:jmmauq$9ke$1(at)dont-email(dot)me... >>> <snip> >>>> >>>> You've been doing it that badly all this time? >>>> >>> >>>> >>> Not according to my fellow developers and paying customers. >>>> >> First rule is that customers don't know anything about good coding. >>>> >> And >>>> >> your fellow developers could easily be as bad as you. No credibility >>>> >> there. >>>> > Delivering code which satisfies the client takes a higher priority than >>>> > writing code which satisfies other programmers. It is not possible to >>>> > write code which satisfies EVERY programmer on the plant as they all >>>> > have different ideas as to what "best practice" actually is. >>>> >>>> It is when you're only doing simple stuff. REAL programmers concentrate >>>> on making their code MAINTAINABLE. >> >> Full ACK. I have never cared if the client would accept or even >> understand >> my code; indeed, if I told my boss that from now on I would be writing >> code >> that way, I would probably be fired on the spot because it does not pay. >> My >> clients so far are not programmers; it is difficult for them to understand >> the basic concepts of programming to begin with. >> >> The client has ordered an application for a price, and they are going to >> get >> the best application that can I can do for that price, with a profit >> margin, >> an error margin, and future maintenance in mind. As a result, my fellow >> developers are going to get the best maintainable code that I can write >> under those conditions (which really is not hard to do once you have >> accustomed yourself to some basic rules and tools of software >> development). >> >>> You have no basis on which to make the statement that my code is >>> unmaintainable. My code has been reviewed by many others, and the vast >>> majority have nothing but compliments. >> >> This is a common fallacy, a self-fulfilling prophecy, that many developers >> try to rationalize (their) bad code quality with. For you cannot know how >> many people have read the code *and* found it so bad that they did not >> care >> to point out its flaws to you. Nor can you know how knowledgable the >> people >> are who have reviewed the code and found it to be good. > > The trouble is that there is no objective method of deciding whether > someone's code is "not crap", "mildly crap" or "total crap". It is always > subjective, with the only universal rule being "If it's different from mine > then it's bo8und to be crap!" > > If you bother looking at my code you will see that it is properly > modularised, properly commented, has meaningful data names and function > names, and achieves its results as simply as possible. Other programmers > strive to include as many design patters as they can, or as much clever code > as they can in the vain hope that it will impress other programmers. I > follow the KISS principle, which means that people who look my code for the > first time have an easier job than when they look as someone else's "clever" > code. > >> However, inevitably there are more people not knowing what they are doing >> than people knowing what they are doing: for any given field, there are >> many >> laymen, fewer intermediates, and very few experts. So the odds are >> against >> that from the mere majority of a randomly selected set of opinions a >> realistic assessment of any subject can be derived. This applies >> especially >> to source code as software development is a very special field. And the >> odds are against that expert in that field would bother complaining about >> bad code of others as they - being skilled in writing good code - would >> simply write the code to solve the problem themselves, if need be, or just >> move on to your competition. > > I take exception to people like Jerry Stuckle who are quick to brand my > programming style as crap when they obviously don't understand how it works. > The only thing that they see is that "my way" is different their "their way, > the one true way" therefore it *must* be crap. > > You should also remember that I have released my development framework as > open source so that anyone can download it, review it, criticise it, use it > or ignore it. Jerry Stuckle, on the other hand, is too afraid to release his > own wonderful framework to the world, even though he reckons that it is far > superior to mine. Is it because he is too ashamed of his own framework? Is > he afraid that someone (other than me, that is) will brand it as utter crap? > Whether I release my framework or not has nothing to do with the fact yours is crap. It's just another attempt by the incompetent to divert the conversation from the real target. We know you're a lousy programmer, Tony. You've proven it time and time again with your statements. You should have quit while you were ahead. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex(at)attglobal(dot)net ================== Report message to a moderator

Re: Dynamic form generation [message #177841 is a reply to message #177835] Mon, 23 April 2012 13:41   Thomas 'PointedEars' Messages: 701 Registered: October 2010 Karma: 0 Senior Member Tony Marston wrote: > "Thomas 'PointedEars' Lahn" <PointedEars(at)web(dot)de> wrote in message > news:2055880(dot)9alNe96dWn(at)PointedEars(dot)de... It is called attribution _line_, not attribution novel. >> Tony Marston wrote: >>> You have no basis on which to make the statement that my code is >>> unmaintainable. My code has been reviewed by many others, and the vast >>> majority have nothing but compliments. >> >> This is a common fallacy, a self-fulfilling prophecy, that many >> developers try to rationalize (their) bad code quality with. For you >> cannot know how many people have read the code *and* found it so bad that >> they did not care to point out its flaws to you. Nor can you know how >> knowledgable the people are who have reviewed the code and found it to be >> good. > > The trouble is that there is no objective method of deciding whether > someone's code is "not crap", "mildly crap" or "total crap". It is always > subjective, with the only universal rule being "If it's different from > mine then it's bo8und to be crap!" Wrong on all accounts. There are theoretically sound, practically proven and therefore well-established rules of thumb – at least – in software development. Ignoring them, or not being aware of them in the first place, leads to objectively bad code. So as I said, it all boils down not only to knowledge but to knowledgability, which comes from and with experience. > You should also remember that I have released my development framework as > open source so that anyone can download it, review it, criticise it, use > it or ignore it. Jerry Stuckle, on the other hand, is too afraid to > release his own wonderful framework to the world, even though he reckons > that it is far superior to mine. Is it because he is too ashamed of his > own framework? Is he afraid that someone (other than me, that is) will > brand it as utter crap? This is another common fallacy: Argumentum ad hominem. PointedEars -- > If you get a bunch of authors […] that state the same "best practices" > in any programming language, then you can bet who is wrong or right... Not with javascript. Nonsense propagates like wildfire in this field. -- Richard Cornford, comp.lang.javascript, 2011-11-14 Report message to a moderator

Re: Dynamic form generation [message #177842 is a reply to message #177829] Mon, 23 April 2012 13:47   Jerry Stuckle Messages: 2598 Registered: September 2010 Karma: 0 Senior Member On 4/22/2012 5:59 PM, Thomas 'PointedEars' Lahn wrote: > Tony Marston wrote: > >> "Jerry Stuckle" wrote: >>> On 4/19/2012 4:27 AM, Tony Marston wrote: >>>> "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message >>>> news:jmmauq$9ke$1(at)dont-email(dot)me... >> <snip> >>>> >>> You've been doing it that badly all this time? >>>> >> >>>> >> Not according to my fellow developers and paying customers. >>>> > First rule is that customers don't know anything about good coding. >>>> > And >>>> > your fellow developers could easily be as bad as you. No credibility >>>> > there. >>>> Delivering code which satisfies the client takes a higher priority than >>>> writing code which satisfies other programmers. It is not possible to >>>> write code which satisfies EVERY programmer on the plant as they all >>>> have different ideas as to what "best practice" actually is. >>> >>> It is when you're only doing simple stuff. REAL programmers concentrate >>> on making their code MAINTAINABLE. > > Full ACK. I have never cared if the client would accept or even understand > my code; indeed, if I told my boss that from now on I would be writing code > that way, I would probably be fired on the spot because it does not pay. My > clients so far are not programmers; it is difficult for them to understand > the basic concepts of programming to begin with. > > The client has ordered an application for a price, and they are going to get > the best application that can I can do for that price, with a profit margin, > an error margin, and future maintenance in mind. As a result, my fellow > developers are going to get the best maintainable code that I can write > under those conditions (which really is not hard to do once you have > accustomed yourself to some basic rules and tools of software development). > >> You have no basis on which to make the statement that my code is >> unmaintainable. My code has been reviewed by many others, and the vast >> majority have nothing but compliments. > > This is a common fallacy, a self-fulfilling prophecy, that many developers > try to rationalize (their) bad code quality with. For you cannot know how > many people have read the code *and* found it so bad that they did not care > to point out its flaws to you. Nor can you know how knowledgable the people > are who have reviewed the code and found it to be good. > Very true. And notice how he's trying to rationalize his poor code now? > However, inevitably there are more people not knowing what they are doing > than people knowing what they are doing: for any given field, there are many > laymen, fewer intermediates, and very few experts. So the odds are against > that from the mere majority of a randomly selected set of opinions a > realistic assessment of any subject can be derived. This applies especially > to source code as software development is a very special field. And the > odds are against that expert in that field would bother complaining about > bad code of others as they – being skilled in writing good code – would > simply write the code to solve the problem themselves, if need be, or just > move on to your competition. > Again, true. Good programmers can agree on what's good code and what's crap code. Just because someone does things a different way doesn't make it "bad". And I've found a direct correlation between the quality of a programmer and his/her willingness to accept criticism. Good programmers can take suggestions on their own code objectively. Poor programmers will defend their crap until the day they die (and longer if they could). > > HTH > > PointedEars, with a fitting random signature -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex(at)attglobal(dot)net ================== Report message to a moderator

Re: Dynamic form generation [message #177843 is a reply to message #177821] Mon, 23 April 2012 14:23   Tony Marston Messages: 57 Registered: November 2010 Karma: 0 Member "Jerry Stuckle" <jstucklex(at)attglobal(dot)net> wrote in message news:jn15dt$gjl$1(at)dont-email(dot)me... > On 4/22/2012 5:27 AM, Tony Marston wrote: >> "Jerry Stuckle" wrote in message news:jmu1nc$fui$1(at)dont-email(dot)me... >>> >>> On 4/21/2012 5:35 AM, Tony Marston wrote: >> <snip> >>> From your description, any good programmer can tell your code is crap. >>> Only those like yourself can't see crap when it's described. >> >> Your definition of crap code seems to be nothing more than "it doesn't >> follow my rules, therefore it must be crap". >> > > My definition of crap code is that "it is bloated, overly complicated and > doesn't follow generally recognized rules". IOW, everything you've shown > your code to be. You call my code bloated because I have included the option to change the password validation rules by changing values on a screen whereas you have to change the code. My method may have taken slightly longer to code, but it also means that changes are easier to implement. You call my code overly complicated because it has a pre-written validation class whereas to have to write code to validate each piece of user input. You say that my code does not follow "generally recognized rules" for no other reason that the rules which it *DOES* follow are not the same as yours. There is no single set of rules that is universally folowed by all programmers, so I follow the rules which I consider to be the most appropriate. >>> Yea, right. And what is the experience of those programmers? PHP >>> programmers as a whole are not known for their intelligence or >>> competence. In fact, just the opposite is true. >> >> So, as this is a newsgroup for PHP programmers you are effectively >> saying that every member of this group is stupid and incompetent? Do you >> know how arrogant that makes you sound? >> > > No, you're putting words in my mouth (again). No I'm not. Your exact words were, and I quote: "PHP programmers as a whole are not known for their intelligence or competence. In fact, just the opposite is true." The phrase "as a whole" tends to encompass the entire PHP programming fraternity, not just a select few. > I'm not saying every member of this group is stupid or incompetent. There > are a number of people here who are quite intelligent and competent, whose > opinions I regard highly. Only those who dare not disagree with anything you say. I am the founder-member of the "I disagree with everything that Jerry Stuckle says" society, so I don't think I'm in that group. Ask me if I care! <snip> >>> What do you think a setter is if it's not a method? And you never have >>> answered how the programmer can change one property without building a >>> whole array. Or get a single property? >> >> The table data already exists in the object as an array, so the >> programmer can examine or change the contents of the array at will. The >> programmer does not have to build the array, it is already there! Why >> can't you understand such a simple concept? > > Yes, you've already said you don't understand one of the basic principles > of OO programming - encapsulation. Encapsulation has nothing to do with information hiding, only implementation hiding. Encapsulation does not require te use of getters and setters. >>> Also, the presence of set/get methods does not preclude the parsing of >>> arrays. I have both, for instance. >>> >>>> > If you understood even the very basics of OO programming (one of which >>>> > is encapsulation), you would know why they are needed. >>>> >>>> Getters and setters are NOT required for encapsulation. Encapsulation >>>> means *implementation* hiding, not *information* hiding. >>>> >>> >>> Yes, and the properties of the class (i.e. variables) are part of the >>> implementation. >> >> Implementation means code, not data. > > That's where you don't understand even basic OO. Implementation means > both code and data. No it does not. On the subject of "Encapsulation is not data hiding" take a look at the following articles: 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/ <snip> >> My framework generates less code than yours because it uses more >> generalised functions. I don't use the copy paste method that you seem >> to favour. > > Your framework generates less code because it's only a half-assed > implementation of even basic OO principles (which you have repeatedly > shown you don't understand). My framework is an implementation of MY understanding of the principles of OOP just as your framework is an implementation of YOUR understanding of the same principles. When you consider the fact that there is no universal agreement on what "Object Oriented Programming" actually means then it is not surprising that two individuals have a totally different understanding. Yet I am not the one who is saying that *MY* understanding is the only opinion worth having. Take a look at these articles to see if you can identify a definition of OOP with is universally accepted: http://c2.com/cgi/wiki?DefinitionsForOo http://c2.com/cgi/wiki?NobodyAgreesOnWhatOoIs http://www.devx.com/opinion/Article/26776 http://www.geocities.com/tablizer/oopbad.htm http://www.geocities.com/tablizer/whypr.htm http://www.geocities.com/tablizer/core1.htm http://www.geocities.com/tablizer/beyondhw.htm http://c2.com/cgi/wiki?ArgumentsAgainstOop http://c2.com/cgi/wiki?ObjectOrientationIsDead http://c2.com/cgi/wiki?ObjectOrientationIsaHoax http://dreamsongs.com/ObjectsHaveFailedNarrative.html http://www.eetimes.com/design/embedded/4216597/Nuts-to-OOP http://c2.com/cgi/wiki?ObjectOrientedForDummies >>> But less code can mean MORE complexity. However, you've never worked >>> on anything non-trivial, so you wouldn't understand. >> >> How can less code be more complex? > > Again, it shows how little you know. Just because there code is smaller > does not mean it's easier to understand. Sometimes it's better to add > code to make it more understandable. I agree that several lines of simple code is easier to understand than one line of complex code, which is why I like to keep my code as simple as possible. Yet you seem to object that it is "too simple". >> <snip> >>>> Take a look at the definition of "ERP" at >>>> http://en.wikipedia.org/wiki/Enterprise_resource_planning and tell me >>>> I'm wrong. I don't have all the modules listed there, but SME's don't >>>> need all those modules. >>> >>> I suggest you read it. An ERP system HAS all the modules. You can't >>> pick and choose. It's an integrated system. >> >> If you read the definition properly you will see that it is a set of >> integrated modules, and not all users require all modules. My ERP system >> does much more than deal with just sales orders. It does what my users >> want, and I care more for their opinion than I do yours. >> > > No, not all users require all modules. However, all ERP systems PROVIDE > all modules. I don't provide modules that have not been requested. I started off by calling it an order processing system, but my first customer insisted that it was much more than. So if a paying customer says that it is an ERP system why should I accept your definition? <snip> >>>> No I don't. You told me yourself that you regularly cut, paste and >>>> modify code. I don't need to do that as the code is defined once in a >>>> reusable function. >>> >>> Exactly. But that's not duplicated code. It's starting with a code >>> template and modifying it to suit my needs. That way you don't need to >>> start from scratch every time. >> >> If you were really competent you would create a version of that code >> template that could be reused as a single function instead of having to >> be copied and modified multiple times. > > And you've just proved that once again you have no idea what you're > talking about. > > A good example - a table with 25 columns. Most are text/numeric, but one > is a 20MB BLOB. > > In one form you want to display all columns in a two column table > (label/value). This one is easy. > > In a second case you want to display 10-16 of those columns in a 4-column > table; 6 columns will be displayed or not based on values in other > columns. 1 (the BLOB) will be displayed if it is not null. > > In the third case, you want to display 5 columns in a 5 column table row > (only). You do not want to retrieve the BLOB column as it is unnecessary > overhead (bloat). > > Let's see your template do that. The number of columns which are retrieved from the database is not controlled by the template. By default all columns are retrieved, but the defaults can be changed whenever needed. >> <snip> >>>> An application can be described as "complex" by looking at the volume >>>> of >>>> business rules which have to be implemented. Using the Radicore >>>> framework I can quickly generate working transactions which already >>>> handle the boring work of moving data between the database and the user >>>> interface, which leaves maximum time to spend on the payload, the >>>> business rules. >>>> >>> >>> You can claim that for your simple database applications. But then you >>> need to do that to satisfy yourself you're working on "complex" >>> applications. Those of us who have worked on truly complex >>> applications know better. >> >> A complex application has complex business rules. A simple application >> has simple business rules. The number of lines of code is irrelevant. If >> I can take an application that uses 3M LOC and achieve the same result >> using half as many LOC would that automatically make my version half as >> complex? I think not. >> > > In your universe, yes. Anyone who has worked on truly complex > applications knows better. But people who only do simple database > applications think a few rules make something complex. I hate to burst > your balloon, but it doesn't. You can keep deluding yourself, though. While I agree that an application which does nothing more than move data between the database and the user interface and does not have any business rules to process is a simple application, it is naive to say that the addition of a large number of complex rules does not turn it into a more complex application. Using my framework all the simple stuff can be done without writing any code, but the complicated stuff, the processing of business rules, requires the programmer to actually add code to the relevant classes. It is the volume of code which the programmer has to add to the framework-generated code which adds to its complexity. Just because you think that a database application cannot possibly be complicated does not make it so. >>> So? You've claimed you've worked on "database applications for >>> decades". That's long before PHP existed. You opened the door. Now >>> you're backpedaling. Typical. >> >> I am not back pedalling. This newsgroup is for people who write database >> applications in PHP, so comments about writing operating systems or >> compilers are irrelevant. > > You are back-pedalling. This is not a database newsgroup, nor is it a > newsgroup for people who write database applications. You brought up > databases, not me. If you bother looking at what the OP wrote he wanted a way to generate an HTML form from a MySQL table structure. That is why I am talking about databases in this post. >> Before I starting writing database applications with PHP I wrote >> database applications with a variety of other languages. That shows that >> my experience of writing database applications has not been confined to >> the PHP language. Tellme how that is back pedalling? >> > > All database applications. Trivial to anyone who's ever worked on truly > complex applications. You brought up an irrelevant subject, and now > you're back-pedaling because I pointed out the fallacy in your argument. > > The fact is all you've EVER done is simple database applications. You > have no idea what a complicated application is. I shan't bother replying to such a pathetic statement. >>>> Applications which are NOT web applications and NOT written in PHP are >>>> irrelevant. >>> >>> Only because all you do are trivial applications in PHP - and you do >>> it poorly, at that. >>> >>>> > Even DOS 1.0 was more complex than anything you've written. >>>> >>>> DOS is not a web application written in PHP, so it's irrelevant. >>> >>> Nope, and neither were the "decades of database applications" you >>> claimed to have written in the very post I'm replying to. >> >> The fact that my experience with other languages meant that I wrote >> database applications for the desktop does not mean that it is totally >> irrelevant when using PHP to write database applications for the web. A >> database application is a database application regardless of whether the >> user interface is the web or the desktop. > > You're bringing up other languages and databases claiming they're > relevant - yet when I mention other languages or applications you claim > they are irrelevant. I am constantly talking about "database applications" because they are relevant to this topic. Non-database applications, such as operating systems and compilers are totally irrelevant. > The truth is you have no leg to stand on so you keep trying to change the > subject and/or claim something is irrelevant. > >>> Nor is database normalization (which you also claimed to know how to >>> do properly - which I also doubt) in that same post. >> >> I shall treat that remark with the contempt it deserves. > > Good. You are contemptful. Of you, yes. >>> But the incompetent need to have it both ways - ignore the rules when >>> it benefits them but claim it's off topic when the rules don't suit >>> them. >> >> You so are saying that I'm incompetent simply because I refuse to follow >> YOUR rules? Do you know how arrogant that makes you? > > No, widely recognized rules by experts. Who says that the rules that you choose to follow were written by experts? What about different sets of rules written by different sets of experts? > But you refuse to follow them. Do you know how arrogant (and stupid) that > makes YOU? > > But once again you refuse to discuss the issue and attack back. You're > only showing your stupidity. No, I'm showing that I don't agree with you. >>> Which means a mixture of conformant and non-conformant passwords in >>> your database. Anyone knowledgeable of security would cringe at such a >>> setup. >> >> Any competent person would tell you that if the password validation >> rules are changed in such a way as to make all exissting passwords >> non-conformant then you get everybody to change their passwords so that >> all NEW passwords conform to the NEW rules. > > Which is why you set the rules ahead of time. But that's not what you > claimed earlier, so you have to once-again back-pedal. Password validation rules MAY be set when the application is first installed, but it is also possible that they MAY be changed some time later. have yiu never heard of customers changing their minds? >>> But it really doesn't matter - it's all bloatware anyway. Only in your opinion. >>> Bloatware. If a customer wants a customized password rule, it's one >>> line of code to change. And it doesn't add all that unnecessary >>> complexity (bloatware) to the script. >> >> So you are admitting that in YOUR implementation if you want to change >> the password validation rules then you have to change your code. In MY >> implementation this can be done by changing a value in the database, and >> you have the audacity and arrogance to call that bloat! > > Sure. It's a one line change to the code. Quick, simple, and > straightforward. But once a system is installed, I've NEVER had a > customer ask for the rules to be changed. That's because we discuss the > pros and cons of different rules up front. > > Plus I don't have to stay on the phone trying to talk the customer through > how to implement his new rules. If you design a simple screen which allows a user to define different password validation rules then your are a poor designer. > Your method is nothing but bloat - which is why you're the only one who's > ever implemented such a stupid concept. It is not boat, it is a valid option. It is also an option that can be modified without having to change a single line of code. >>>> > How many customers have actually demanded the need to change the >>>> > rules? In over 30 years of programming for clients, none of mine have. >>>> >>>> None have had to demand such a facility for the simple reason that it >>>> is >>>> supplied as standard. >>> >>> My point exactly. Bloatware. A feature no one wants or cares about. >> >> My customers care for it, and their opinion means more to me than yours. > > I highly doubt your customers give a damn about it. Maybe they do because > you sold them on how great it is - but then snake oil salesmen are good at > that. I don't sell then anything that doesn't work. I ask then what password validation rules they want rom day 1, then I show then how to set those rules using the screen provided. They then know how to change the rules should they ever want to. <snip> >> Your personal insults are adding nothing to this newsgroup. Please try >> showing a bit more professionalism and maturity. > > No personal insult. Just the truth. No, just your version of what you assume the truth to be. -- Tony Marston http://www.tonymarston.net http://www.radicore.org Report message to a moderator

Re: What Jerry Stuckle thinks of PHP programmers [message #177844 is a reply to message #177839] Mon, 23 April 2012 14:26   Tony Marston Messages: 57 Registered: November 2010 Karma: 0 Member "Jerry Stuckle" <jstucklex(at)attglobal(dot)net> wrote in message news:jn3lmh$s5a$1(at)dont-email(dot)me... > On 4/23/2012 9:10 AM, Tony Marston wrote: >> "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message >> news:jmu1nc$fui$1(at)dont-email(dot)me... >> <snip> >>> Yea, right. And what is the experience of those programmers? PHP >>> programmers as a whole are not known for their intelligence or >>> competence. >>> In fact, just the opposite is true. >> >> All you PHP programmers in this group now know that Jerry Stuckle, that >> self-proclaimed guru and OO expert, thinks that you are stupid and >> incompetent. >> >> Anyone care to comment? >> > > ROFLMAO! The last refuge of the incompetent. You can't defend your > position so you start with the personal attacks. > > No, I don't think everyone is either stupid or incompetent. That isn't what you wrote. > But I KNOW you are! No, you assume that I'm incompetent because I have the balls to disagree with you. Report message to a moderator

Re: Dynamic form generation [message #177845 is a reply to message #177843] Mon, 23 April 2012 16:24   Jerry Stuckle Messages: 2598 Registered: September 2010 Karma: 0 Senior Member On 4/23/2012 10:23 AM, Tony Marston wrote: > "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message > news:jn15dt$gjl$1(at)dont-email(dot)me... >> On 4/22/2012 5:27 AM, Tony Marston wrote: >>> "Jerry Stuckle" wrote in message news:jmu1nc$fui$1(at)dont-email(dot)me... >>>> >>>> On 4/21/2012 5:35 AM, Tony Marston wrote: >>> <snip> >>>> From your description, any good programmer can tell your code is crap. >>>> Only those like yourself can't see crap when it's described. >>> >>> Your definition of crap code seems to be nothing more than "it doesn't >>> follow my rules, therefore it must be crap". >>> >> >> My definition of crap code is that "it is bloated, overly complicated and >> doesn't follow generally recognized rules". IOW, everything you've shown >> your code to be. > > You call my code bloated because I have included the option to change the > password validation rules by changing values on a screen whereas you have to > change the code. My method may have taken slightly longer to code, but it > also means that changes are easier to implement. > I call your code bloated because it contains extra code for an unnecessary function no one else does because it's a "feature" no one needs and no one asks for. A simple one line of code will do what your complicated database access, parsing and checking will do. That one line of code is not only more efficient but can handle many more possibilities. > You call my code overly complicated because it has a pre-written validation > class whereas to have to write code to validate each piece of user input. > Yes, your code is unnecessarily complicated when it has to have an entire class to do what a single line of code will do more clearly and more efficiently. > You say that my code does not follow "generally recognized rules" for no > other reason that the rules which it *DOES* follow are not the same as > yours. There is no single set of rules that is universally folowed by all > programmers, so I follow the rules which I consider to be the most > appropriate. > Once again you need to actually UNDERSTAND OO programming. These are not "my rules" - they are long established "rules" accepted by world-recognized experts on the subject. >>>> Yea, right. And what is the experience of those programmers? PHP >>>> programmers as a whole are not known for their intelligence or >>>> competence. In fact, just the opposite is true. >>> >>> So, as this is a newsgroup for PHP programmers you are effectively >>> saying that every member of this group is stupid and incompetent? Do you >>> know how arrogant that makes you sound? >>> >> >> No, you're putting words in my mouth (again). > > No I'm not. Your exact words were, and I quote: "PHP programmers as a whole > are not known for their intelligence or competence. In fact, just the > opposite is true." The phrase "as a whole" tends to encompass the entire PHP > programming fraternity, not just a select few. > That's right. I didn't say there are no good programmers. But as a whole they are not known for their intelligence or competence. You are a perfect example of that. >> I'm not saying every member of this group is stupid or incompetent. There >> are a number of people here who are quite intelligent and competent, whose >> opinions I regard highly. > > Only those who dare not disagree with anything you say. I am the > founder-member of the "I disagree with everything that Jerry Stuckle says" > society, so I don't think I'm in that group. Ask me if I care! > Nope, there are people I disagree with here but still respect. I, too, have learned from those people. And quite frankly, I really don't give a damn if a penny-ante "programmer" who thinks database applications are complicated agrees with what I say or not. I do care about what good programmers think, however. > <snip> >>>> What do you think a setter is if it's not a method? And you never have >>>> answered how the programmer can change one property without building a >>>> whole array. Or get a single property? >>> >>> The table data already exists in the object as an array, so the >>> programmer can examine or change the contents of the array at will. The >>> programmer does not have to build the array, it is already there! Why >>> can't you understand such a simple concept? >> >> Yes, you've already said you don't understand one of the basic principles >> of OO programming - encapsulation. > > Encapsulation has nothing to do with information hiding, only implementation > hiding. Encapsulation does not require te use of getters and setters. > You obviously do not understand the concept of encapsulation. Once again I suggest you read a good book on it. Booch would be an excellent start. However, I suspect it will be way over your head. It's meant for programmers. >>>> Also, the presence of set/get methods does not preclude the parsing of >>>> arrays. I have both, for instance. >>>> >>>> >> If you understood even the very basics of OO programming (one of which >>>> >> is encapsulation), you would know why they are needed. >>>> > >>>> > Getters and setters are NOT required for encapsulation. Encapsulation >>>> > means *implementation* hiding, not *information* hiding. >>>> > >>>> >>>> Yes, and the properties of the class (i.e. variables) are part of the >>>> implementation. >>> >>> Implementation means code, not data. >> >> That's where you don't understand even basic OO. Implementation means >> both code and data. > > No it does not. On the subject of "Encapsulation is not data hiding" take a > look at the following articles: > Encapsulation has nothing to do with "data hiding". I never said it did. But it DOES have EVERYTHING to do with controlling ACCESS to the data. Once again, I suggest you read a book by a recognized expert in the field, not something on the internet written by someone as incompetent as you. > 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/ > > <snip> >>> My framework generates less code than yours because it uses more >>> generalised functions. I don't use the copy paste method that you seem >>> to favour. >> >> Your framework generates less code because it's only a half-assed >> implementation of even basic OO principles (which you have repeatedly >> shown you don't understand). > > My framework is an implementation of MY understanding of the principles of > OOP just as your framework is an implementation of YOUR understanding of the > same principles. When you consider the fact that there is no universal > agreement on what "Object Oriented Programming" actually means then it is > not surprising that two individuals have a totally different understanding. > Yet I am not the one who is saying that *MY* understanding is the only > opinion worth having. > And your understanding is pure crap. There IS a universal agreement on the basic principles of OOP by recognized experts in the field. > Take a look at these articles to see if you can identify a definition of OOP > with is universally accepted: > > http://c2.com/cgi/wiki?DefinitionsForOo > http://c2.com/cgi/wiki?NobodyAgreesOnWhatOoIs > http://www.devx.com/opinion/Article/26776 > http://www.geocities.com/tablizer/oopbad.htm > http://www.geocities.com/tablizer/whypr.htm > http://www.geocities.com/tablizer/core1.htm > http://www.geocities.com/tablizer/beyondhw.htm > http://c2.com/cgi/wiki?ArgumentsAgainstOop > http://c2.com/cgi/wiki?ObjectOrientationIsDead > http://c2.com/cgi/wiki?ObjectOrientationIsaHoax > http://dreamsongs.com/ObjectsHaveFailedNarrative.html > http://www.eetimes.com/design/embedded/4216597/Nuts-to-OOP > http://c2.com/cgi/wiki?ObjectOrientedForDummies > Once again I urge you to read a book by a recognized expert in the field and not something on the internet written by a person who has no understanding of what OOP really is. Which of those are your articles, BTW? >>>> But less code can mean MORE complexity. However, you've never worked >>>> on anything non-trivial, so you wouldn't understand. >>> >>> How can less code be more complex? >> >> Again, it shows how little you know. Just because there code is smaller >> does not mean it's easier to understand. Sometimes it's better to add >> code to make it more understandable. > > I agree that several lines of simple code is easier to understand than one > line of complex code, which is why I like to keep my code as simple as > possible. Yet you seem to object that it is "too simple". > I never said anything of the sort. >>> <snip> >>>> > Take a look at the definition of "ERP" at >>>> > http://en.wikipedia.org/wiki/Enterprise_resource_planning and tell me >>>> > I'm wrong. I don't have all the modules listed there, but SME's don't >>>> > need all those modules. >>>> >>>> I suggest you read it. An ERP system HAS all the modules. You can't >>>> pick and choose. It's an integrated system. >>> >>> If you read the definition properly you will see that it is a set of >>> integrated modules, and not all users require all modules. My ERP system >>> does much more than deal with just sales orders. It does what my users >>> want, and I care more for their opinion than I do yours. >>> >> >> No, not all users require all modules. However, all ERP systems PROVIDE >> all modules. > > I don't provide modules that have not been requested. > To be called an ERP system it must supply all those modules. Whether a customer wants to use every module is immaterial. Yours is not an ERP system - it is a simple order entry/tracking system. > I started off by calling it an order processing system, but my first > customer insisted that it was much more than. So if a paying customer says > that it is an ERP system why should I accept your definition? > An ERP system is one which handles the ENTERPRISE - that's why it's called ENTERPRISE resource planning. It includes not only order entry/tracking but inventory, accounting, payroll, customer relations and a whole bunch of other things. > <snip> >>>> > No I don't. You told me yourself that you regularly cut, paste and >>>> > modify code. I don't need to do that as the code is defined once in a >>>> > reusable function. >>>> >>>> Exactly. But that's not duplicated code. It's starting with a code >>>> template and modifying it to suit my needs. That way you don't need to >>>> start from scratch every time. >>> >>> If you were really competent you would create a version of that code >>> template that could be reused as a single function instead of having to >>> be copied and modified multiple times. >> >> And you've just proved that once again you have no idea what you're >> talking about. >> >> A good example - a table with 25 columns. Most are text/numeric, but one >> is a 20MB BLOB. >> >> In one form you want to display all columns in a two column table >> (label/value). This one is easy. >> >> In a second case you want to display 10-16 of those columns in a 4-column >> table; 6 columns will be displayed or not based on values in other >> columns. 1 (the BLOB) will be displayed if it is not null. >> >> In the third case, you want to display 5 columns in a 5 column table row >> (only). You do not want to retrieve the BLOB column as it is unnecessary >> overhead (bloat). >> >> Let's see your template do that. > > The number of columns which are retrieved from the database is not > controlled by the template. By default all columns are retrieved, but the > defaults can be changed whenever needed. > So answer the rest of my question. >>> <snip> >>>> > An application can be described as "complex" by looking at the volume >>>> > of >>>> > business rules which have to be implemented. Using the Radicore >>>> > framework I can quickly generate working transactions which already >>>> > handle the boring work of moving data between the database and the user >>>> > interface, which leaves maximum time to spend on the payload, the >>>> > business rules. >>>> > >>>> >>>> You can claim that for your simple database applications. But then you >>>> need to do that to satisfy yourself you're working on "complex" >>>> applications. Those of us who have worked on truly complex >>>> applications know better. >>> >>> A complex application has complex business rules. A simple application >>> has simple business rules. The number of lines of code is irrelevant. If >>> I can take an application that uses 3M LOC and achieve the same result >>> using half as many LOC would that automatically make my version half as >>> complex? I think not. >>> >> >> In your universe, yes. Anyone who has worked on truly complex >> applications knows better. But people who only do simple database >> applications think a few rules make something complex. I hate to burst >> your balloon, but it doesn't. You can keep deluding yourself, though. > > While I agree that an application which does nothing more than move data > between the database and the user interface and does not have any business > rules to process is a simple application, it is naive to say that the > addition of a large number of complex rules does not turn it into a more > complex application. > You have never worked on a complex application, so you don't really understand what "complex" is. Adding a few business rules doesn't make an application "complex". > Using my framework all the simple stuff can be done without writing any > code, but the complicated stuff, the processing of business rules, requires > the programmer to actually add code to the relevant classes. It is the > volume of code which the programmer has to add to the framework-generated > code which adds to its complexity. > More code = more complexity? Nope. You can have a large amount of code (with no bloat) yet still be a simple application. > Just because you think that a database application cannot possibly be > complicated does not make it so. > I never said a database application can't be complex. But nothing you've done ever has been. >>>> So? You've claimed you've worked on "database applications for >>>> decades". That's long before PHP existed. You opened the door. Now >>>> you're backpedaling. Typical. >>> >>> I am not back pedalling. This newsgroup is for people who write database >>> applications in PHP, so comments about writing operating systems or >>> compilers are irrelevant. >> >> You are back-pedalling. This is not a database newsgroup, nor is it a >> newsgroup for people who write database applications. You brought up >> databases, not me. > > If you bother looking at what the OP wrote he wanted a way to generate an > HTML form from a MySQL table structure. That is why I am talking about > databases in this post. > You brought up database applications in general, not the OP. Now you're backpedaling. >>> Before I starting writing database applications with PHP I wrote >>> database applications with a variety of other languages. That shows that >>> my experience of writing database applications has not been confined to >>> the PHP language. Tellme how that is back pedalling? >>> >> >> All database applications. Trivial to anyone who's ever worked on truly >> complex applications. You brought up an irrelevant subject, and now >> you're back-pedaling because I pointed out the fallacy in your argument. >> >> The fact is all you've EVER done is simple database applications. You >> have no idea what a complicated application is. > > I shan't bother replying to such a pathetic statement. > That's because you have no response. It's true. >>>> > Applications which are NOT web applications and NOT written in PHP are >>>> > irrelevant. >>>> >>>> Only because all you do are trivial applications in PHP - and you do >>>> it poorly, at that. >>>> >>>> >> Even DOS 1.0 was more complex than anything you've written. >>>> > >>>> > DOS is not a web application written in PHP, so it's irrelevant. >>>> >>>> Nope, and neither were the "decades of database applications" you >>>> claimed to have written in the very post I'm replying to. >>> >>> The fact that my experience with other languages meant that I wrote >>> database applications for the desktop does not mean that it is totally >>> irrelevant when using PHP to write database applications for the web. A >>> database application is a database application regardless of whether the >>> user interface is the web or the desktop. >> >> You're bringing up other languages and databases claiming they're >> relevant - yet when I mention other languages or applications you claim >> they are irrelevant. > > I am constantly talking about "database applications" because they are > relevant to this topic. Non-database applications, such as operating systems > and compilers are totally irrelevant. > Only to you. But then you're good at backpedaling. The op asked nothing about a "database application". Merely a way to display tables. You're the one who brought up your order entry/tracking system which you so pathetically call an ERP. >> The truth is you have no leg to stand on so you keep trying to change the >> subject and/or claim something is irrelevant. >> >>>> Nor is database normalization (which you also claimed to know how to >>>> do properly - which I also doubt) in that same post. >>> >>> I shall treat that remark with the contempt it deserves. >> >> Good. You are contemptful. > > Of you, yes. > My mistake. I meant you are contemptible. Wrong word. >>>> But the incompetent need to have it both ways - ignore the rules when >>>> it benefits them but claim it's off topic when the rules don't suit >>>> them. >>> >>> You so are saying that I'm incompetent simply because I refuse to follow >>> YOUR rules? Do you know how arrogant that makes you? >> >> No, widely recognized rules by experts. > > Who says that the rules that you choose to follow were written by experts? > What about different sets of rules written by different sets of experts? > There are world-wide recognized experts like Booch in the field who agree on the same rules. Show me any world-wide experts who support your "rules". And someone with a blog on the internet doesn't count. >> But you refuse to follow them. Do you know how arrogant (and stupid) that >> makes YOU? >> >> But once again you refuse to discuss the issue and attack back. You're >> only showing your stupidity. > > No, I'm showing that I don't agree with you. > You're only showing your stupidity. >>>> Which means a mixture of conformant and non-conformant passwords in >>>> your database. Anyone knowledgeable of security would cringe at such a >>>> setup. >>> >>> Any competent person would tell you that if the password validation >>> rules are changed in such a way as to make all exissting passwords >>> non-conformant then you get everybody to change their passwords so that >>> all NEW passwords conform to the NEW rules. >> >> Which is why you set the rules ahead of time. But that's not what you >> claimed earlier, so you have to once-again back-pedal. > > Password validation rules MAY be set when the application is first > installed, but it is also possible that they MAY be changed some time later. > have yiu never heard of customers changing their minds? > Not in this instance, no. >>>> But it really doesn't matter - it's all bloatware anyway. > > Only in your opinion. > And any good programmer. You're the only one who thinks otherwise. Then show us what major pieces of software (especially open source) includes such a function. After all, if it's so important to everyone, then there must be a lot of programs which implement it. >>>> Bloatware. If a customer wants a customized password rule, it's one >>>> line of code to change. And it doesn't add all that unnecessary >>>> complexity (bloatware) to the script. >>> >>> So you are admitting that in YOUR implementation if you want to change >>> the password validation rules then you have to change your code. In MY >>> implementation this can be done by changing a value in the database, and >>> you have the audacity and arrogance to call that bloat! >> >> Sure. It's a one line change to the code. Quick, simple, and >> straightforward. But once a system is installed, I've NEVER had a >> customer ask for the rules to be changed. That's because we discuss the >> pros and cons of different rules up front. >> >> Plus I don't have to stay on the phone trying to talk the customer through >> how to implement his new rules. > > If you design a simple screen which allows a user to define different > password validation rules then your are a poor designer. > If you bloat your code with unnecessary and unwanted functionality, then yes. >> Your method is nothing but bloat - which is why you're the only one who's >> ever implemented such a stupid concept. > > It is not boat, it is a valid option. It is also an option that can be > modified without having to change a single line of code. > Then show us what major pieces of software (especially open source) includes such a function. After all, if it's so important to everyone, then there must be a lot of programs which implement it. >>>> >> How many customers have actually demanded the need to change the >>>> >> rules? In over 30 years of programming for clients, none of mine have. >>>> > >>>> > None have had to demand such a facility for the simple reason that it >>>> > is >>>> > supplied as standard. >>>> >>>> My point exactly. Bloatware. A feature no one wants or cares about. >>> >>> My customers care for it, and their opinion means more to me than yours. >> >> I highly doubt your customers give a damn about it. Maybe they do because >> you sold them on how great it is - but then snake oil salesmen are good at >> that. > > I don't sell then anything that doesn't work. I ask then what password > validation rules they want rom day 1, then I show then how to set those > rules using the screen provided. They then know how to change the rules > should they ever want to. > If you properly explain the advantages and disadvantages of different rules from the outset, then they can decide from the outset what they need. However, once again - do you give them the ability to change their screen layouts? That is something people want regularly. > <snip> >>> Your personal insults are adding nothing to this newsgroup. Please try >>> showing a bit more professionalism and maturity. >> >> No personal insult. Just the truth. > > No, just your version of what you assume the truth to be. > No personal insult. Just the truth. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex(at)attglobal(dot)net ================== Report message to a moderator

Re: What Jerry Stuckle thinks of PHP programmers [message #177846 is a reply to message #177844] Mon, 23 April 2012 16:25   Jerry Stuckle Messages: 2598 Registered: September 2010 Karma: 0 Senior Member On 4/23/2012 10:26 AM, Tony Marston wrote: > "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message > news:jn3lmh$s5a$1(at)dont-email(dot)me... >> On 4/23/2012 9:10 AM, Tony Marston wrote: >>> "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message >>> news:jmu1nc$fui$1(at)dont-email(dot)me... >>> <snip> >>>> Yea, right. And what is the experience of those programmers? PHP >>>> programmers as a whole are not known for their intelligence or >>>> competence. >>>> In fact, just the opposite is true. >>> >>> All you PHP programmers in this group now know that Jerry Stuckle, that >>> self-proclaimed guru and OO expert, thinks that you are stupid and >>> incompetent. >>> >>> Anyone care to comment? >>> >> >> ROFLMAO! The last refuge of the incompetent. You can't defend your >> position so you start with the personal attacks. >> >> No, I don't think everyone is either stupid or incompetent. > > That isn't what you wrote. > >> But I KNOW you are! > > No, you assume that I'm incompetent because I have the balls to disagree > with you. > > No, you've shown your incompetence by your comments in this very newsgroup. There are people whom I greatly respect who disagree with me also. But those are competent programmers. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex(at)attglobal(dot)net ================== Report message to a moderator

Re: What Jerry Stuckle thinks of PHP programmers [message #177847 is a reply to message #177846] Mon, 23 April 2012 17:45   Luuk Messages: 329 Registered: September 2010 Karma: 0 Senior Member On 23-04-2012 18:25, Jerry Stuckle wrote: > > No, you've shown your incompetence by your comments in this very > newsgroup. There are people whom I greatly respect who disagree with me > also. But those are competent programmers. > yaaaawn...... Report message to a moderator

Re: What Jerry Stuckle thinks of PHP programmers [message #177848 is a reply to message #177836] Mon, 23 April 2012 19:31   The Natural Philosoph Messages: 993 Registered: September 2010 Karma: 0 Senior Member Tony Marston wrote: > "Jerry Stuckle" <jstucklex(at)attglobal(dot)net> wrote in message > news:jmu1nc$fui$1(at)dont-email(dot)me... > <snip> >> Yea, right. And what is the experience of those programmers? PHP >> programmers as a whole are not known for their intelligence or competence. >> In fact, just the opposite is true. > > All you PHP programmers in this group now know that Jerry Stuckle, that > self-proclaimed guru and OO expert, thinks that you are stupid and > incompetent. > > Anyone care to comment? > I would say that Jerry Stuckle has been looking into the mirror again. After all he does claim to be a PHP programmer although I have never seen him post a line of his own code. And as far as I recall his dormant company used to be a training company but now shows zero turnover at all. Which suggests why he is so twitter and bisted and has time to troll so many usenet groups. -- 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. Report message to a moderator

Re: What Jerry Stuckle thinks of PHP programmers [message #177849 is a reply to message #177847] Mon, 23 April 2012 19:35   The Natural Philosoph Messages: 993 Registered: September 2010 Karma: 0 Senior Member Luuk wrote: > On 23-04-2012 18:25, Jerry Stuckle wrote: >> No, you've shown your incompetence by your comments in this very >> newsgroup. There are people whom I greatly respect who disagree with me >> also. But those are competent programmers. >> > > > yaaaawn...... > > I've never seem jerry offer any respect to someone who disagreed with him, even when they were 100% demonstrably correct. > But you are right Luuk. Its time to watch TV or play a mindless computer game where trolls are things you routinely slaughter for minor acquisitions of virtual treasure... I've slaughtered jerry only to find there was nothing worth looting whatsoever apart from a bag of piss and wind. And that is commoner than bullshit when all is said and done. -- 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. Report message to a moderator

Re: Dynamic form generation [message #177850 is a reply to message #177843] Mon, 23 April 2012 19:37   The Natural Philosoph Messages: 993 Registered: September 2010 Karma: 0 Senior Member Tony Marston wrote: > "Jerry Stuckle" <jstucklex(at)attglobal(dot)net> wrote in message Tony: I just deleted about 300 lines of you trying to tell Jerry something he doesn't want to hear. Please. kill file it and get a life. Unless you enjoy argument for its own sake, like Jerry. -- 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. Report message to a moderator

Re: Dynamic form generation [message #177851 is a reply to message #177835] Mon, 23 April 2012 19:39   The Natural Philosoph Messages: 993 Registered: September 2010 Karma: 0 Senior Member Tony Marston wrote: > I take exception to people like Jerry Stuckle who are quick to brand my > programming style as crap when they obviously don't understand how it works. > The only thing that they see is that "my way" is different their "their way, > the one true way" therefore it *must* be crap. In a nutshell, that is jerry. 1/. What took you so long? 2/. Why haven't you plonked it? -- 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. Report message to a moderator

Re: What Jerry Stuckle thinks of PHP programmers [message #177858 is a reply to message #177836] Tue, 24 April 2012 02:32   Ross McKay Messages: 14 Registered: January 2011 Karma: 0 Junior Member On Mon, 23 Apr 2012 14:10:00 +0100, Tony Marston wrote: > "Jerry Stuckle" <jstucklex(at)attglobal(dot)net> wrote in message > news:jmu1nc$fui$1(at)dont-email(dot)me... > <snip> >> Yea, right. And what is the experience of those programmers? PHP >> programmers as a whole are not known for their intelligence or competence. >> In fact, just the opposite is true. > > All you PHP programmers in this group now know that Jerry Stuckle, that > self-proclaimed guru and OO expert, thinks that you are stupid and > incompetent. > > Anyone care to comment? For a change, I think he might be close to correct. Having dealt with a large quantity of other people's code, especially some very large WordPress plugins, I have to say that PHP code quality that I've seen in the wild is often very poor. At least a compiled language enforces *some* quality corrections on one's code, whereas PHP (and also JavaScript) seem to be designed to help total newbie programmers get the job done. This is good, but it also leads to piles of excremental code that "work" much in the same way that Microsoft Access allows newbie database wranglers to build databases that "work". Sure, you get bad code in any language, but I sincerely believe that I've seen more bad PHP code than other bad code (even bad classic ASP code). Which is not to say that said code didn't "work", for limited values of "work". The entry level for writing working PHP code is very low, so you get all comers. Most will learn over time and improve, as we all continue to do (or most of us anyway, I hope!) Conversely, I've seen some truly marvellous PHP code. -- Ross McKay, Toronto, NSW Australia "There is more to life than simply increasing its speed." - Gandhi Report message to a moderator

Re: Dynamic form generation [message #177861 is a reply to message #177834] Tue, 24 April 2012 09:10   Thomas 'PointedEars' Messages: 701 Registered: October 2010 Karma: 0 Senior Member Tony Marston wrote: > "Thomas 'PointedEars' Lahn" <PointedEars(at)web(dot)de> wrote in message > news:16487873(dot)YAfrjsNhc7(at)PointedEars(dot)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 Report message to a moderator

Re: Dynamic form generation [message #177863 is a reply to message #177861] Tue, 24 April 2012 16:11   Tony Marston Messages: 57 Registered: November 2010 Karma: 0 Member "Thomas 'PointedEars' Lahn" <PointedEars(at)web(dot)de> wrote in message news:1400277(dot)AFRqVoOGUt(at)PointedEars(dot)de... > Tony Marston wrote: <snip> >>> This means that you perform no type conversion or checking, or range >>> checking in the application, yes? >> >> Incorrect. > > It is a yes-or-no question, therefore it cannot be incorrect. I answered "incorrect" to the statement "you perform no type conversion or checking, or range checking in the application". >> 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 Report message to a moderator

Re: Dynamic form generation [message #177864 is a reply to message #177863] Tue, 24 April 2012 16:54   Thomas 'PointedEars' Messages: 701 Registered: October 2010 Karma: 0 Senior Member Tony Marston wrote: > > "Thomas 'PointedEars' Lahn" <PointedEars(at)web(dot)de> wrote in message > news:1400277(dot)AFRqVoOGUt(at)PointedEars(dot)de... ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> Tony Marston wrote: > > <snip> >>>> This means that you perform no type conversion or checking, or range >>>> checking in the application, yes? >>> >>> Incorrect. >> >> It is a yes-or-no question, therefore it cannot be incorrect. > > I answered "incorrect" to the statement "you perform no type conversion or > checking, or range checking in the application". Again, it was _not_ a statement, it was a question. >>> If my ADD controller contains the line $result => $dbobject- >>> insertRecord($_POST); then the entire $_POST array is passed to >>> that object. I do not have to break it down into its compnent parts and >>> inject each component individually. The contents of the array is then >>> validated by the framework to ensure that all columns maked as NOT NULL >>> are not empty, all date fields are dates, all numeric fields are numbers >>> and within range, et cetera. [.] >>> Just because I say that the programmer does not have to write code does >>> not mean that the data is never validated. It always is, but as an >>> automatic function of thre framework. >> >> I see. How do you account for data types in the array that are not >> provided ^^^^^^^^^^^^ >> by the respective database engine Will you *please* fix your quoting style? > The array values are always strings. No, the array _element_ of $_POST and $_GET arrays may easily be an array itself with any non-trivial HTML form. PHP supports HTML form controls with the name suffix `[]', where the value of all controls with the same prefix are arranged in an array. > What comes in via the $_GET or $_POST array is always a string, Wrong. > and what I write into the SQL query is always a string. So much the worse. What about code injection and Prepared Statements? > I can switch my database between MySQL, PostgreSQL, Oracle and SQL Server, > and I tend to design my databases using common data types, so I never have > any problems. I seriously doubt that. > <snip> >>> Just because a lot of OOP tutorials show the use of getters and setters >>> does not mean that I *HAVE* to use them. >> >> No, it means that this is strong indication that there are good reasons >> that >> you SHOULD use them (I leave it to you to find out what those reasons >> are; >> this newsgroup is not OOP 101). Especially as PHP (by contrast to Java, >> for >> example) provides convenient transparent access to non-public properties >> with the __set() and __get() magic methods. > > I repeat, there is no rule that says I must/should use getters and setters > for each of my column values, No, there is just extensive research on OOP, common sense, and experience. > so I don't have to. You also don't have to look to the left and right before crossing a busy street. > By passing in a collection of values as an array instead of its individual > components Same fallacy as before. > one at a time I use less code, and less code to achieve a given > result is supposed to be better. No; less code, faster code or less memory-consuming code is not necessarily better code. >>> I don't see why I should pass in a collection of values using multiple >>> setters when I can achieve the same result by passing in the entire >>> collection as a single array variable. >> >> That is a false dichotomy, as I have explained already. > > You reason is no more than "that is what I have been taught, and you are > not allowed to be different". I choose to be different when different is > better. You are mistaken. Look up "false dichotomy", please. > <snip> >>> My database table objects do not have a separate property for each >>> column within that table, so I don't need getters and setters for each >>> column. >> >> But in MVC, models are not data access objects. > > Neither are they in mine. My data acess object is totally separate from > each table object. Your model objects surely appear to have data access methods, most notably insertRecord(). >>>> >> It also generates the code necessary to validate a field. Some stock >>>> >> fields (like "must be integer") have predefined validation functions. >>>> > My framework does not generate any code to perform basic field >>>> > validation as that is performed by a validation class which I wrote >>>> > years ago. >>>> So that validation class has become part of the framework, has it not? >>> >>> Absolutely correct. >> >> (See above.) >> >> So your argument that the validation class is not part of your framework >> is ^^^^^ >> effectively void. > > I never said that my validation class was not part of my framework. You implied it. > I said that I never had to write any code to validate user data as that is > automatically taken care of by te ramework. I think the point was not that code is generated, but that validation takes place. > <snip> >>>> It also means that your HTTP POST requests are inherently bound to the >>>> structure of the database (table), does it not? >>> >>> Why? The $_POST array is simply an associative array, and the only thing >>> it is "bound" to is the HTML form which generated it. If the $_POST >>> array contains any field names which do not exist in the database table >>> then those fields simply will not appear in the sql query which is >>> generated. >> >> AIUI, the keys of the elements of the $_POST array must match that of the >> field names in the database as far as they exist in the database then. >> Therefore, if you have to change the application logic or if you have to >> change the database, you have to change the other part. > > Not all database changes require a programmer to change any code. In a lot > of cases it is a simple matter of re-importing into the data dictionary > and then re-exporting to regenerate the table structure files. Still with that approach you have to change the *business* logic (not database access logic) of the application if you change the database and vice-versa. There is no layer in-between that allows for transparent access and, therefore, easy adjustment. > The fact that the field names on the screen are the same as column names > in the database is irrelevant. You are very much mistaken. > Only a masochist would use different names Or a person considering the limitations of browsers and databases, and the exploits that can follow from exposing server-side structures as-are to the client. > because it would then require a data mapper to translate the names. Which is the sensible thing to do, believe it or not. > Coding changes are usually only required when a business rule changes. You are still winding around the issue. >> Moreover, if at some point you do _not_ want to update a field, but the >> $_POST array contains an element with a key matching a field, that field >> will be updated anyway. > > An incorrect assumption. The UPDATE query is edited (by standard code, > naturally) to include only those columns which have actually changed. You are missing the point. If someone passes in a request array a value with a key that matches an *existing* database field that you usually would not want to have updated, the field would be updated anyway because your insertRecord() method cannot tell that this field should not be updated at this time. Whereas "updated" refers to all updates of or requests from the table, not only UPDATE queries. >> An attacker could use that vulnerability to >> manipulate your database through the application in ways that you cannot >> conceive yet. > > Prove it. An example of my framework is available at > http://www.radicore.org/demo.php. Break it if you can. You should know that "Show me where it breaks" is a typical luser's reply. I have told you where and basically how, given your description, the approach presents a vulnerability. It would be up to you to verify that. >> This approach also does not appear to account for the possibility that >> with >> one request several tables need to be updated. > > Easy peasy. Let's suppose a particular INSERT requires data to be added to > TableA, TableB and TableC. I would start by sending all the data to the > primary table with the statement: > > $result - $tableAobject->insertRecord($_POST). > > After validation it would create the relevant INSERT query for tableA. It > would automatically filter out any field names which do not exit in that > table. > > In the _postInsertRecord method of TableA's class I would have the > following: > > $result = $tableBobject->insertRecord($data); > $result = $tableCobject->insertRecord($data); > > Where $data at this point is the validated version of the original $_POST > array. ISTM you are still thinking too linear. There is no inherent connetion between the two result values. But I was talking about table *relations*. If the user of the model has to rebuild the relations of a model with another models in their code, then that is surely a poorly designed model in any sense of the "M" in MVC, one that does not scale well on top of that. > This method is ridiculously simple yet ridiculously effective, but I > expect that you'll find a way to tell me that it's wrong. [x] done >> Apropos, how you do implement queries across several tables (JOINs) with >> your framework? > > SELECT statements can have the necessary JOINS added in automatically by > the framework using information which was exported from the data > dictionary. It is also possible to override the default query with > whatever your heart desires. OK. How does that look like? -- PointedEars Report message to a moderator

Re: Dynamic form generation [message #177865 is a reply to message #177818] Tue, 24 April 2012 17:21   Tony Marston Messages: 57 Registered: November 2010 Karma: 0 Member "Jerry Stuckle" <jstucklex(at)attglobal(dot)net> wrote in message news:jn13eu$4ll$1(at)dont-email(dot)me... <snip> >>> And you completely miss the question. How do you change a single >>> property in the object without building the array? >> >> BECAUSE THE ARRAY IS ALREADY INSIDE THE OBJECT, YOU IDIOT!!! I don't >> need code inside the table object to build the array as it is supplied >> as an array, either from the $_GET or $_POST array, or an array of rows >> and columns from the database. > > So, IOW, you can't change a single property from the program. You can't, > for instance, set just the ship date in an order. You can only set the > entire object. How stupid. If I have a transaction where the only value that can be changed in the ship date for an order, then the $POST array will contain "ship_date = whatever". My update controller has the line $dbobject->updateRecord($_POST) where $dbobject is an instance of the order class. The order class, as with every other table class in my system, will perform an update operation using the contents of its input array however many fields it contains. It does not matter whether it contains 1 field or 100 fields, it's all the same. Why can't you understand such a simple concept? >>> From the number of times you have ducked the question, my only >>> assumption can be the program can't change a single property in the >>> object. >> >> Changing a property inside an object is as simple as changing a value in >> an array. > > Oh, so all of your variables are public? How stupid is that? It violates > the first rule of OO programing - encapsulation. Encapsulation does not mean data hiding. > So you're saying I can say > > $object->ship_date = 9999-12-31. Or even > > $object->ship_date = "This is completely stupid but OK according to Tony". I've already told you that I don't have a separate class property for each column in the table. All the table data is held in a single array, so instead of $object->ship_date = '9999-12-31' you would have to use $object->fieldarray['ship_date'] = '9999-12-31'; Such duff data would never make it to the database anyway as it would fail the validation. > Proper OO programming doesn't allow such crap programming. OO does not prevent programmers from writing crap code. It just allows then to generate a different class of crap. <snip> >>> Your way is plain bloat. >> >> Validating that date fields contain dates, numeric fields contain >> numbers and NOT NULL fields are not empty is never something that a user >> can change because it is standard validation, which is why I put all the >> necessary code in a standard validation class years ago. This means that >> in my framework, unlike yours, I never have to write a line of code to >> perform standard validation. > > Only you would think instantiating an object to ensure a value is really > an integer is better than just calling intval(). Bloat, bloat, bloat. I don't instantiate my validaton object for each individual value, I do it just once to validate the whole array of values. >> If a customer requires an additional rule, such as comparing dates on >> one database table with dates on another, then that is non-standard, is >> not covered by the standard validation class and will therefore require >> a programmer to write some code. >> > > With proper OO principles, the object requiring the rule implements the > rule. But the rule has to be coded within the relevant class. >>> More bloat. No, the intval() function call is inherent to the set() >>> function. >> >> I don't have separate setter and getter functions for each column on a >> table. > > Yea, you allow people to set the variables directly (see above). A direct > violation of the most basic OO principle. I don't have separate getter and setter functions for each entry within the array because the data goes in and out as an array. > Having instantiate the object just to ensure a value is an integer when a > simple call to intval() does the same thing is bloat. > > But then you don't validate things set by the program, because you don't > understand encapsulation. I understand encapsulation very well. The validation rules for the person entity are defined within the person class. When I call the validation object I give it two variables - the array of field values and the array of field rules. The validation object will then verify that each field's value conforms to its rules. >>>> Again you are writing code to do something which my framework does >>>> automatically. And you have the nerve to say that my methods are crap! >>> >>> Nope, my framework automatically handles simple rules based on >>> datatypes. If I need more complex rules, they are easy to enter. >> >> That's exactly how my framework works, but I achieve the same result by >> different means. You seem to think that simply because my methods are >> different that they are automatically wrong. What an arrogant person you >> are! >> > > So tell me - how do you prevent > > $object->ship_date = "This is stupid!"; Because the validation rule for the field called "ship_date" is that it be a date, so the value "This is stupid!" will be rejected. <snip> >>> Nope, you brought up the subject of allowing the customer to change >>> the rules. >> >> Only the password validation rules. > > And I asked why, when you implemented a function no one else in the world > has found a need for, haven't you implemented a function that millions of > people want and need? That question is orthogonal to the subject of this thread, so I shall ignore it. <snip> >>> >>> Yes? So how do you display the same data in different formats then? >> >> I have a different transaction based on a different transaction pattern, >> one to output HTML, another for PDF and another for CSV. > > I asked how do you display the same data in different formats, not > different media. But you can't do that, can you? Read on, MacDuff. >> If it is necessary to have the HTML output displayed differently under >> different circumstance then I would still have a separate transaction >> with each having its own screen structure file. > > Gee, sounds like you have to create a lot of code to just do something as > simple as displaying the same information in a slightly different format. > My way is easy and can be done very quickly. You're missing the point again. If you want to have the data from the same table displayed in one of several different formats then you need a mechanism for the user to choose which format he wants. I do that my having a separate transaction, with its own menu button, for each format. The only different coding that would be required would be in a small screen structure file, and that would be also be quick and easy. > I never said anything of the type. I said I had a function which took the > input from $_GET or _$POST and processed it. I also said I had getter and > setter functions. Youn said that you had a function which took the $_GET or $_POST array, split it into its component parts so that you could use a setter on each part. The fact that the function accepts an array as its input is irrelevant as you are still spliting the array into its component parts. > The lack of getters and setters means your variables must be public, which > violates the first principle of OO programming - encapsulation. Encapsulation does not mean data hiding. >>> That's right. That's an implicit part of OO (encapsulation). >> >> Using getters and setters has nothing to do with encapsulation. > > Only in the alternate universe of Tony Marston. You really should try > reading a book on OO by a recognized expert in the field. Booch would be > a good start. There are many others who also think that encapsulation does NOT mean data hiding. take a look at the following: http://www.javaworld.com/javaworld/jw-05-2001/jw-0518-encapsulation.html http://www.itmweb.com/essay550.htm http://homepage.mac.com/keithray/blog/2006/02/22/ - the 2nd paragraph titled "Encapsulation Wasn't Meant To Mean Data Hiding" written by martin Fowler. >> <snip> >>> But unlike you, I can get or set a single property, also, as needed. >>> Something I do all the time. >> >> In my implementation of MVC neither the Controller nor the View *EVER* >> needs to obtain a single column value by its name. They only ever deal >> with an array of rows and columns, and they don't care what the array >> contains. That is why my implementation has a small number of >> Controllers and Views which are reusable. > > Which doesn't answer my question. But then you've already answered it. > You don't even understand the basic OO concept of encapsulation. The fact that my controllers and views do not use getters and setters on named items has nothing to do with encapsulation. >>> Once again you show you have no knowledge of OO. Polymorphism cannot >>> exist without inheritance - which requires a parent/child hierarchy. >> >> Yes it can. Polymorphism simply requires that the same interface exist >> in more than one class. That may come from inheritance, or it may not. >> It *IS* possible to define the same interface more than once without >> inheritance. > > It's not surprising you claim this. It is not a claim it is a fact that it is possible to have the same interface in more than one object WITHOUT inheritance. > When you don't even understand encapsulation, no one should expect you to > understand a more advanced concept like polymorphism. My understanding of the concepts of OO are documented in http://www.tonymarston.net/php-mysql/what-is-oop.html#what.is.an.oo.languag e >>> I've used them much longer than you've even known they existed. When >>> you have a class derived from the abstract class, there is a >>> parent/child relationship. But there is no such relationship between >>> two classes derived from the same one. >> >> Each one of the 200 concrete table classes in my application is derived >> from the same abstract table class, so each one of those 200 classes is >> a sibling of the other, and "sibling" implies a relationship. > > So there is a sibling relationship? Once again you prove how you don't > understand the concept of polymorphism. Each sibling has the same method names inherited from the same parent class, which means that I can use the same method name on any sibling. Using the same name method name on a number of different objects qualifies as polymorhism - same interface, different implementation. <snip> >> But you don't like your methods to be criticised, do you? You seem to >> think that anybody whose methods are different from yours is >> automatically an incompetent moron. > > Nothing of the sort. But then it's pretty common of you - you can't > defend your code so you attack the messenger. What do you mean I can't defend my code? I have done nothing BUT defend my code for almost all of this thread. The OP asked if it were possible to create an HTML form to maintain the contents of a database table without having to write lots of code. I said that this could be done with the open source Radicore framework as this was specifically designed to deal with database tables, and can generate a series of default HTML forms without the need to write any code whatsover. Coding is only required when you want to change the defaults. You have done nothing but state that my framework works differently from your framework, therefore my framework must be crap. My framework does everything that I claim it does and is available as open source for anyone to download and evaluate. Your framework is not available as open source, so nobody can judge whether it works or not, let alone is better than anyone else's. You have not provided any code samples at all to back up your claims, so I can only say that without any proof to the contrary that all your claims are totally unfounded and without substance. >>> Nope. I didn't say my way was the only way. I said my way works, does >>> not contain bloatware and follows recognized OO practices. All you can >>> claim is yours works. >> >> My way works just as your way works. As for "recognised OO practices" >> there is no single set of practices which is recognised by every single >> programmer on the planet. Different groups recognise different >> practices, and I just happen to belong to a different group than you do. > > No, your way doesn't work. Yes it does, and has done for years. You can visit the demo radicore application at http://www.radicore.org/demo.php and try it out for yourself. Where is the link to YOUR framework? -- Tony Marston http://www.tonymarston.net http://www.radicore.org Report message to a moderator

Re: What Jerry Stuckle thinks of PHP programmers [message #177866 is a reply to message #177844] Tue, 24 April 2012 17:45   Thomas 'PointedEars' Messages: 701 Registered: October 2010 Karma: 0 Senior Member Tony Marston wrote: > "Jerry Stuckle" <jstucklex(at)attglobal(dot)net> wrote in message > news:jn3lmh$s5a$1(at)dont-email(dot)me... >> On 4/23/2012 9:10 AM, Tony Marston wrote: >> No, I don't think everyone is either stupid or incompetent. > > That isn't what you wrote. > >> But I KNOW you are! > > No, you assume that I'm incompetent because I have the balls to disagree > with you. I am afraid that in your case it is your bold and wrong statements about (PHP) programming that show you as being inexperienced at least. PointedEars -- > If you get a bunch of authors […] that state the same "best practices" > in any programming language, then you can bet who is wrong or right... Not with javascript. Nonsense propagates like wildfire in this field. -- Richard Cornford, comp.lang.javascript, 2011-11-14 Report message to a moderator

Re: Dynamic form generation [message #177867 is a reply to message #177864] Tue, 24 April 2012 17:55   Tony Marston Messages: 57 Registered: November 2010 Karma: 0 Member "Thomas 'PointedEars' Lahn" <PointedEars(at)web(dot)de> wrote in message news:6244670(dot)rdf3491b2I(at)PointedEars(dot)de... <snip> >>>> > This means that you perform no type conversion or checking, or range >>>> > checking in the application, yes? >>>> >>>> Incorrect. >>> >>> It is a yes-or-no question, therefore it cannot be incorrect. >> >> I answered "incorrect" to the statement "you perform no type conversion >> or >> checking, or range checking in the application". > > Again, it was _not_ a statement, it was a question. It was a statement with a question at the end, as in "you perform no type conversion or checking, or range checking in the application, yes?" The question part was "yes?", meaning "is this statement true". I answered "incorrect", meaning "the statement is not true". Did you not study Engish grammar at school? >>>> If my ADD controller contains the line $result => $dbobject- >>>> insertRecord($_POST); then the entire $_POST array is passed to >>>> that object. I do not have to break it down into its compnent parts and >>>> inject each component individually. The contents of the array is then >>>> validated by the framework to ensure that all columns maked as NOT NULL >>>> are not empty, all date fields are dates, all numeric fields are >>>> numbers >>>> and within range, et cetera. [.] >>>> Just because I say that the programmer does not have to write code does >>>> not mean that the data is never validated. It always is, but as an >>>> automatic function of thre framework. >>> >>> I see. How do you account for data types in the array that are not >>> provided > ^^^^^^^^^^^^ >>> by the respective database engine > > Will you *please* fix your quoting style? No. >> The array values are always strings. > > No, the array _element_ of $_POST and $_GET arrays may easily be an array > itself with any non-trivial HTML form. PHP supports HTML form controls > with > the name suffix `[]', where the value of all controls with the same prefix > are arranged in an array. So, an array element may be a string or an array of strings. The resulting values are still strings eventually. >> What comes in via the $_GET or $_POST array is always a string, > > Wrong. So an array element may be a string or an array of strings. What's the big deal? The lowest-level values are still strings! >> and what I write into the SQL query is always a string. > > So much the worse. What about code injection and Prepared Statements? I don't use prepared statements, and I don't have to use prepared statements to avoid code injection. >> I can switch my database between MySQL, PostgreSQL, Oracle and SQL >> Server, >> and I tend to design my databases using common data types, so I never >> have >> any problems. > > I seriously doubt that. You can doubt it as much as you like. But I have copies of my data in a MySQL database, a PostgreSQL database, an Oracle database, and a SQL Server database, and the same application can be switched from one to the other with a single change to a config file. You can download my radicore framework and try it out for yourself if you don't believe me. <snip> >>>> Just because a lot of OOP tutorials show the use of getters and setters >>>> does not mean that I *HAVE* to use them. >>> >>> No, it means that this is strong indication that there are good reasons >>> that >>> you SHOULD use them (I leave it to you to find out what those reasons >>> are; >>> this newsgroup is not OOP 101). Especially as PHP (by contrast to Java, >>> for >>> example) provides convenient transparent access to non-public properties >>> with the __set() and __get() magic methods. >> >> I repeat, there is no rule that says I must/should use getters and >> setters >> for each of my column values, > > No, there is just extensive research on OOP, common sense, and experience. Just because a lot of prgrammers do something does not make it the "right" way. >> so I don't have to. > > You also don't have to look to the left and right before crossing a busy > street. Stop changing the subject. >> By passing in a collection of values as an array instead of its >> individual >> components >> one at a time I use less code, and less code to achieve a given >> result is supposed to be better. > > No; less code, faster code or less memory-consuming code is not > necessarily > better code. Where is your proof that passing in a collection of data as a single array instead of passing in then component parts one at a time is not better? >>>> I don't see why I should pass in a collection of values using multiple >>>> setters when I can achieve the same result by passing in the entire >>>> collection as a single array variable. >>> >>> That is a false dichotomy, as I have explained already. >> >> You reason is no more than "that is what I have been taught, and you are >> not allowed to be different". I choose to be different when different is >> better. > > You are mistaken. Look up "false dichotomy", please. According to http://en.wikipedia.org/wiki/False_dilemma it means choosing between only two possibilities when there may be more than two. I never said that there were only two choices, only that my choice is obviously different from yours. >> <snip> >>>> My database table objects do not have a separate property for each >>>> column within that table, so I don't need getters and setters for each >>>> column. >>> >>> But in MVC, models are not data access objects. >> >> Neither are they in mine. My data acess object is totally separate from >> each table object. > > Your model objects surely appear to have data access methods, most notably > insertRecord(). But the insertRecord() method in my table object does not update the database. To do that it calls the insertRecord() method on a separate data access object. It is the DAO which actually updates the database, not the table object. >>>> >>> It also generates the code necessary to validate a field. Some >>>> >>> stock >>>> >>> fields (like "must be integer") have predefined validation >>>> >>> functions. >>>> >> My framework does not generate any code to perform basic field >>>> >> validation as that is performed by a validation class which I wrote >>>> >> years ago. >>>> > So that validation class has become part of the framework, has it not? >>>> >>>> Absolutely correct. >>> >>> (See above.) >>> >>> So your argument that the validation class is not part of your framework >>> is effectively void. >> >> I never said that my validation class was not part of my framework. > > You implied it. No I didn't. You implied it. >> I said that I never had to write any code to validate user data as that >> is >> automatically taken care of by the framework. > > I think the point was not that code is generated, but that validation > takes > place. Correct. Data validation takes place without the programmer having to write any code. <snip> >>>> > It also means that your HTTP POST requests are inherently bound to the >>>> > structure of the database (table), does it not? >>>> >>>> Why? The $_POST array is simply an associative array, and the only >>>> thing >>>> it is "bound" to is the HTML form which generated it. If the $_POST >>>> array contains any field names which do not exist in the database table >>>> then those fields simply will not appear in the sql query which is >>>> generated. >>> >>> AIUI, the keys of the elements of the $_POST array must match that of >>> the >>> field names in the database as far as they exist in the database then. >>> Therefore, if you have to change the application logic or if you have to >>> change the database, you have to change the other part. >> >> Not all database changes require a programmer to change any code. In a >> lot >> of cases it is a simple matter of re-importing into the data dictionary >> and then re-exporting to regenerate the table structure files. > > Still with that approach you have to change the *business* logic (not > database access logic) of the application if you change the database and > vice-versa. There is no layer in-between that allows for transparent > access > and, therefore, easy adjustment. I only have to change the business logic for a field if the existing logic becomes invalid after changing the database structure. You would have to do that in *ANY* application irrespective of how it was written or what framework it uses. >> The fact that the field names on the screen are the same as column names >> in the database is irrelevant. > > You are very much mistaken. How so? >> Only a masochist would use different names > > Or a person considering the limitations of browsers and databases, and the > exploits that can follow from exposing server-side structures as-are to > the > client. How does using the same data names on the screen and the database cause a problem? >> because it would then require a data mapper to translate the names. > > Which is the sensible thing to do, believe it or not. Only in your universe. Intelligent programmers don't use different names in different parts of the system, therefore don't need mappers. >> Coding changes are usually only required when a business rule changes. > > You are still winding around the issue. What was the issue again? You keep losing me with your ridiculous arguments. >>> Moreover, if at some point you do _not_ want to update a field, but the >>> $_POST array contains an element with a key matching a field, that field >>> will be updated anyway. >> >> An incorrect assumption. The UPDATE query is edited (by standard code, >> naturally) to include only those columns which have actually changed. > > You are missing the point. If someone passes in a request array a value > with a key that matches an *existing* database field that you usually > would > not want to have updated, the field would be updated anyway because your > insertRecord() method cannot tell that this field should not be updated at > this time. Whereas "updated" refers to all updates of or requests from > the > table, not only UPDATE queries. My framework updates using whatever data it is given. How does your framework solve this so-called problem? >>> An attacker could use that vulnerability to >>> manipulate your database through the application in ways that you cannot >>> conceive yet. >> >> Prove it. An example of my framework is available at >> http://www.radicore.org/demo.php. Break it if you can. > > You should know that "Show me where it breaks" is a typical luser's reply. > I have told you where and basically how, given your description, the > approach presents a vulnerability. It would be up to you to verify that. No. If you think that there's a vulnerability in my code then it's up to you to prove it. Put Up or Shut Up! >>> This approach also does not appear to account for the possibility that >>> with one request several tables need to be updated. >> >> Easy peasy. Let's suppose a particular INSERT requires data to be added >> to >> TableA, TableB and TableC. I would start by sending all the data to the >> primary table with the statement: >> >> $result - $tableAobject->insertRecord($_POST). >> >> After validation it would create the relevant INSERT query for tableA. It >> would automatically filter out any field names which do not exit in that >> table. >> >> In the _postInsertRecord method of TableA's class I would have the >> following: >> >> $result = $tableBobject->insertRecord($data); >> $result = $tableCobject->insertRecord($data); >> >> Where $data at this point is the validated version of the original $_POST >> array. > > ISTM you are still thinking too linear. There is no inherent connetion > between the two result values. But I was talking about table *relations*. You asked me how I could update several tables with one set of data, and I have shown you how. The relationshop between tables A, B and C is irrelevant. > If the user of the model has to rebuild the relations of a model with > another models in their code, then that is surely a poorly designed model > in > any sense of the "M" in MVC, one that does not scale well on top of that. You are talking nonsense. >> This method is ridiculously simple yet ridiculously effective, but I >> expect that you'll find a way to tell me that it's wrong. > > [x] done > >>> Apropos, how you do implement queries across several tables (JOINs) with >>> your framework? >> >> SELECT statements can have the necessary JOINS added in automatically by >> the framework using information which was exported from the data >> dictionary. It is also possible to override the default query with >> whatever your heart desires. > > OK. How does that look like? Surely you know what a SELECT statement with JOINS looks like? -- Tony Marston http://www.tonymarston.net http://www.radicore.org Report message to a moderator

Re: What Jerry Stuckle thinks of PHP programmers [message #177868 is a reply to message #177858] Tue, 24 April 2012 18:32   Tim Streater Messages: 328 Registered: September 2010 Karma: 0 Senior Member In article <tj3cp7l3hsfbkrcps98arpgaquvr8r7hrh(at)4ax(dot)com>, Ross McKay <au(dot)org(dot)zeta(dot)at(dot)rosko(at)invalid(dot)invalid> wrote: > On Mon, 23 Apr 2012 14:10:00 +0100, Tony Marston wrote: > >> "Jerry Stuckle" <jstucklex(at)attglobal(dot)net> wrote in message >> news:jmu1nc$fui$1(at)dont-email(dot)me... >> <snip> >>> Yea, right. And what is the experience of those programmers? PHP >>> programmers as a whole are not known for their intelligence or competence. >>> In fact, just the opposite is true. >> >> All you PHP programmers in this group now know that Jerry Stuckle, that >> self-proclaimed guru and OO expert, thinks that you are stupid and >> incompetent. >> >> Anyone care to comment? > > For a change, I think he might be close to correct. Having dealt with a > large quantity of other people's code, especially some very large > WordPress plugins, I have to say that PHP code quality that I've seen in > the wild is often very poor. > > At least a compiled language enforces *some* quality corrections on > one's code, whereas PHP (and also JavaScript) seem to be designed to > help total newbie programmers get the job done. This is good, but it > also leads to piles of excremental code that "work" much in the same way > that Microsoft Access allows newbie database wranglers to build > databases that "work". > > Sure, you get bad code in any language, but I sincerely believe that > I've seen more bad PHP code than other bad code (even bad classic ASP > code). Which is not to say that said code didn't "work", for limited > values of "work". The entry level for writing working PHP code is very > low, so you get all comers. Most will learn over time and improve, as we > all continue to do (or most of us anyway, I hope!) All of which is interesting but irrelevant. -- Tim "That excessive bail ought not to be required, nor excessive fines imposed, nor cruel and unusual punishments inflicted" -- Bill of Rights 1689 Report message to a moderator

Re: Dynamic form generation [message #177869 is a reply to message #177865] Tue, 24 April 2012 18:56   Thomas 'PointedEars' Messages: 701 Registered: October 2010 Karma: 0 Senior Member Tony Marston wrote: > "Jerry Stuckle" <jstucklex(at)attglobal(dot)net> wrote in message > news:jn13eu$4ll$1(at)dont-email(dot)me... > <snip> >>>> And you completely miss the question. How do you change a single >>>> property in the object without building the array? >>> >>> BECAUSE THE ARRAY IS ALREADY INSIDE THE OBJECT, YOU IDIOT!!! I don't >>> need code inside the table object to build the array as it is supplied >>> as an array, either from the $_GET or $_POST array, or an array of rows >>> and columns from the database. >> >> So, IOW, you can't change a single property from the program. You can't, >> for instance, set just the ship date in an order. You can only set the >> entire object. How stupid. > > If I have a transaction where the only value that can be changed in the > ship date for an order, then the $POST array will contain "ship_date = > whatever". 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 Report message to a moderator

Re: Dynamic form generation [message #177870 is a reply to message #177865] Tue, 24 April 2012 20:20   Jerry Stuckle Messages: 2598 Registered: September 2010 Karma: 0 Senior Member On 4/24/2012 1:21 PM, Tony Marston wrote: > "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message > news:jn13eu$4ll$1(at)dont-email(dot)me... > <snip> >>>> And you completely miss the question. How do you change a single >>>> property in the object without building the array? >>> >>> BECAUSE THE ARRAY IS ALREADY INSIDE THE OBJECT, YOU IDIOT!!! I don't >>> need code inside the table object to build the array as it is supplied >>> as an array, either from the $_GET or $_POST array, or an array of rows >>> and columns from the database. >> >> So, IOW, you can't change a single property from the program. You can't, >> for instance, set just the ship date in an order. You can only set the >> entire object. How stupid. > > If I have a transaction where the only value that can be changed in the ship > date for an order, then the $POST array will contain "ship_date = whatever". > > My update controller has the line $dbobject->updateRecord($_POST) where > $dbobject is an instance of the order class. > > The order class, as with every other table class in my system, will perform > an update operation using the contents of its input array however many > fields it contains. It does not matter whether it contains 1 field or 100 > fields, it's all the same. > > Why can't you understand such a simple concept? > 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.languag e > 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(at)attglobal(dot)net ================== Report message to a moderator

Re: Dynamic form generation [message #177872 is a reply to message #177842] Wed, 25 April 2012 07:52   Tony Marston Messages: 57 Registered: November 2010 Karma: 0 Member "Jerry Stuckle" <jstucklex(at)attglobal(dot)net> wrote in message news:jn3mi4$29f$1(at)dont-email(dot)me... <snip> > Again, true. Good programmers can agree on what's good code and what's > crap code. Just because someone does things a different way doesn't make > it "bad". > > And I've found a direct correlation between the quality of a programmer > and his/her willingness to accept criticism. I can accept criticism in the form of "you do it that way, but wouldn't this way be better?", but all you sem to do is state time and timer again "your way is different from mine, therefore it must be crap". > Good programmers can take suggestions on their own code objectively. Poor > programmers will defend their crap until the day they die (and longer if > they could). I would always welcome suggestions to improve my code, but by "improve" I do *NOT* mean "make it the same as mine". If I did everything the same as you then I would be no better than you, and I'm afraid that your best is not good enough. The fact that my methods of achieving a result are different from yours does not make my methods "wrong", only "different". They work, therefore they are not wrong. You have not provided any code samples that demonstrate that your methods are superior, so why should I or anyone else believe that your methods are superior? Just be cause you say so? -- Tony Marston http://www.tonymarston.net http://www.radicore.org Report message to a moderator

Re: Dynamic form generation [message #177873 is a reply to message #177869] Wed, 25 April 2012 08:23   Tony Marston Messages: 57 Registered: November 2010 Karma: 0 Member "Thomas 'PointedEars' Lahn" <PointedEars(at)web(dot)de> wrote in message news:1430094(dot)ghCgKLUCYl(at)PointedEars(dot)de... > Tony Marston wrote: > >> "Jerry Stuckle" <jstucklex(at)attglobal(dot)net> wrote in message >> news:jn13eu$4ll$1(at)dont-email(dot)me... >> <snip> >>>> > And you completely miss the question. How do you change a single >>>> > property in the object without building the array? >>>> >>>> BECAUSE THE ARRAY IS ALREADY INSIDE THE OBJECT, YOU IDIOT!!! I don't >>>> need code inside the table object to build the array as it is supplied >>>> as an array, either from the $_GET or $_POST array, or an array of rows >>>> and columns from the database. >>> >>> So, IOW, you can't change a single property from the program. You >>> can't, >>> for instance, set just the ship date in an order. You can only set the >>> entire object. How stupid. >> >> If I have a transaction where the only value that can be changed in the >> ship date for an order, then the $POST array will contain "ship_date = >> whatever". > > 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 Report message to a moderator

Re: What Jerry Stuckle thinks of PHP programmers [message #177875 is a reply to message #177868] Wed, 25 April 2012 09:02   Ross McKay Messages: 14 Registered: January 2011 Karma: 0 Junior Member On Tue, 24 Apr 2012 19:32:24 +0100, Tim Streater wrote: > All of which is interesting but irrelevant. Like Jerry? :) -- Ross McKay, Toronto, NSW Australia "Well I must have a door in the back of my head Where I dump out all the crap so I can just feel solid again" - Dandy Warhols Report message to a moderator

Re: Dynamic form generation [message #177876 is a reply to message #177870] Wed, 25 April 2012 09:04   Tony Marston Messages: 57 Registered: November 2010 Karma: 0 Member "Jerry Stuckle" <jstucklex(at)attglobal(dot)net> wrote in message news:jn71ur$o4l$1(at)dont-email(dot)me... > On 4/24/2012 1:21 PM, Tony Marston wrote: >> "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message >> news:jn13eu$4ll$1(at)dont-email(dot)me... >> <snip> >>>> > And you completely miss the question. How do you change a single >>>> > property in the object without building the array? >>>> >>>> BECAUSE THE ARRAY IS ALREADY INSIDE THE OBJECT, YOU IDIOT!!! I don't >>>> need code inside the table object to build the array as it is supplied >>>> as an array, either from the $_GET or $_POST array, or an array of rows >>>> and columns from the database. >>> >>> So, IOW, you can't change a single property from the program. You >>> can't, >>> for instance, set just the ship date in an order. You can only set the >>> entire object. How stupid. >> >> If I have a transaction where the only value that can be changed in the >> ship >> date for an order, then the $POST array will contain "ship_date = >> whatever". >> >> My update controller has the line $dbobject->updateRecord($_POST) where >> $dbobject is an instance of the order class. >> >> The order class, as with every other table class in my system, will >> perform >> an update operation using the contents of its input array however many >> fields it contains. It does not matter whether it contains 1 field or 100 >> fields, it's all the same. >> >> Why can't you understand such a simple concept? > > 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 Report message to a moderator

Re: What Jerry Stuckle thinks of PHP programmers [message #177882 is a reply to message #177875] Wed, 25 April 2012 11:20   The Natural Philosoph Messages: 993 Registered: September 2010 Karma: 0 Senior Member Ross McKay wrote: > On Tue, 24 Apr 2012 19:32:24 +0100, Tim Streater wrote: > >> All of which is interesting but irrelevant. > > Like Jerry? :) Jerry isn't even interesting. -- 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. Report message to a moderator

[OT] Was: Dynamic form generation [message #177883 is a reply to message #177861] Wed, 25 April 2012 11:22   Erwin Moller Messages: 228 Registered: September 2010 Karma: 0 Senior Member 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 Report message to a moderator   Next Page

Pages (3): [ «  ‹  1  2  3  ›  »]

Previous Topic:	Data injection problems
Next Topic:	Do you want to develop PHP for the Web and make money

Goto Forum:

- FUDforum  FUDforum Announcements  FUDforum Installation Issues  How To  FUDforum Suggestions- FUDforum Development  FUDforum 3.0+  Bug Reports  Plugins and Code Hacks  Converters  Translations  Forum Styles  Icons & buttons  Forum Showcase  Marketplace- General  General Chit Chat  FUDforum in eGroupWare  PHP discussions  Database discussions  HTML, Javascript, jQuery & AJAX  Test Forum  Test subforum 1  Test subforum 2- Imported messages  comp.lang.php