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 #177716 is a reply to message #177715] Mon, 16 April 2012 15:18 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 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.
>>>> >
>>>> > 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.
>

Why? Because your framework demands it be so?

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

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

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

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.

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.

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?

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?

--
==================
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 00:58:04 GMT 2024

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

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