FUDforum
Fast Uncompromising Discussions. FUDforum will get your users talking.
Home » Imported messages » comp.lang.php » Dynamic form generation
Show: Today's Messages :: Polls :: Message Navigator
Return to the default flat view Create a new topic Submit Reply
Re: Dynamic form generation [message #177715 is a reply to message #177713] Mon, 16 April 2012 14:11 Go to previous messageGo to previous message
Tony Marston is currently offline  Tony Marston
Messages: 57
Registered: November 2010
Karma:
Member
"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.
>>>>
>>>> Bt 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? Myabe 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.

> 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.

> 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 langages 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 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 applicaton 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 glot, 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?

--
Tony Marston

http://www.tonymarston.net
http://www.radicore.org



> --
> ==================
> Remove the "x" from my email address
> Jerry Stuckle
> JDS Computer Training Corp.
> jstucklex(at)attglobal(dot)net
> ==================

Report message to a moderator

[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Data injection problems
Next Topic: Do you want to develop PHP for the Web and make money
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Sat Nov 23 01:00:48 GMT 2024

Total time taken to generate the page: 0.04457 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.1.3.
Copyright ©2001-2023 FUDforum Bulletin Board Software