On Feb 16, 2016, at 2:11 PM, Lester Caine wrote:
On 16/02/16 19:36, Adam Jon Richardson wrote:
So is there something I've missed that may be worth considering
even at
this stage of things?
I'm in the minority, but I tend to craft DSL's to maintain
flexibility for
use cases such as HTML forms.
That approach is fine but I'm looking to allow clients to modify or
add
fields to existing forms and the underlying data management has to
track
any changes to the field set in addition to being able to reload the
form later to add or update details prior to it being 'locked'.
What I would do is create a basic form template that can have target
strings
that str_replace can replace with preference variables. The
preference variables
and values can be stored in a registered user preference database or
flat file.
I do exclusively flat files, but not just text files: php script files
that will not display
anything if a user requests the file by name, but can be accessed via
inclusion in
other scripts.
For the user to add or revise form elements suggests the inclusion of
elements
or even a separate form for the user to use to revise the target form.
This also
implies a significant amount of javascript on the client side. Changes
the user
makes can be written back to a user preference file. In turn this
suggests user
registration for the sake of routing form submissions to the proper
data base
or flat file record for the user. I write tons of javascript exactly
for this type of
use. Without javascript, there would seem to be an enormous amount of
back
and forth between client and server and the necessity for maintaining
state
would put a significant demand on the the server. This would requires
quite
a bit of sanitization of form input on the server side.
My habit in this regard, is to create self processing forms. In this
manner there
can be variable states of the visible html based on what is submitted
and how the
visible form is configured. Self processing php/html pages can also
respond to
get queries assigned to anchor tag href values, where the target of
the link is
the form page itself, and javascript based client/server interactions
such as
"ajax" async interactions.
In short, it looks like a significant amount of design, coding and
engineering
to me.
This may not be encouraging, but I thought I would offer some
considerations
JK
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
