| Re: Dynamic form generation [message #177728 is a reply to message #177725] |
Wed, 18 April 2012 12:09   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
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.
>>>> >> 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).
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.
>>>> >> 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. None of those use frameworks because the
frameworks don't work.
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.
>>>> >> 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.
>>>> 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.
>> 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.
>> 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.
--
==================
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
]