>
> However, I'm a bit confused about how you are going to provide any sort of
> protection from someone editing the form information and changing the fields
> and editing any other data within the database. In other words, the keys are
> tied to the database column id numbers. Therefore, it may be an issue if
> someone can modify those values and submit alternative data. Could you
> please expand on your ideas on this area?
>
I am not proposing direct query-data to database (yet, anyway), so there
is still room for permission checking. The proposal is less grand than
that. I just want to have a standard method for assigning form field
names that should work in most cases. Let's say you want to edit an
attribute which has a name and a boolean deleted flag. You might have
attribute_id=1 (hidden)
name="description" (text)
deleted=false (checkbox)
You then create an action that looks for those specific keys and updates
the db. Now let's say the ui people would like to be able to edit many
attributes at once, you have to rewrite the action to handle inputs
like:
attribute_id1=1
name1="description"
deleted1=false
attribute_id2=5
name2="platform"
deleted2=true
...
The format I propose is similar to the second in that it can handle
multiple objects of the same class.
My form
att=1,5,... (multiple hidden fields)
att1name="short desc"
att5name="hardware"
att1del=true
...
Earlier my thoughts were that it would be best to include the id in each
property field name. This eliminates the need for the hidden fields
giving the id's. However, this led me down the path of parsing every
key. So I went back to requiring the extra (hidden) field to declare
the id.
So my proposal breaks down to something like:
1. Standardize input keys to cid[oid]property, where the delimiters are
not needed.
2. System inputs are specified in one location in xml.
3. helper classes are generated from the xml that can be used by
templates and actions/business objects to process inputs.
It is still possible to write a push type application using these
classes, so they are not necessarily part of a PULL specification. I
just think it will make it easier to broaden an Action's scope (with the
help of some session objects) so that it is not tied so much to a
specific form/wizard layout.
John McNally
John
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
