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 #177713 is a reply to message #177711] Mon, 16 April 2012 12:33 Go to previous messageGo to previous message
Jerry Stuckle is currently offline  Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
Senior Member
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. Security can easily be
handled via a function call, 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 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.

--
==================
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: Fri Nov 22 19:17:15 GMT 2024

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

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