| Re: Dynamic form generation [message #177721 is a reply to message #177716] |
Tue, 17 April 2012 08:18   |
Tony Marston
Messages: 57
Registered: November 2010
Karma:
|
Member |
|
|
"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.
>>> 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.
>>> 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.
>>> 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.
> 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.
> 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.
> 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.
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.
--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]