"Diethelm Guallar, Gonzalo" wrote:
>
> John, other than the code, are there any docs
> describing what the idea for intake is?
>
The basic idea is to provide a central location for describing the
inputs to an application, which can be used generate classes to
interpret and validate those inputs. There are many other similar
approaches to this problem, it seems most of them tie the input
processing bean to a specific form. For example in JSP a form bean can
be used to encapsulate the request data. Turbine already has a similar
feature in ParameterParser that will try to match bean properties to the
request data. I like Turbine's approach here in that the bean is not so
closely tied to a specific form. It still uses reflection, which if I
can avoid, I prefer an alternate solution.
So intake creates "beans" that contain methods which can be used by
template engineers to give correct names to input fields as well as
provide any error message that might be appropriate for a field. This
class when then used in an action will find the appropriate inputs and
instantiate beans of its type encapsulating and validating the request
data.
The inputs in the xml file are grouped into logical units which can be
used to generate a class based on inputs contained in a group. The
grouping could fall towards the JSP form bean side of the spectrum or
more closely resemble the object model, or map directly to the database
tables, or I suppose even each input could be a separate class as the
only thing that requires a grouping is if one input requires that
another one have a value as well. I think the middle two options give
more flexibility in the ui, while still maintaining a reasonable api.
In order to allow form elements, inputs, to be moved easily from one
form to another, I think it makes sense to adopt a standard naming
scheme. I was originally thinking of something like
TorqueOMClass[PrimaryKey]Property
I think regardless of what form such a input came from it is pretty
certain it refers to the value stored in a specific cell of a db. A
couple minor problems with this scheme is that it can lead to rather
long names, the names are very transparent, and slightly more
problematic is the considerable amount of String parsing that might need
to occur.
Intake solves the first two in that the first and last parts of the
request name can be as short as one letter and the template and java
classes will be using easily identifiable method names
For example a template designer might put something like <input
name="$attribute.DescriptionKey" ... which could lead to a name of
"a0d". A java engineer could then have something like this in an action
ArrayList attrs = AttributeInput.getObjects(ParameterParser)
or
if the action is certain it will only be looking for one attribute input
AttributeInput attr = new AttributeInput(ParameterParser)
if (attr.isDescriptionSet() && attr.isDescriptionValid() )
{
<do something with> attr.getDescription()
}
The system allows multiple objects of the same type within one form and
by using the getObjects method a input object will be created for each
distinct id. String parsing can be eliminated by requiring the template
engineer to declare the id's on the page
#foreach ( $attribute in $attributes )
<input hidden name="$attribute.CID" value="attribute.OID">
#end
getObjects method then uses this field to determine what keys to look
for. (I am thinking of adding back in the functionality of being able
to parse the name strings in the event these fields are not present,
with a log note that the template is being inefficient.)
This is getting long winded, so let me sum up by saying this is an early
work in progress. I plan to develop the idea further within the Scarab
application, so you may want to wait a few weeks while it settles down.
But the idea is not that complicated, so if you feel it has merit jump
in and help me develop it.
John McNally
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
