RE: [Modus-devs] forms and objects

[Brad P. <br...@ro...>]

I think I am on the same page. Let's see. A content object is a
container for a collection of field component instances along with some
other information. The field component instances take care of things
like validation and setting their values. I was wondering if a content
object could know more about what is going on (i.e. a form POST). It
probably could, but that isn't really the point. A content object is not
necessarily a form per se.

Am I getting there?

On Mon, 2002-09-09 at 19:58, Nathan Dintenfass wrote:
> 
> 
> >
> > 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
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Modus-devs mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modus-devs
> 
>