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

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

Well, I've managed to eat up sizable portions of my Friday talking Modus.
Which is fun.

My answers inline below . . .


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

Yes, definitely not just persistence.  It's about doing away with a lot of
mundane, repetitive tasks while offering a tight metaphor for coding.  I
think, as Jeremy has demonstrated, that Modus 1.0 could be used in the
context of Fusebox -- though eventually Modus (or a related project) may
grow to supersede much of what Fusebox is about.


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

True, true.  Though, personally performance tends to be a lower priority for
me because I rarely work on sites that have huge volume.  I think the target
for Modus is more likely the "typical CF site" where you never have a user
base in the millions (or even in the hundreds of thousands).  That is, it
wouldn't be a big deal in my mind if Modus 1.0 was not an "Enterprise Class"
system if it is useful to a large swath of CF folks.


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

Well, depends on what "fast" means.  Is less than 500 ms for a page that
both displays all the press releases and has everything necessary to edit
one (including having retrieved one from persistence to get it ready to
edit)?  For most applications that is acceptable performance.  Is it great?
No.  Could it be improved.  Probably.  But, as long as a typical Modus page
can stay in that range it's probably good enough (for 1.0 anyway).  We can
go back later when the developer API is well baked to optimize (or people
can build different caching and/or persistence mechanisms to speed things
up).  What I'm saying is that for 1.0 I think the primary objective should
be tight metaphor, rapid development and "acceptable" performance.


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

Agreed.  Embedded components are a no go for the foreseeable future.
"Linked" components (the "foreign key" reference model) are the way to go
for Modus.


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

Yes, I think that's reasonable.


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

Oh, yes.  I never intended for pressRelease.renderHTML(), only
pressRelease.getField("image").renderHTML() -- which just outputs:

<img src="http://[serverPath]/imageName.gif">

That is probably the most extreme example of a field knowing about HTML.

I absolutely agree that a contentObject should not even try to render itself
in its entirety.  I could see building some kind of display handler
mechanism where I might do pressRelease.renderDisplay("handerName"), but
that's not a priority for me.  The renderHTML() on most field types just
outputs the raw value -- I just think from an interface standpoint it's
cleaner to use toHTML() rather than getValue() -- allows for things like a
field type that is a "webImage" (one of the built in field types in 0.2) or
perhaps a "colorPicker" (which might use a SWF or some other "rich" client).

renderSimpleForm() is a different animal -- I guess I see that as something
used only for the most basic of basic objects or for prototyping.  I would
imagine that in a product app that renderSimpleForm() would rarely be used.
But, it's convenient enough that I built it in (works fabulously for
something super simple like the current modustest application).  Understand
that I build a lot of "little" sites that do some fairly basic CMS for small
businesses, hobby sites, personal sites, etc. -- Modus was started more to
help me slam those out than to build something like macromedia.com (though,
it's nice to have that perspective on the team to keep me from making
blunders and, frankly, for my own education about OO
frameworks/methods/patterns).



>
> > 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! :)

Yes, label is "friendly name" -- localization is a great issue.  I guess it
seems like someone who is building a multi-lingual site will need to find an
alternative way if they want some generic form generation to happen (or
submit changes to Modus that allow it ;).  This is a great example of the
different perspective -- working on macromedia.com you are forced to think
about things like localization, whereas I have not dealt with it very much.
I think it's safe to say that the "label" mechanism in the descriptor is not
a requirement and not something that a lot of "advanced" sites would use
(like most advanced CF developers would never touch CFINSERT/CFUPDATE and
most would not use client variables, but those are handy features of the
language for a newbie -- I see renderSimpleForm() in the same category).