| Re: Dynamic form generation [message #177743 is a reply to message #177738] |
Thu, 19 April 2012 12:41   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
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...
>> On 4/18/2012 4:10 AM, Tony Marston wrote:
>>> "Jerry Stuckle" wrote in message news:jmjfdk$vmp$1(at)dont-email(dot)me...
>>>>
>>>> On 4/17/2012 4:18 AM, Tony Marston wrote:
>>>> > "Jerry Stuckle" wrote in message news:jmhd8m$6jr$1(at)dont-email(dot)me...
>>>> >>
>>>> >> On 4/16/2012 10:11 AM, Tony Marston wrote:
>>>> >>> "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message
>>>> >>> news:jmh3iq$f4m$1(at)dont-email(dot)me...
>>>> >>>> On 4/16/2012 4:31 AM, Tony Marston wrote:
>>>> >>>>> "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message
>>>> >>>>> news:jmeg9a$5pt$2(at)dont-email(dot)me...
>>>> >>>>>> On 4/15/2012 3:33 AM, Tony Marston wrote:
>>>> >>>>>>> "Peter H. Coffin"<hellsop(at)ninehells(dot)com> wrote in message
>>>> >>>>>>> news:slrnjoj0b7(dot)4ci(dot)hellsop(at)nibelheim(dot)ninehells(dot)com...
>>>> >>>>>>>> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote:
>>>> >>>>>>>>>
>>>> >>>>>>>>> "Charles"<cchamb2(at)gmail(dot)com> wrote in message
>>>> >>>>>>>>> news:6651622.883.1334288601914.JavaMail.geo-discussion-forums@vbbfj25...
>>>> >>>>>>>>>
>>>> >>>>>>>>>
>>>> >>>>>>>>>> Absolutely correct. The database has 34 active and 34
>>>> >>>>>>>>>> historical
>>>> >>>>>>>>>> tables
>>>> >>>>>>>>>> so far, and my guess is that about another dozen or so of
>>>> >>>>>>>>>> each to
>>>> >>>>>>>>>> create.
>>>> >>>>>>>>>> I can visualize the relationships between the tables, and I'm
>>>> >>>>>>>>>> normalizing
>>>> >>>>>>>>>> as
>>>> >>>>>>>>>> I go on table structure, but having to write and maintain
>>>> >>>>>>>>>> somewhere
>>>> >>>>>>>>>> around
>>>> >>>>>>>>>> 150 scripts each and every time I so much as sneeze
>>>> >>>>>>>>>> (add/remove a
>>>> >>>>>>>>>> field
>>>> >>>>>>>>>> or
>>>> >>>>>>>>>> change a field type in any of the 100 tables) is daunting.
>>>> >>>>>>>>>
>>>> >>>>>>>>>> I'm just as comfortable with calling a script to do crate each
>>>> >>>>>>>>>> form
>>>> >>>>>>>>>> as
>>>> >>>>>>>>>> I
>>>> >>>>>>>>>> need it.
>>>> >>>>>>>>>
>>>> >>>>>>>>>> Any suggestions?
>>>> >>>>>>>>>
>>>> >>>>>>>>> If you used a proper framework then you wouldn't have to do so
>>>> >>>>>>>>> much
>>>> >>>>>>>>> work
>>>> >>>>>>>>> for
>>>> >>>>>>>>> a minor database change. If you used radicore all you would
>>>> >>>>>>>>> have to
>>>> >>>>>>>>> do
>>>> >>>>>>>>> is
>>>> >>>>>>>>> re-import the table's structure into the data dictionary and
>>>> >>>>>>>>> then
>>>> >>>>>>>>> export
>>>> >>>>>>>>> the
>>>> >>>>>>>>> updated structure to replace the table's structure file. The
>>>> >>>>>>>>> only
>>>> >>>>>>>>> time
>>>> >>>>>>>>> you
>>>> >>>>>>>>> would need to modify another script would be if you needed to
>>>> >>>>>>>>> change
>>>> >>>>>>>>> the
>>>> >>>>>>>>> screen structure (by modifying a small screen structure file)
>>>> >>>>>>>>> or a
>>>> >>>>>>>>> business
>>>> >>>>>>>>> rule (by modifying that table's class file).
>>>> >>>>>>>>
>>>> >>>>>>>> Wow.... All that. All Charles *really* needed to do was actually
>>>> >>>>>>>> specify
>>>> >>>>>>>> what column names he was fetching and 90% of the work he wants
>>>> >>>>>>>> to
>>>> >>>>>>>> eliminate GOES AWAY AUTOMATICALLY.
>>>> >>>>>>>
>>>> >>>>>>> But what if he has already built built a script (which should be
>>>> >>>>>>> several
>>>> >>>>>>> scripts by the way, one each for LIST, ADD, ENQUIRE, UPDATE,
>>>> >>>>>>> DELETE and
>>>> >>>>>>> SEARCH) then he changes the table's structure? Maybe by adding a
>>>> >>>>>>> field,
>>>> >>>>>>> removing a field, or changing a field's size or type? In a
>>>> >>>>>>> non-framework
>>>> >>>>>>> world you have to modify every script which references that table
>>>> >>>>>>> - you
>>>> >>>>>>> have
>>>> >>>>>>> to change the screen definition, you have to change the
>>>> >>>>>>> validation
>>>> >>>>>>> rules,
>>>> >>>>>>> and you have to change the code which communicates with the
>>>> >>>>>>> database.
>>>> >>>>>>> With a
>>>> >>>>>>> framework like Radicore - which was specifically built for
>>>> >>>>>>> database
>>>> >>>>>>> applications and not websites - all of that grunt work is
>>>> >>>>>>> eliminated.
>>>> >>>>>>> It
>>>> >>>>>>> saves time, and time is money.
>>>> >>>>>>>
>>>> >>>>>>
>>>> >>>>>> Not at all true. Ever heard of include(), for instance? And why
>>>> >>>>>> does
>>>> >>>>>> he
>>>> >>>>>> need separate scripts for LIST, ADD, etc.?
>>>> >>>>>
>>>> >>>>> Because each of the LIST, ADD, ENQUIRE, UPDATE, DELETE and SEARCH
>>>> >>>>> functions
>>>> >>>>> has a different screen structure, different behaviour, and may need
>>>> >>>>> different security considerations - somebody may be able to
>>>> >>>>> access the
>>>> >>>>> LIST,
>>>> >>>>> ENQUIRE and SEARCH screens, but not the ADD, UPDATE and DELETE
>>>> >>>>> screens.
>>>> >>>>> It
>>>> >>>>> is much easier to control access if they are separate
>>>> >>>>> functions/transactions. Instead of having code inside a huge
>>>> >>>>> function you
>>>> >>>>> have a database-driven Role Based Access Control (RBAC) system
>>>> >>>>> built into
>>>> >>>>> your framework which allows you to turn access ON or OFF at the
>>>> >>>>> function
>>>> >>>>> level simply by updating the database. Another advantage of this
>>>> >>>>> method
>>>> >>>>> is
>>>> >>>>> that if you don't have access to a function then it can be edited
>>>> >>>>> out of
>>>> >>>>> the
>>>> >>>>> display of menu buttons.
>>>> >>>>>
>>>> >>>>
>>>> >>>> So? None of this requires different scripts.
>>>> >>>
>>>> >>> Each screen should have its own script, and a LIST screen which shows
>>>> >>> summary data for many rows going across the page with column labels
>>>> >>> across
>>>> >>> the top is different from a detail screen (ADD, ENQUIRE, UPDATE,
>>>> >>> DELETE and
>>>> >>> SEARCH) which shows details for a single row going down the page with
>>>> >>> labels
>>>> >>> on the left and values on the right. This break is even more
>>>> >>> essential when
>>>> >>> there is simply too many fields for each row in a LIST screen.
>>>> >>>
>>>> >>
>>>> >> Why? Because your framework demands it be so?
>>>> >
>>>> > No, that is the way I have built applications since the 1980s when I
>>>> > was
>>>> > working for a software house. The other developers found it easier to
>>>> > write and maintain programs which had a single screen and function
>>>> > instead of programs which had multiple screens/functions. And the users
>>>> > liked it that way as well.
>>>> >
>>>>
>>>> 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. And it IS possible to satisfy
multiple programmers. But then you've never worked on anything even
slightly complex, so you have no idea.
>>>> >>>> Security can easily be handled via a function call,
>>>> >>>
>>>> >>> I have worked with such complications in the past, and I know from
>>>> >>> experience that having a single script which can perform several
>>>> >>> functions,
>>>> >>> then trying to make one or more of those functions inaccessible to
>>>> >>> the
>>>> >>> current user is a maintenance nightmare. You have to avoid calling
>>>> >>> code that
>>>> >>> shouldn't be executed, and avoid not calling code which should be
>>>> >>> executed.
>>>> >>> It is far simpler to split each function into a smaller dedicated
>>>> >>> script and
>>>> >>> have the framework decide whether to call the script or not than it
>>>> >>> is to
>>>> >>> call a script and afterwards decide that it's not actually allowed.
>>>> >>>
>>>> >>
>>>> >> I have too. It works great. And much easier to maintain than similar
>>>> >> code in multiple scripts.
>>>> >
>>>> > I disagree. Having a script that performs a single function is easier
>>>> > to
>>>> > maintain than a script which can perform multiple functions as you have
>>>> > to keep track of what function the user has selected, then ensure that
>>>> > the right code does get executed while the wrong code does not. I and
>>>> > my
>>>> > fellow developers have been through that scenario, which is why we all
>>>> > prefer the single-function-per-script approach.
>>>> >
>>>>
>>>> Yup, you have a script which displays a single form. What can be
>>>> simpler?
>>>>
>>>> And if you and your developers thing it's easier to spread what is
>>>> effectively duplicate code across several scripts, then I see why you
>>>> need a framework.
>>>
>>> The amount of code which is actually generated by my framework is
>>> incredibly small. Common code is not duplicated, it is shared, either by
>>> being in a function or inherited from an abstract class. In my
>>> implementation of MVC I have reusable controllers, reusable views, and
>>> each table class can be used by several controller/view combinations.
>>>
>>
>> And how do you set/get individual fields? That is a large part of the
>> code with mine generates. Other code is for forms generation and handling
>> (two functions - one for generating all forms and one for processing data
>> returned by $_GET/$_POST, WITH validation).
>
> 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.
>> 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?
>>>> >>>> and the only differences between LIST and UPDATE are whether the
>>>> >>>> fields
>>>> >>>> are read/write or not. Again, easily handled in one script. And
>>>> >>>> all of
>>>> >>>> this can easily be handled in a class, for instance.
>>>> >>>
>>>> >>> I have been developing database applications in different languages
>>>> >>> for
>>>> >>> several decades, and in my experience having a single LIST screen
>>>> >>> which can
>>>> >>> also be used for ADD, ENQUIRE, UPDATE, DELETE and SEARCH only works
>>>> >>> for
>>>> >>> simple applications such as PhpMyAdmin. For real world applications
>>>> >>> used in
>>>> >>> the enterprise they require something more sophisticated, which is
>>>> >>> where
>>>> >>> your approach falls short.
>>>> >>>
>>>> >>
>>>> >> I have also. I first learned how to do it when working with CICS at
>>>> >> IBM, then later graduated to C++ programming. Classes do wonders in
>>>> >> such an environment.
>>>> >
>>>> > Classes by themselves are not a solution, it is the code within them,
>>>> > and how they are strung together, which provides the solution. I'm
>>>> > afraid that an application which has a single screen to perform the
>>>> > list, add, enquire, update, delete and search functions is no better
>>>> > than a general-purpose admin like phpMyadmin, and that is simply not
>>>> > good enough for sophisticated users with sophisticated needs.
>>>> >
>>>>
>>>> Yup, which all comes back to good design.
>>>>
>>>> But I didn't say it was a single screen which does all that - I said
>>>> it was a single script which performs it. And the more sophisticated
>>>> the application becomes, the more important it is to not duplicate
>>>> your code in multiple scripts (and the less appropriate a framework
>>>> becomes).
>>>
>>> Lots of small scripts instead of a few large scripts does not equate to
>>> duplicated code, at least not in my universe.
>>>
>>>> I'm not against frameworks in general. They are ok for simple
>>>> applications.
>>>
>>> And even more ok for larger applications.
>>>
>>
>> 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.
>> 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?
>> 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.
>>>> >>>> I know you believe frameworks are slicker than snot on a doorknob,
>>>> >>>> but
>>>> >>>> they are not at all the only way to go. And in many cases there are
>>>> >>>> better ways.
>>>> >>>>
>>>> >>>>>>> If you have ever built an application which has evolved over the
>>>> >>>>>>> years
>>>> >>>>>>> to
>>>> >>>>>>> incorporate over 200 databases tables, 350 relationships and 1700
>>>> >>>>>>> screens
>>>> >>>>>>> then you would appreciate such a time-saving feature. If, on the
>>>> >>>>>>> other
>>>> >>>>>>> hand,
>>>> >>>>>>> you have never built an application which has more than a dozen
>>>> >>>>>>> dinky
>>>> >>>>>>> little
>>>> >>>>>>> tables then you are unlikely to be using any sort of framework at
>>>> >>>>>>> all.
>>>> >>>>>>>
>>>> >>>>>>
>>>> >>>>>> A medium sized application. But you don't need a framework. A good
>>>> >>>>>> design does wonders.
>>>> >>>>>
>>>> >>>>> It may be medium to you, but not to many others. A proper framework
>>>> >>>>> will
>>>> >>>>> provide a lot, if not all, of the "plumbing" code for you, so the
>>>> >>>>> idea
>>>> >>>>> of
>>>> >>>>> writing an application with several hundreds of tables and
>>>> >>>>> thousands of
>>>> >>>>> transactions WITHOUT a framework where you have to write all that
>>>> >>>>> plumbing
>>>> >>>>> code yourself just strikes me as dumb. An efficient programmer
>>>> >>>>> aims to
>>>> >>>>> spend
>>>> >>>>> less time on the "plumbing" code and more time on the "payload".
>>>> >>>>>
>>>> >>>>
>>>> >>>> Yes, there are a lot of people here who don't know what a large
>>>> >>>> application is. But then if the application has "evolved" like you
>>>> >>>> indicate, I suspect it is highly inefficient in how it works. Such
>>>> >>>> is
>>>> >>>> what happens when things "evolve" instead of being properly
>>>> >>>> redesigned
>>>> >>>> when necessary. Frameworks encourage such "evolution".
>>>> >>>>
>>>> >>>> But I wouldn't even think of using a framework for something like
>>>> >>>> that. I
>>>> >>>> would use OO techniques. With the right stuff in your personal
>>>> >>>> libraries,
>>>> >>>> a lot of the work is already done.
>>>> >>>
>>>> >>> OO techniques on their own are insufficient. You can't get away from
>>>> >>> having
>>>> >>> to write enormous amounts of "plumbing" code if you don't use a
>>>> >>> framework.
>>>> >>> Using libraries is not much of a time saver as you still have to
>>>> >>> write the
>>>> >>> code to call the library functions. A framework is more than a
>>>> >>> collection of
>>>> >>> libraries as it also provides a series of runnable tools which help
>>>> >>> generate
>>>> >>> user transactions. Radicore is such a framework as you can start with
>>>> >>> nothing more than a database schema, and using the data dictionary
>>>> >>> you can
>>>> >>> generate the classes and transaction scripts to view and maintain a
>>>> >>> table in
>>>> >>> minutes without having to write a line of PHP, HTML or SQL. Can you
>>>> >>> do that
>>>> >>> with your libraries?
>>>> >>>
>>>> >>
>>>> >> They are in many cased much better than frameworks. There isn't that
>>>> >> much "plumbing" code. And you still have to write the code to fit into
>>>> >> the framework.
>>>> >
>>>> > 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.
>>>> >> The biggest problem with frameworks when the needs fall outside of the
>>>> >> frameworks capabilities - and quite frankly, most of the programming I
>>>> >> do is that way. But then there is that tendency to make the problem
>>>> >> fit the framework - instead of the solution fitting the problem.
>>>> >
>>>> > I write database applications, and I created the Radicore framework to
>>>> > help me build such applications, and it works much better than anything
>>>> > else I have seen. I can build these applications much faster than I
>>>> > could in the 1980s when using COBOL, and faster than I could in the
>>>> > 1990s when using UNIFACE. It removes a lot of the grunt work by
>>>> > providing as much of the plumbing as possible, which leaves me more
>>>> > time
>>>> > to spend on the payload, the code which delivers value to the customer.
>>>> >
>>>>
>>>> Ah, now I see why you think Radicore is slicker than snot on a
>>>> doorknob. But then creators always think their (whatever) is the best
>>>> thing in the world and applicable to every situation in the universe.
>>>>
>>>> I can build PHP code a lot faster than I could COBOL in the 70's or
>>>> FORTRAN in the 60's. But I can say the same for C++, also.
>>>>
>>>> >> As for generating all that code - my libraries do a lot of it. But no,
>>>> >> I can't do it without writing any code, and neither can you. How do
>>>> >> you validate your input, for instance? Or control the layout?
>>>> >
>>>> > Basic validation, such as dealing with NOT NULL fields, or checking
>>>> > that
>>>> > date fields contain dates and numeric fields contain numbers, etc, is
>>>> > all performed automatically by the framework. I don't have to write any
>>>> > code at all to perform basic data validation. Screen layouts are
>>>> > controlled by a simple screen structure script which is generated
>>>> > automatically when the transaction is generated from a pattern. It is
>>>> > very easy to modify this script to move fields around, or drop them
>>>> > from
>>>> > the screen altogether.
>>>> >
>>>>
>>>> Sure, those are easy. I don't have to do that either with my
>>>> libraries. But *I* control the screen layout, according to what the
>>>> customer wants. I don't let a framework tell the customer what the
>>>> layout will be.
>>>
>>> You obviously haven't learnt to read yet. I said that my framework
>>> generates a default screen structure file which is used as a starting
>>> point. You can then customise this to your heart's content.
>>>
>>
>> Ah, but you said you could do that without writing any code. Now your
>> back-pedaling quite quickly.
>
> 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.
>
See above.
>>>> But one again are you saying you can do all that without writing any
>>>> code?
>>>>
>>>> >> For instance, I have one commercial product I'm working on right now
>>>> >> where the User table had a bunch of fields. Not all fields will be
>>>> >> needed by all users. Which fields are used are found in a second
>>>> >> table. Can your framework display and validate fields from the first
>>>> >> table based on rows in the second table? Without writing a single line
>>>> >> of PHP code?
>>>> >
>>>> > Yes. As well as having a database table which allows access to
>>>> > individual transactions, I have another database table which modifies
>>>> > the access to individual fields within a transaction. A normally
>>>> > modifiable field can be changed to read-only, or it can be removed from
>>>> > the screen (for that user) altogether.
>>>> >
>>>>
>>>> And you can do that without writing any code? And make it dynamic, so
>>>> when the user changes the contents of the second table the screen
>>>> changes also?
>>>>
>>>> > All security, whether it's access to individual transactions, or fields
>>>> > within transactions, is controlled by updating database tables using
>>>> > the
>>>> > screens provided, not by writing code.
>>>> >
>>>>
>>>> And how do you guarantee the entered data are valid?
>>>
>>> User data is initially validate by the framework, as I have already
>>> explained. Additional validation rules have to be defined by te
>>> programmer with code.
>>>
>>
>> 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. And what about existing passwords which
don't follow the new rules?
But again, more bloatware.
>>>> 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.
>> --
>> ==================
>> Remove the "x" from my email address
>> Jerry Stuckle
>> JDS Computer Training Corp.
>> jstucklex(at)attglobal(dot)net
>> ==================
>
>
--
==================
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
]