| Re: Dynamic form generation [message #177761 is a reply to message #177755] |
Fri, 20 April 2012 12:09   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
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?
>> 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.
> <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. If you understood even the very
basics of OO programming (one of which is encapsulation), you would know
why they are needed.
Less code does not mean less complexity. In fact, just the opposite can
be true.
>>>> 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.
And if it were designed properly it wouldn't need over 200 tables.
Bloat, bloat, bloat.
> It's also multi-lingual and multi-currency.
>
Whoppee. No big thing there.
> <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. But you've never written a complex
application, so you have no idea.
>>>> 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?
Even DOS 1.0 was more complex than anything you've written.
>>>> 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).
> <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.
> <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. 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.
>> 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.
How many customers have actually demanded the need to change the rules?
In over 30 years of programming for clients, none of mine have.
>>>> >> 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.
--
==================
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
]