| Re: Dynamic form generation [message #177760 is a reply to message #177752] |
Fri, 20 April 2012 11:47   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 4/20/2012 4:27 AM, Tony Marston wrote:
> "Jerry Stuckle" wrote in message news:jmp0gb$d8$1(at)dont-email(dot)me...
>>
>> On 4/19/2012 4:56 AM, Tony Marston wrote:
>>> "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message
>>> news:jmmabk$67a$1(at)dont-email(dot)me...
>>>> On 4/18/2012 4:33 AM, Tony Marston wrote:
>>>> > "Jerry Stuckle" wrote in message news:jmk2lu$hgn$1(at)dont-email(dot)me...
>>>> >>
>>>> >> On 4/17/2012 8:49 AM, Thomas 'PointedEars' Lahn wrote:
>>>> >>> Denis McMahon wrote:
>>>> >>>
>>>> >>>> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote:
>>>> >>>>> If you used a proper framework ...
>>>> >>>>
>>>> >>>> ... then you'd have all the junk and baggage that comes along with
>>>> >>>> that
>>>> >>>> framework, including any security flaws in the framework.
>>>> >>>>
>>>> >>>> Not saying that frameworks are inherently bad, but they're not
>>>> >>>> automatically the solution either.
>>>> >>>
>>>> >>> TINSTAAFL. If you want complete flexibility of the application as
>>>> >>> the
>>>> >>> OP
>>>> >>> wants, you have to have an abstraction layer in your application,
>>>> >>> i.e. it
>>>> >>> has to be built on a framework (some people really should reflect on
>>>> >>> the
>>>> >>> term "framework" and its etymology). Abstraction layers come at a
>>>> >>> price:
>>>> >>> Increased overall complexity of the application and decreased
>>>> >>> efficiency for
>>>> >>> tasks that do not require as much flexibility.
>>>> >>>
>>>> >>
>>>> >> Yup, and when you use a framework you force the application to match
>>>> >> the framework, instead of allowing the application to meet the
>>>> >> client's needs.
>>>> >>
>>>> >> It may work - but then it may not, also.
>>>> >
>>>> > The client's needs are met by screens/reports which have the right
>>>> > layout and which perform the right functions. My framework does not
>>>> > stand in the way of that at all. When user transactions are initially
>>>> > generated they have default screens and default behaviour, but
>>>> > these can
>>>> > be customised to whatever level of sophistication you want.
>>>> >
>>>>
>>>> The client's needs are met by the APPLICATION. This is much more
>>>> than the
>>>> screens and the layouts. But then if all you do are trivial database
>>>> applications, then I can see where something like that can help.
>>>
>>> An application is nothing more than a collection of individual
>>> components,
>>> where each component does a "unit of work" from the user's point of
>>> view. A
>>> small application has a small number of components, while a large
>>> application has a large number of components.
>>>
>>
>> I can understand how someone like you who does such simple stuff
>> things that way. But then you've never worked on something even
>> moderately complex.
>
> Building an entire ERP system with 1700 transactions is much more than
> "simple". I work on business applications for corporations, not toy
> systems for hobbyists.
>
Building a *decent* ERP is complex. SAP, for instance, has a good one.
They have several hundred programmers working on it constantly.
What you call an "ERP" is nothing like that.
>> A large application is much more complex than just having "a large
>> number of components".
>
> I disagree. An application which uses 200 database tables is more
> complex than one which uses only 2, and the more tables you have the
> more maintenance screens you require.
>
That's because you've never worked on a complex application. Your claim
of an ERP is proof of that.
All you do is database stuff. There's nothing complex about that.
>>>> However, your example of over 200 tables and 350 relationships is a
>>>> perfect example of how bloated such code can become.
>>>
>>> The term "bloat" implies having things which are not used, and I can
>>> assure
>>> you that every database table has a purpose and is used in one or more
>>> transactions. If a database table ever became redundant then I would
>>> remove
>>> it.
>>>
>>
>> Not at all. "Bloat" also refers to applications which are overly large
>> for what needs to be done.
>
> My applications are not overly large. While I have a large number of
> small transactions each of which does one thing, this is not "bloat", it
> is following the Single Responsibility Principle.
>
>
Nope, they aren't, because your applications are just for database access.
But they sure sound like they're bloated.
>> My databases are based on the designs in Len Silverston's Data Model
>>> Resource book. So far I have implemented the PARTY, PRODUCT, ORDER,
>>> INVENTORY, SHIPMENT, INVOICE, REQUEST and WORK-EFFORT databases. If you
>>> bother to read his book you wil see that every table serves a purpose.
>>>
>>
>> Yes, that works fine for simple applications. But then you've already
>> said that's all you do. You've never worked on anything even
>> moderately complex.
>
> I would like to see *YOU* design and build an ERP application basedon
> those databases and then tell me it's simple!
>
I'd like to see YOU create a REAL ERP application! All you did was
build database access to multiple tables. ERP is much more than that.
>>>> >>> Whether that framework was written by you or someone else is another
>>>> >>> matter.
>>>> >>> Chances are that a framework written by someone else has already
>>>> >>> gained
>>>> >>> enough adoption in the global software community that its flaws -
>>>> >>> including
>>>> >>> security flaws - are more quickly detected and fixed than in a
>>>> >>> framework
>>>> >>> that you have written yourself. On the other hand, chances are
>>>> >>> that a
>>>> >>> framework you have written yourself can be better adjusted *by you*
>>>> >>> to do
>>>> >>> what you want than a framework written by someone else,
>>>> >>> especially if
>>>> >>> you
>>>> >>> created it for the same project in which you are using it.
>>>> >>>
>>>> >>
>>>> >> So? Good programming practices and test cases will eliminate more
>>>> >> security flaws than many of the "frameworks" out there. Have you seen
>>>> >> some of the crap code which has been written "by committee"? Not all
>>>> >> of it, but a lot of the donations are from people who don't really
>>>> >> understand what they're doing - or at least don't write code like
>>>> >> they
>>>> >> know what they're doing.
>>>> >>
>>>> >>> Inevitably all frameworks become bloated if functionality for
>>>> >>> flexibility
>>>> >>> keeps being added to them. It would appear that there is a point
>>>> >>> where
>>>> >>> a
>>>> >>> framework author should stop improving it and start something new
>>>> >>> for
>>>> >>> a new
>>>> >>> project, maybe based on old code (but sometimes a rewrite is less
>>>> >>> expensive
>>>> >>> and turns out to be better). IOW, it is a good idea if you built
>>>> >>> frameworks
>>>> >>> with modularity in mind and use them only *as needed* (not simply
>>>> >>> for
>>>> >>> the
>>>> >>> sake of using them, like trying to appear cool to the crowd).
>>>> >>>
>>>> >>>
>>>> >>> PointedEars
>>>> >>
>>>> >> 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.
>>>
>>
>> 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.
>>> 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.
>>>> 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.
Bloat, bloat, bloat.
>> 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.
>>>> Others, like passwords where the rules may change, allow the validation
>>>> to be handled by a regex, function call or similar.
>>>
>>> In my framework any password rues - such as minimum length, the
>>> number of
>>> uppercase characters, the number of lowercase characters, the number of
>>> digits - is controlled from a database record. Each customer can
>>> therefore
>>> change the rules without me having to change any code.
>>>
>>
>> More bloat. And unnecessary.
>
> It is necessary if I want to allow the customer to change the password
> validation rules without having to write any code. Not having to write
> code is not bloat.
>
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?
Why stop with the password? Why not let the customer change the window
layout, for instance? Or add tables and columns to the database?
Your code is just bloatware and adds an unnecessary layer of complexity
to the code.
>>>> 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.
>>>> 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.
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.
>>> 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.
When there is no parent/child relationship (as in the case of two
different database tables), there is no polymorphism.
>>>> >> However, since each class is pretty much independent, I can easily
>>>> >> change a class without affecting the rest of the program.
>>>> >
>>>> > So can I with my framework.
>>>> >
>>>> >> I don't have it where it will work with multiple tables yet
>>>> >> (something
>>>> >> I will do one of these days), but it takes a huge amount of the
>>>> >> repetitive work off of me.
>>>> >
>>>> > Removing the need for all this repetitive coding, the "plumbing" as I
>>>> > call it, is exactly what my framework does.
>>>> >
>>>>
>>>> Not if it only generates a tiny bit of code.
>>>
>>> You are missing the point as usual. My framework need only generate a
>>> small
>>> amount of code as everything else, especially all the standard
>>> plumbing, is
>>> included from standard pre-written functions.
>>>
>>
>> No, I'm missing nothing. But you've clearly shown just how crappy your
>> code is.
>
> Just because it's different from yours does not make it crap.
>
It's not because it's different that it's crap. It's crap because
you've shown here it's crap.
>>>> >> And no, I don't try to use it for every project. But where a project
>>>> >> is database-intensive, it suits my purposes.
>>>> >
>>>> > All my applications are database-intensive, which is why I use a
>>>> > framework which is centred around the database.
>>>> >
>>>>
>>>> Ah, that explains it, then. Database access is easy (although many
>>>> people
>>>> can still screw that up). Most of my applications need to do real work.
>>>
>>> My framework takes care of all the standard database access, and getting
>>> data in and out of the screen, plus basic data validation. As for the
>>> "real
>>> work" as you call - or the "payload" as I call it - that is done by
>>> adding
>>> whatever code is necessary in the relevant class to implement each
>>> business
>>> rule. The point is that when using my framework the programmer has to
>>> spend
>>> little or no time on the standard plumbing, which leaves him with
>>> much more
>>> time to spend on the payload.
>>>
>>
>> Yup, you've never done any applications which require real work, as
>> you once again have shown.
>
> Then you obviously have not experienced the complicated things which
> need to be done in an ERP application.
>
Obviously neither have you. What you have is not a real ERP
application. I suspect your customer would do as well with an Excel
spreadsheet.
And I wonder what your customer would think if he knew you were taking
credit for his hard work in building his business.
>>>> But I'm also not so stupid as to think that my frameworks is good for
>>>> everyone. It works for me. But I don't try to foist it off on someone
>>>> else without telling them it's my framework. That is just plain
>>>> dishonest.
>>>
>>> I never said that my framework is the perfect solution for everyone.
>>> If you
>>> a writing a simple website then it's not good, but if you are writing a
>>> database application then it's better than most.
>>>
>>
>> Hmmm, you sure seemed to indicate that when you first started pushing
>> this piece of horse hockey.
>
> That may have been the impression that you got, but you have indicated
> time and time again that your mind works in mysterious ways.
>
Yea, I live in the real world and have real world experience. Unlike
you, who seems to live in some alternative universe where you can make
up any rules you want and can ignore those you don't like. You can call
a simple database application an ERP and take all the credit for your
client's hard work.
>>> 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.
>>>
>>
>> And you never said it was written by you, and that you were nowhere
>> near an unbiased user. The fact you are pushing your own product
>> without telling people you have a vested interest is dishonest. The
>> fact you have a link to it in your sig is immaterial - lots of people
>> have links in their sigs to all kinds of things.
>>
>> But then I can see why you don't want to tell people it's your
>> product. I wouldn't want to admit to having created that piece of
>> horse hockey, either.
>
> You're the expert in horse hockey judging by the amount you write in
> these posts.
>
Nope, I know how to program properly. You've obviously never worked in
a corporate environment, for instance, where you have multiple
programmers and have to learn good programming techniques.
>>> 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. Unlike you, I don't need my
ego stroked.
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.
--
==================
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
]