[Modus-devs] Some general Modus comments to start with

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

Well, there is a lot of ground to cover from your last few posts.  I'm
sending this one first to lay out some generic responses.  I'll respond to
inline questions by replying to the individual posts.

Let me say first that Modus is not intended to be a general application
framework -- it is focused on building web-delivered applications written in
CFML.  Given the intended use of Modus, the "80% case" is the target for the
code base (particularly for 1.0).  I think we can spend some good energy
discussing the places where clean separation of "data", "logic" and
"display" could be better, but I come from a viewpoint that speed of
development for a CFML developer wanting to build web pages that deliver
dynamic content is a key consideration that, in my mind, may trump certain
design philosophies.  But, I remain very open to suggestions on ways to
improve what we've got so far (it's only 0.2.x after all).  For me, the
modustest app in its current form is a living proof-of-concept that
demonstrates how very very easy it is for someone to very rapidly create a
very simple CMS.  As we move towards linked contentObjects and other
"advanced" features I don't want to lose such ease of use for the base case.

A lot of the discussion in the last 24 hours has started to revolve around
what a field is and what the descriptor should know.  These are both good
discussions to have, particularly as we prepare to rewrite the guts to use
the XML descriptor.

A general premise of Modus is that a "field" should know how to render
itself into a form widget.  This makes it very easy to create basic Add/Edit
forms with a minimal amount of coding (a classic PITA task for a web app).
The renderSimpleForm() is just a convenience that I think will move out of
the baseContentObject and into some kind of contentObjectUtility.  I am not
looking to create a totally abstract form generation engine, but I do think
that if I know a field is going to require a file upload, that I can just
call renderFormField() on that field and get the proper HTML input.  I don't
think this is mutually exclusive with delivery to Flash or WML or
whatever -- in those environments you wouldn't use the renderFormField()
methods of the fields, but since 80% (or more) of Modus apps will be
delivered via HTML I think it's a "good thing" for fields to be able to help
out the developer.

I could be much more easily convinced to do away with "label" and
renderSimpleForm() than I could to not have fields know how to create the
proper HTML form widget for themselves.  But, it sure is handy to have that
label ;)

On the subject of embedded vs. reference for linked components: I tend to
lean towards references.  Although embedded can have some advantages, it
will likely prove to be overly cumbersome from a performance standpoint (and
from a code sanity standpoint).

I'll try to cover the rest in the messages . . .

Thanks for engaging in this discussion!

 - n