RE: [Modus-devs] YesNo field, WAS: Collections of content objects and performance

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

> On Friday, Nov 1, 2002, at 09:37 US/Pacific, Nathan Dintenfass wrote:
> > Well, once again the nature of "field" is the issue here.  The yesno
> > field
> > exists because to just say "this is a boolean" value does not seem to
> > have
> > any advantage of just defining a column in a table in a database.
>
> OK, I see where you're coming from... And I can see that yes/no is more
> familiar to CFers (although I resolutely use true/false :)

Actually, if memory serves, the yesno field uses 'true' and 'false' as the
values it persists.  The way to think about it is that rather than needing
to take the step of defining a datatype and then building the display and
form widget separately, a "field" in Modus can wrap these two together.
While this can be seen as breaking the barrier between data and logic and
display, it does work rather well in the finite universe Modus inhabits --
web-delivered applications built in CFML.  Given that MOST of the time when
you want to store some text you'll use INPUT type="text" and MOST of the
time you want a boolean you'll show the user a yes/no radio choice, etc. it
seems reasonable to just go ahead and encapsulate that for the developer.
Yes, it's breaking "the rules", but it's doing so with eyes open for (what I
hope are) good reasons.


> I guess I'm just concerned about the overhead in such 'rich' fields, as
> opposed to just trying to persist an 'object'. As long as Modus can
> still persist a simple boolean, as well as your yesno, then I'm happy.

Again, the yesno "field" just stores a "boolean" data chunk.  I just remove
the need for the developer to have to define both of them.  As always,
though, I am very open to suggestions.  Modus is a learning experience for
me more than it is an expression of what I think of as "the right way."


> I think it's reasonable to have some fields that are self-validating
> and this 'rich' yesno field seems to be a good candidate.

Ah, good.  Should it be smart enough to not run the same rule twice if the
developer DOES specify it?  I suppose so.

 - n