| Re: Dynamic form generation [message #177791 is a reply to message #177790] |
Sat, 21 April 2012 10:21   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 4/21/2012 5:35 AM, Tony Marston wrote:
> "Jerry Stuckle" wrote in message news:jmrjmk$ubd$1(at)dont-email(dot)me...
>>
>> On 4/20/2012 5:10 AM, Tony Marston wrote:
>>> "Jerry Stuckle" wrote in message news:jmp154$4tt$1(at)dont-email(dot)me...
>>>>
>>>> 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.
>>>
>>> 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.
>>>
>>
>> Sure I do. Your description of it right here. And what is that "vast
>> majority"? How many people actually use your code instead of just
>> downloading it and tossing it out?
>
> You cannot possibly tell if code is unmaintainable just by a simple
> description. You have to work with the code and actually maintain it
> before you can make that judgement.
>
From your description, any good programmer can tell your code is crap.
Only those like yourself can't see crap when it's described.
> 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.
But then you're a great example of the latter.
>>>> And it IS possible to satisfy multiple programmers. But then you've
>>>> never worked on anything even slightly complex, so you have no idea.
>>>
>>> So you are saying that an ERP system with 1700 transactions is not
>>> complex then you have a strange idea of what "complex" really means.
>>>
>>
>> Not what you wrote, it isn't. A real ERP system takes a lot of
>> programmers a long time to develop. SAP is an example of a REAL ERP
>> implementation.
>
> Not if you use the right framework. I started with Len Silverston's
> database models (as I mentioned in a previous post), and using the
> Radicore framework (which was specifically built to work from database
> schemas) I had the first version working in 6 months. This was because I
> didn't have to waste my time writing any code to carry out the boring
> and repetitive plumbing work. Instead I could concentrate on the payload
> - all the business rules and clever stuff. I certainly did not have to
> do any of that cut/paste/modify that you seem so fond of.
>
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.
>>> <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?
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.
>> 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. But less code can
mean MORE complexity. However, you've never worked on anything
non-trivial, so you wouldn't understand.
>>>> >> And MVC is quite popular amongst some programmers, mainly those
>>>> >> writing
>>>> >> web apps. But it never really picked up in the business world for
>>>> >> many
>>>> >> reasons.
>>>> >
>>>> > I write business applications, initially for the desktop but now
>>>> > for the
>>>> > web. I have tried many different paradigms in my long career, and I
>>>> > have
>>>> > found the 3-Tier architecture to be the best, so that it what I
>>>> > decided to
>>>> > use for my PHP framework. It just happens that after I wrote it a
>>>> > fellow
>>>> > programmer told me that I had also implemented the MVC pattern.
>>>> >
>>>>
>>>> It's an OK platform. But not suitable for every application. However,
>>>> what did your "business applications" do? Room reservations for a
>>>> hotel? Or another database application?
>>>
>>> You obviously don't know what ERP means, do you? I write e-commerce
>>> applications, which means that I have to deal with customers and
>>> suppliers, organisations and people, products, product features, product
>>> prices, sales orders, purchase orders, transfer orders, invoices, credit
>>> notes, inventory, shipments, requests and requirements, work effort.
>>>
>>
>> Unlike you, I DO know what ERP is, and I know what goes into a REAL
>> ERP application. What you describe is an e-commerce application,
>> available all over the internet. Not an ERP application.
>
> A "real" ERP application is basically an order processing or order
> fulfilment system (also known as supply chain management. It starts with
> sales orders (which may be entered via a front-end website) and then
> helps the organisation process those orders through authorisation,
> generating pick lists, issuing from inventory, packaging, and shipping
> to the customer. It will also have to deal with customer returns,
> possible purchase orders to suppliers and receipts from suppliers, as
> well as invoicing and credit notes.
>
No, a REAL ERP application does a lot more than that. What you describe
is an order entry/tracking system. A real ERP system also does all the
accounting (including taxes), payroll, benefits, budgeting and all kinds
of things. But then you've never seen a real ERP system, that's obvious.
Your order entry/tracking system doesn't even begin to approach the
capabilities of even the most limited ERP system.
> 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.
All you have is a simple order entry/tracking system.
> That describes the ERP system that a major client of mine has been using
> for 4 years. Simply having a website that accepts sales orders would be
> useless without a back-office system that allows them to get the goods
> shipped to the customer as quickly as possible.
>
All you have is a simple order entry/tracking system.
>> And if it were designed properly it wouldn't need over 200 tables.
>> Bloat, bloat, bloat.
>
> You obviously don't know what it means to normalise data, so I presume
> you work with toy spreadsheets and not proper relational databases.
>
I was normalizing data long before you knew what relational databases
were - back in the early 80's. But your customer could do just as well
with an excel spreadsheet.
>>> It's also multi-lingual and multi-currency.
>>>
>>
>> Whoppee. No big thing there.
>
> It is if you want it done properly. I've seen other people's attempts at
> providing a multi-lingual and multi-currency system, and they have been
> quite hilarious. For my major client they have a single set of central
> databases which is maintained by my ERP system, but they have several
> websites which use different languages (German, Swedish and American)
> and different currencies (Sterling, Euros, Krona and Dollars) and which
> are fed from the same central databases. This means that any text which
> is obtained from the database has to be supplied in the correct
> language, and when orders are taken they are stored in Sterling but with
> the currency code and current exchange rate.
>
Only a big thing for you, obviously. Not for any competent programmer.
And you do not have an ERP system. All you have is a simple order
entry/tracking system.
> When invoices are sent out they use the language and currency of the
> customer.
>
No big problem there, either, for a competent programmer. But you seem
to think it's a really big thing.
That speaks wonders of your "competence".
> When automated emails are sent out they use the language of the customer.
>
Again, no big thing.
> If you have ever written such a system (which I seriously doubt) you
> would realise that it is far from being simple.
>
Sorry to say, but I was doing it in the 80's on mainframes when working
for IBM. No big thing.
BTW - do you do Katakana? Now that gets a bit more difficult!
>>> <snip>
>>>> >> You've obviously never been involved with a large application. Try
>>>> >> something with> 3M LOC. Or when you have 100+ programmers working
>>>> >> on a
>>>> >> project for 3+ years.
>>>> >
>>>> > 3M LOC is a meaningless figure if that contains a lot of duplicated
>>>> > code. If
>>>> > I achieved exactly the same result, but in only 1M LOC would that
>>>> > make my
>>>> > application smaller? It is what the application does which is
>>>> > important, not
>>>> > how many lines of code it takes to achieve it.
>>>> >
>>>>
>>>> You couldn't do an application like this in 1M LOC. But then you've
>>>> never worked on anything moderately complex, obviously.
>>>
>>> I don't copy and paste like you do, I write reusable functions. This
>>> means that I achieve similar results with less code.
>>>
>>
>> You only assume cut and paste.
>
> 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.
>> But you've never written a complex application, so you have no idea.
>
> Then our definitions of "complex" must surely differ. If you write
> applications where a single script can perform the functions of list,
> enquire, add, update, delete and search then it can only be a simple
> application in my book. I have been writing database applications for
> businesses for decades, and that "simple" approach would never be accepted.
>
Sure, a single CLASS can do all that. It works great.
Now let's see how many OS's you've worked on. Or compilers.
> 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.
>>>> >> 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.
> 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. Nor is
database normalization (which you also claimed to know how to do
properly - which I also doubt) in that same post.
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.
>>>> >> They are fine for simple applications. But your previous example
>>>> >> of an
>>>> >> application with> 200 tables and 350 relationships shows what can
>>>> >> (and
>>>> >> usually does) happen.
>>>> >
>>>> > An application is merely a collecton of individual components, and
>>>> > it is
>>>> > possible for a small application to grow larger simply by adding new
>>>> > components. A framework which helps you build new components quickly,
>>>> > and
>>>> > which provides as much of the plumbing code as possible so that the
>>>> > programmer can spend his valuable time by concentrating on the
>>>> > payload,
>>>> > should be of considerable benefit.
>>>> >
>>>>
>>>> An overly simplistic statement from someone who's never worked on any
>>>> even moderately complex application.
>>>
>>> My statement is not overly simplistic. Your statement is overly complex.
>>>
>>
>> Once again, you have no idea what an even moderately complex
>> application is. All you've done is database applications and simple
>> e-commerce (and called it ERP).
>
> You simply don't know what constitutes an ERP system, do you? Look at
> the wikipedia defintion at
> http://en.wikipedia.org/wiki/Enterprise_resource_planning
>
I do, much more than you do. And all you've got is a simple order
entry/tracking system.
An ERP system includes all those modules - that's why it's called
ENTERPRISE RESOURCE STEM - not order entry/tracking.
>>> <snip>
>>>> >>>>> When using the Radicore framework it provides all the plumbing
>>>> >>>>> code for
>>>> >>>>> you, you only have to add code to deal with business rules
>>>> >>>>> which go
>>>> >>>>> beyond what Radicore provides as standard.
>>>> >>>>>
>>>> >>>>
>>>> >>>> Ah, so you DO have to write PHP code, then.
>>>> >>>
>>>> >>> Only when necessary, and then only for the payload, not the
>>>> >>> plumbing.
>>>> >>>
>>>> >>
>>>> >> You said earlier you didn't have to write any code. Now the truth
>>>> >> comes
>>>> >> out.
>>>> >
>>>> > You're not reading what I wrote - I said that my framework generates a
>>>> > runnable but basic transaction with default behaviour. I only need to
>>>> > write
>>>> > any code when I want to change the defaults.
>>>> >
>>>>
>>>> Yes, I did. Maybe you need to go back and read what you wrote. And now
>>>> the truth is out and you have to backpedal.
>>>
>>> I'm not back pedalling. I simply said that my framework generates basic
>>> yet runnable transactions with default behaviour. All the programmer has
>>> to do is change the defaults where necessary.
>>>
>>
>> Just continue backpedaling.
>
> You don't know what back pedalling really means, do you? You're just
> like that character in Alice in Wonderalnd yoiu says "aword means
> whatever I want it to mean, nothing more and nothing less".
>
Nope, you just continue to backpedal then you're called on it, you try
to change the meaning.
>>> <snip>
>>>> >> And how does it do that? How does it know, for instance, the needed
>>>> >> rules
>>>> >> for a password? Once again you said you didn't need to write any
>>>> >> code.
>>>> >
>>>> > I have one password validation routine which I wrote many years
>>>> > ago. The
>>>> > validation rules - such as minimum length, the number of uppercase
>>>> > characters, the number of lowercase characters, the number of digits
>>>> > - is
>>>> > defined on a database table. Thus the rules can be changed by changing
>>>> > values on a screen and not by writing code.
>>>> >
>>>>
>>>> Bloat... How often do you need to change the rules? None of my
>>>> customers have ever needed to.
>>>
>>> The point is that any of my customers can change the password rules to
>>> whatever they want without me having to change any code.
>>>
>>
>> And how often do they need to change the rules? None of my customers
>> ever needed to.
>
> A customer may not need to change the rules once the system has been
> installed, but if you write a package that may be used by numerous
> customers then different rules may need to be specified when the system
> is installed.
>
Bloat, bloat, bloat.
>> But then we discuss that up front, along with the pros and cons of
>> different rule sets. The result is a simple one-line password
>> verification rule - not bloatware.
>
>>>> 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.
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.
>> 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.
>>>> >>>> Yes, I know you think your toy is the answer to life, the universe
>>>> >>>> and
>>>> >>>> everything. But it isn't.
>>>> >>>
>>>> >>> It works in my universe, but my universe is not centered around
>>>> >>> Uranus.
>>>> >>>
>>>> >>
>>>> >> That's true. You are in some alternate universe. Hopefully you never
>>>> >> get
>>>> >> a customer who knows something.
>>>> >
>>>> > Really? My biggest customer has been using my ERP application for
>>>> > over 4
>>>> > years, and it has helped them triple their turnover to £2.5M per year
>>>> > while
>>>> > lowering their costs.
>>>> >
>>>>
>>>> So? They probably could have doubled that again by using an
>>>> spreadsheet. Too bad your code held them back.
>>>
>>> A single spreadsheet cannot be access simultaneously by multiple users,
>>> and a spreadsheet cannot possible handle the requirements of an ERP
>>> system. You need a proper database for that, and a proper database
>>> application to go with it.
>>>
>>
>> Neither can your code. All your code is is a simple e-commerce system,
>> one of many available on the internet.
>
> I have looked at the documentation for several of these ecommerce
> packages, and I have never seen anything mentioned about those functions
> which are used only by members of staff which enable them to process the
> sales orders. These ecommerce packages concentrate only on the front-end
> website and totally ignore the back-end administrative functions.
>
So, what have you looked at. The open source free things out there?
There is a lot more out there than what you find on SourceForge and the
like.
> 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.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]