Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.php > #5552
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Newsgroups | comp.lang.php |
| Subject | Re: Dynamic form generation |
| Date | 2012-04-17 06:07 -0400 |
| Organization | A noiseless patient Spider |
| Message-ID | <jmjfdk$vmp$1@dont-email.me> (permalink) |
| References | (8 earlier) <cNQir.139600$bA2.91936@fx20.am4> <jmh3iq$f4m$1@dont-email.me> <oMVir.126156$8i.19574@fx19.am4> <jmhd8m$6jr$1@dont-email.me> <7I9jr.212617$sE1.169738@fx22.am4> |
On 4/17/2012 4:18 AM, Tony Marston wrote: > "Jerry Stuckle" wrote in message news:jmhd8m$6jr$1@dont-email.me... >> >> On 4/16/2012 10:11 AM, Tony Marston wrote: >>> "Jerry Stuckle"<jstucklex@attglobal.net> wrote in message >>> news:jmh3iq$f4m$1@dont-email.me... >>>> On 4/16/2012 4:31 AM, Tony Marston wrote: >>>>> "Jerry Stuckle"<jstucklex@attglobal.net> wrote in message >>>>> news:jmeg9a$5pt$2@dont-email.me... >>>>>> On 4/15/2012 3:33 AM, Tony Marston wrote: >>>>>>> "Peter H. Coffin"<hellsop@ninehells.com> wrote in message >>>>>>> news:slrnjoj0b7.4ci.hellsop@nibelheim.ninehells.com... >>>>>>>> On Fri, 13 Apr 2012 09:59:52 +0100, Tony Marston wrote: >>>>>>>>> >>>>>>>>> "Charles"<cchamb2@gmail.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? >>>> 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. >>>> 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). I'm not against frameworks in general. They are ok for simple 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. >> 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. 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? Yes, I know you think your toy is the answer to life, the universe and everything. But it isn't. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
Back to comp.lang.php | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Dynamic form generation Charles <cchamb2@gmail.com> - 2012-04-11 20:48 -0700
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-12 00:03 -0400
Re: Dynamic form generation The Natural Philosopher <tnp@invalid.invalid> - 2012-04-12 05:46 +0100
Re: Dynamic form generation Michael Vilain <vilain@NOspamcop.net> - 2012-04-11 21:52 -0700
Re: Dynamic form generation Denis McMahon <denismfmcmahon@gmail.com> - 2012-04-12 12:42 +0000
Re: Dynamic form generation Charles <cchamb2@gmail.com> - 2012-04-12 20:43 -0700
Re: Dynamic form generation Michael Vilain <vilain@NOspamcop.net> - 2012-04-12 21:55 -0700
Re: Dynamic form generation Denis McMahon <denismfmcmahon@gmail.com> - 2012-04-13 13:19 +0000
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-13 09:59 +0100
Re: Dynamic form generation Denis McMahon <denismfmcmahon@gmail.com> - 2012-04-13 13:22 +0000
Re: Dynamic form generation Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-17 14:49 +0200
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-17 11:36 -0400
Re: Dynamic form generation "Tony Marston" <TonyMarston@hotmail.com> - 2012-04-18 09:33 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-18 07:59 -0400
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-19 09:56 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-19 08:29 -0400
Re: Dynamic form generation "Tony Marston" <TonyMarston@hotmail.com> - 2012-04-20 09:27 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-20 07:47 -0400
Re: Dynamic form generation "Tony Marston" <TonyMarston@hotmail.com> - 2012-04-21 12:22 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-21 10:19 -0400
Re: Dynamic form generation "Tony Marston" <TonyMarston@hotmail.com> - 2012-04-22 11:45 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-22 10:09 -0400
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-24 18:21 +0100
Re: Dynamic form generation Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-24 20:56 +0200
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-25 09:23 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-24 16:20 -0400
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-25 10:04 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-25 08:29 -0400
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-26 12:45 +0100
Re: Dynamic form generation Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-22 19:21 +0200
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-23 13:50 +0100
Re: Dynamic form generation Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-24 11:10 +0200
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-24 17:11 +0100
Re: Dynamic form generation Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-24 18:54 +0200
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-24 18:55 +0100
[OT] Was: Dynamic form generation Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-04-25 13:22 +0200
Re: [OT] Was: Dynamic form generation The Natural Philosopher <tnp@invalid.invalid> - 2012-04-25 12:46 +0100
Re: [OT] Was: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-26 12:51 +0100
Re: [OT] Was: Dynamic form generation Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-04-27 10:26 +0200
[OT] Yes-or-no questions (was: [OT] Was: Dynamic form generation) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-28 07:56 +0200
Re: Dynamic form generation "Peter H. Coffin" <hellsop@ninehells.com> - 2012-04-14 08:53 -0500
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-15 08:33 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-15 08:51 -0400
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-16 09:31 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-16 08:33 -0400
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-16 15:11 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-16 11:18 -0400
Re: Dynamic form generation "Tony Marston" <TonyMarston@hotmail.com> - 2012-04-17 09:18 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-17 06:07 -0400
Re: Dynamic form generation "Tony Marston" <TonyMarston@hotmail.com> - 2012-04-18 09:10 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-18 08:09 -0400
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-19 09:27 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-19 08:41 -0400
Re: Dynamic form generation "Tony Marston" <TonyMarston@hotmail.com> - 2012-04-20 10:10 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-20 08:09 -0400
Re: Dynamic form generation "Tony Marston" <TonyMarston@hotmail.com> - 2012-04-21 10:35 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-21 06:21 -0400
Re: Dynamic form generation "Tony Marston" <TonyMarston@hotmail.com> - 2012-04-22 10:27 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-22 10:43 -0400
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-23 15:23 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-23 12:24 -0400
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-26 17:29 +0100
Re: Dynamic form generation The Natural Philosopher <tnp@invalid.invalid> - 2012-04-23 20:37 +0100
What Jerry Stuckle thinks of PHP programmers "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-23 14:10 +0100
Re: What Jerry Stuckle thinks of PHP programmers Paul Herber <paul@pherber.com> - 2012-04-23 14:22 +0100
Re: What Jerry Stuckle thinks of PHP programmers "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-23 15:27 +0200
Re: What Jerry Stuckle thinks of PHP programmers Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-23 09:33 -0400
Re: What Jerry Stuckle thinks of PHP programmers "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-23 15:26 +0100
Re: What Jerry Stuckle thinks of PHP programmers Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-23 12:25 -0400
Re: What Jerry Stuckle thinks of PHP programmers Luuk <luuk@invalid.lan> - 2012-04-23 19:45 +0200
Re: What Jerry Stuckle thinks of PHP programmers The Natural Philosopher <tnp@invalid.invalid> - 2012-04-23 20:35 +0100
Re: What Jerry Stuckle thinks of PHP programmers Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-24 19:45 +0200
Re: What Jerry Stuckle thinks of PHP programmers "Tony Marston" <TonyMarston@hotmail.com> - 2012-04-28 08:48 +0100
Re: What Jerry Stuckle thinks of PHP programmers The Natural Philosopher <tnp@invalid.invalid> - 2012-04-28 09:23 +0100
Re: What Jerry Stuckle thinks of PHP programmers Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-28 08:37 -0400
Re: What Jerry Stuckle thinks of PHP programmers Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-28 14:46 +0200
Re: What Jerry Stuckle thinks of PHP programmers The Natural Philosopher <tnp@invalid.invalid> - 2012-04-23 20:31 +0100
Re: What Jerry Stuckle thinks of PHP programmers Ross McKay <au.org.zeta.at.rosko@invalid.invalid> - 2012-04-24 12:32 +1000
Re: What Jerry Stuckle thinks of PHP programmers Tim Streater <timstreater@greenbee.net> - 2012-04-24 19:32 +0100
Re: What Jerry Stuckle thinks of PHP programmers Ross McKay <au.org.zeta.at.rosko@invalid.invalid> - 2012-04-25 19:02 +1000
Re: What Jerry Stuckle thinks of PHP programmers The Natural Philosopher <tnp@invalid.invalid> - 2012-04-25 12:20 +0100
Re: Dynamic form generation Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-22 23:59 +0200
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-23 14:05 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-23 09:35 -0400
Re: Dynamic form generation Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-23 15:41 +0200
Re: Dynamic form generation The Natural Philosopher <tnp@invalid.invalid> - 2012-04-23 20:39 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-23 09:47 -0400
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-25 08:52 +0100
Re: Dynamic form generation Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-25 08:34 -0400
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-27 09:52 +0100
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-27 14:16 +0100
Re: Dynamic form generation Charles <cchamb2@gmail.com> - 2012-05-03 15:23 -0700
Re: Dynamic form generation "Tony Marston" <tony@NOSPAM.demon.co.uk> - 2012-04-12 10:52 +0100
Re: Dynamic form generation Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-04-13 11:39 +0200
Re: Dynamic form generation Jonathan Stein <jstein@image.dk> - 2012-04-13 15:27 +0200
csiph-web