RE: [Modus-devs] forms and objects

[Nathan D. <na...@ch...>]

>
> So if a user only wanted to display a few fields of a component that
> they created, they could do this by passing only those fields to the
> setFieldValues method. Then display it however they like. Am I on the
> right track?

Well, setFieldValues is really just a convenience method.  If I say:

contentObject.setFieldValues(argumentCollection=form);

That is the short-hand equivalent of doing something like:

for(key in form){
	contentObject.getField(key).setValue(form[key]);
}

The key thing to grok here is that a contentObject has a bunch of fields,
each of which is a component instance itself.  It is the field components
that deal with everything about getting/setting values as well as
validation.  The API of the baseContentObject exposes a lot of convenience
methods about fields, but the field is where the work happens.  So, a field
instance always has a value.  By default that value is an empty string
(since CF has no NULL).  When you set the value using setFieldValues() on
the content object instance or the setValue() method of the field instance
you are doing just that -- given the field a new value.  When you go to
store() a content object, it persists the values of all the fields (along
with some other instance data about the object).  So, if you create a new
contentObject instance and set the value, when you go to get the value it
will be whatever it was set to.

While I'm on the subject of setting field values, it's worth noting that
Modus deals with validation a little differently than other CF code I have
ever written.  Rather than validating a value, then setting it in the
database (or wherever), Modus prefers to have a "stateful" error status.
The act of setting the value of a field automatically validates that field.
Thus, a field ALWAYS has an error state (either it has errors, or it
doesn't).  So, you CAN set a field value to a value that is NOT valid, but
you cannot store a field with an invalid value (built into the store()
method of the baseContentObject).  But, it is up the user to decide how they
want to deal with the flow in that case.  They could use CFTHROW and build
their own handling, they could do what the sample app does right now, which
is to do a simple if statement using the hasErrors() method of the
baseContentObject (fields also have a hasErrors() method), and then just to
loop through any error messages in the content object instance to display
messages right on the screen.  Again, few assumptions are made about how an
application will get built, but the tools are there to use a number of
different techniques.

Does this help?

 - Nathan