| Re: Dynamic form generation [message #177722 is a reply to message #177721] |
Tue, 17 April 2012 10:07   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
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?
>>>> 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.
>>>> 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).
I'm not against frameworks in general. They are ok for simple applications.
>>>> 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.
>> 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.
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?
Yes, I know you think your toy is the answer to life, the universe and
everything. But it isn't.
--
==================
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
]