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