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

[Sean A C. <se...@co...>]

On Friday, Nov 1, 2002, at 08:46 US/Pacific, Nathan Dintenfass wrote:
> 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).

OK, but it sounds like it's intended to be "more general" than 'just' a 
persistence mechanism which is part of what I'm really trying to get a 
handle on.

> 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.

Agreed. And performance is probably a higher goal than 'sweet design 
under the hood'. Take Fusebox as an example.

> 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.

Agreed, but it's not very fast, I gather :)

> As we move towards linked contentObjects and other
> "advanced" features I don't want to lose such ease of use for the base 
> case.

Agreed. I'm actually trying to ensure that we don't try to build in 
features that make Modus complicated to use or make it terribly slow to 
run. I would avoid embedded components for those very reasons.

> 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.

Agreed. Can I put in a little vote for making the presentation 
specifications optional? And having the renderXxx() method(s) throw an 
exception if an attempt is made to render an object for which no 
specification is given...

> The renderSimpleForm() is just a convenience that I think will move 
> out of
> the baseContentObject and into some kind of contentObjectUtility.

I think a field can render itself but I'm not sold on the idea of a 
whole object rendering itself as HTML...

> I can just
> call renderFormField() on that field and get the proper HTML input.

Yes, I think that's reasonable (given my caveat about optional 
presentation specs).

> 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 ;)

I think 'friendly name' is a good concept but it doesn't lend itself to 
localization so I'd be slightly wary of label=. I'm pretty solidly 
against renderSimpleForm() but I can't argue very convincingly against 
renderFormField() (at the moment! :)

> 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).

Agreed. I'd be perfectly happy to not support embedded subcomponents - 
it certainly didn't help us much (it actually caused us more problems 
than it solved). We need to be careful about the array issue for 
similar reasons. Simple enough for the audience without allowing them 
to hang themselves on poor performance.

"Conform! Consume! Obey!"
-- Mr Snaffleburger : http://www.matazone.co.uk/theotherside.html