modus-devs — List for Modus Developers

RE: [Modus-devs] XML descriptor of linked contentObjects, WAS: Collections of content objects and performance

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

> Right, but how many 'collection' implementations will you have? Just
> one in general I suspect so the type="..." could be implicit and the
> whole field spec would be simpler. Just a thought.

Yes, I suppose that's true.  Though, that would mean internally when a
contentObject was initializing it would have to do some kind of meta data
discovery to determine if the field it was using was, in fact, another
content object -- that seems messier than just having the end user say to
use the contentObjectCollection field type and pass in what kind of content
object.  I can easily imagine someone extending contentObjectCollection to
do some specialized things, so it would be good to have the descriptor
semantics reflect this -- and that is consistent with how all other fields
work (except that most field types don't need extra configuration
information).

I guess that until I (or someone else?) actually sits down to implement the
contentObjectCollection field type this is all academic, but given the way
Modus works today that is what makes the most sense to me.  Agreed?

 - n

RE: [Modus-devs] HTML SELECT, WAS: Collections of content objects and performance

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

> On Friday, Nov 1, 2002, at 08:58 US/Pacific, Nathan Dintenfass wrote:
> > Yes, what does an HTML SELECT have to do with a data descriptor??  OK,
> > I
> > should have said that the categoryPicker manifests itself as a form
> > widget
> > with an HTML SELECT.
>
> OK, I can see where you're going with this now (and you know I don't
> like that approach :)

Yes, and that is why I would like to know some alternatives ;)

More generally, do you think a field should not be responsible for rendering
itself into a form widget?  If not, can you give an example of what that
might look like for the developer (in terms of configuration and page level
coding)?



> > I have mixed feelings about it.  When I had to build the
> > categoryPicker it
> > felt "dirty" -- I didn't want to have go build new field types every
> > time I
> > just wanted a discrete list to choose from for a given field.
>
> Hmm... I guess the conceptual question is: do you want the persistent
> implementation to be 0, 1, .., n (i.e., an integer) or a string?
>
> I can see how the 'simplicity' argument leans toward definition inline
> as a string.

Well, in this case it would be a string.  If I had been referencing a linked
object type then I would have expected the persister to store the id of that
instance (as per Jeremy's "key" suggestion, with the default being the id).

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

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

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

> I had not envisioned a
> field as merely a data type, but as a functional unit that can do 
> useful
> things for someone who wants to make HTML-based applications in CFML.

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.

> This brings up another question I have: should fields be rule aware?  
> That
> is, should a "yesno" field automatically run a boolean rule check, or 
> should
> the developer need to specify that separately in the descriptor?

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

"I can smell your brains!"
-- Mittens the Kitten : http://www.matazone.co.uk/theotherside.html

Re: [Modus-devs] XML descriptor of linked contentObjects, WAS: Collections of content objects and performance

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

On Friday, Nov 1, 2002, at 11:01 US/Pacific, Nathan Dintenfass wrote:
> Well, the idea was to push the machinery for dealing with 
> contentObject as
> field into a specific field implementation rather than have it in
> baseField -- the idea being that is a special case.

Right, but how many 'collection' implementations will you have? Just 
one in general I suspect so the type="..." could be implicit and the 
whole field spec would be simpler. Just a thought.

"SOAP is not so much a means of transmitting data
  but a mechanism for calling COM objects over the Web."
-- not Microsoft (surprisingly!)

Re: [Modus-devs] XML descriptor of linked contentObjects

[Jeremy F. <jfi...@ma...>]

So did you ever send something only to realize moments later how stupid =
you were?

Of course the post won't know it's a field. It seems the way you =
suggested with the objectType works:

  <field name=3D"posts"
    label=3D"Posts"
    type=3D"org.bacfug.modus.fields.objectcollection"
    multiple=3D"yes">
   <objectType name=3D"modustest.contentObjects.post"/>
  </field> =20

I don't know what I was thinking.
  ----- Original Message -----=20
  From: Nathan Dintenfass=20
  To: mod...@li...=20
  Sent: Friday, November 01, 2002 2:18 PM
  Subject: RE: [Modus-devs] XML descriptor of linked contentObjects


  So, myorg.post would have to extend the objectCollection field?=20

  If that is what you are suggesting, I'm not sure I like that a =
contentObject needs to know that it could end up as a field.  That's why =
I am thinking that making a field type objectCollection and then passing =
the configuration data from the descriptor of the contentObject type =
that wants to make the link makes sense.

  Or, am I missing your point?

    -----Original Message-----
    From: mod...@li... =
[mailto:mod...@li...]On Behalf Of Jeremy =
Firsenbaum
    Sent: Friday, November 01, 2002 11:08 AM
    To: mod...@li...
    Subject: Re: [Modus-devs] XML descriptor of linked contentObjects, =
WAS: Collections of content objects and performance


      While we're on this topic, I am not sure how Jeremy's suggestion =
would work:


        <field name=3D"posts"
          label=3D"Posts"
          type=3D"org.bacfug.modus.fields.objectcollection"
          key=3D"postid"/>

      I do not understand how it knows it is dealing with the post =
component.
      Please explain.

    Sorry for the confusion. I got hung up on the objectcollection idea. =
It's supposed to read type=3D"myorg.post" which extends =
"org.bacfug.modus.fields.objectcollection" in it's descriptor. Hope that =
clarifies things.

    -Jeremy

RE: [Modus-devs] XML descriptor of linked contentObjects

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

So, myorg.post would have to extend the objectCollection field?

If that is what you are suggesting, I'm not sure I like that a contentObject
needs to know that it could end up as a field.  That's why I am thinking
that making a field type objectCollection and then passing the configuration
data from the descriptor of the contentObject type that wants to make the
link makes sense.

Or, am I missing your point?

  -----Original Message-----
  From: mod...@li...
[mailto:mod...@li...]On Behalf Of Jeremy
Firsenbaum
  Sent: Friday, November 01, 2002 11:08 AM
  To: mod...@li...
  Subject: Re: [Modus-devs] XML descriptor of linked contentObjects, WAS:
Collections of content objects and performance


    While we're on this topic, I am not sure how Jeremy's suggestion would
work:


      <field name="posts"
        label="Posts"
        type="org.bacfug.modus.fields.objectcollection"
        key="postid"/>

    I do not understand how it knows it is dealing with the post component.
    Please explain.

  Sorry for the confusion. I got hung up on the objectcollection idea. It's
supposed to read type="myorg.post" which extends
"org.bacfug.modus.fields.objectcollection" in it's descriptor. Hope that
clarifies things.

  -Jeremy

Re: [Modus-devs] XML descriptor of linked contentObjects, WAS: Collections of content objects and performance

[Jeremy F. <jfi...@ma...>]

  While we're on this topic, I am not sure how Jeremy's suggestion would =
work:


    <field name=3D"posts"
      label=3D"Posts"
      type=3D"org.bacfug.modus.fields.objectcollection"
      key=3D"postid"/>

  I do not understand how it knows it is dealing with the post =
component.
  Please explain.

Sorry for the confusion. I got hung up on the objectcollection idea. =
It's supposed to read type=3D"myorg.post" which extends =
"org.bacfug.modus.fields.objectcollection" in it's descriptor. Hope that =
clarifies things.

-Jeremy

RE: [Modus-devs] XML descriptor of linked contentObjects, WAS: Collections of content objects and performance

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

> Ah, OK. But then isn't type="org.bacfug.modus.fields.contentObject"
> somewhat redundant? Do you *need* the ability to specify multiple
> container types? Do you even *want* that ability? It seems to me that
> it's just an implementation detail - the important part is the
> underlying type, not the collection type itself.
>

Well, the idea was to push the machinery for dealing with contentObject as
field into a specific field implementation rather than have it in
baseField -- the idea being that is a special case.  Given the current
paradigm of "fields" I need some way to tell it what kind of field it should
be, and I am not sure it would make any sense to just point at a
contentObjectType -- since the internals expect something that extends the
baseField.

Make sense?

 - n

Re: [Modus-devs] HTML SELECT, WAS: Collections of content objects and performance

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

On Friday, Nov 1, 2002, at 08:58 US/Pacific, Nathan Dintenfass wrote:
> Yes, what does an HTML SELECT have to do with a data descriptor??  OK, 
> I
> should have said that the categoryPicker manifests itself as a form 
> widget
> with an HTML SELECT.

OK, I can see where you're going with this now (and you know I don't 
like that approach :)

> <field name="type"
> label="Type"
> type="org.bacfug.modus.fields.picklist">
>    <options>
>       <option value="normal" label="Normal"/>
>       <option value="special" label="Special"/>
>    </options>
> </field>
>
> I have mixed feelings about it.  When I had to build the 
> categoryPicker it
> felt "dirty" -- I didn't want to have go build new field types every 
> time I
> just wanted a discrete list to choose from for a given field.

Hmm... I guess the conceptual question is: do you want the persistent 
implementation to be 0, 1, .., n (i.e., an integer) or a string?

I can see how the 'simplicity' argument leans toward definition inline 
as a string.

I don't really like it but I can't think of a better way off-hand... 
I'll give it some more thought.

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

Re: [Modus-devs] XML descriptor of linked contentObjects, WAS: Collections of content objects and performance

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

On Friday, Nov 1, 2002, at 09:32 US/Pacific, Nathan Dintenfass wrote:
> ----------------------------------------------------------------------- 
> -
>   <field name="related"
>     label="Related Press Releases"
>     type="org.bacfug.modus.fields.contentObject"
>     multiple="yes">
>    <objectType name="modustest.contentObjects.pressRelease"/>
>   </field>
> ----------------------------------------------------------------------- 
> ----
>
> Well, this is not flushed out yet, but the idea is that there is a  
> field
> type called "contentObject" that knows how to deal with having a
> contentObject (or a collection of them) as its value.  That way, the
> baseContentObject nor the baseField needs to have the machinery for  
> dealing
> with this case -- we can build a field type that knows about this,  
> since it
> is seems like a special case.  Thus, I say this is a fieldType of
> org.bacfug.modus.fields.contentObject (which probably should go back to
> being contentObjectCollection) and I then need to tell it which
> contentObject type it will hold.

Ah, OK. But then isn't type="org.bacfug.modus.fields.contentObject"  
somewhat redundant? Do you *need* the ability to specify multiple  
container types? Do you even *want* that ability? It seems to me that  
it's just an implementation detail - the important part is the  
underlying type, not the collection type itself.

"I have always wished that my computer would be as easy to use as my  
telephone.
  My wish has come true - I no longer know how to use my telephone."
-- Bjarne Stroustrup

[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

[Modus-devs] Some general Modus comments to start with [read this first]

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

[Hmm, somehow this never showed up in my mail.  Sorry if it's a repost for
some of you]

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

[Modus-devs] getAll(), WAS: Collections of content objects and performance

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

I too struggled a bit with getAll() as part of the baseContentObject -- this
too is a good candidate to be moved to the contentObjectUtility (which
probably has only static methods and can live in memory).  One issue is that
you need to know which persister a given contentObject type is using before
you can get all of them.  The only clean way I can think of to do this is to
have an instance of that type.  I considered building some kind of
"registry" of contentObject types, but that sounds very messy.  Still, from
an API viewpoint I agree it would be cleaner for getAll() to live outside of
the baseContentObject.




-------------------------
Sean and Jeremy:
    I would do the latter, put the handle attribute in the collection
description. Which brings me to a nagging issue I have with OO in general -
objects returning collections of themselves. Is it really "clean" to have a
getAll() method in basecontentobject? I see this kind of thing all of the
time in Java programs and it always makes me cringe.


  Yup. Legal but *ugly*...

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

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

Sean asks:
>
> >   <field
> >    name="featured"
> >    label="Featured?"
> >    type="org.bacfug.modus.fields.yesno"
> >    default="no">
>
> Ugh! We have a perfectly good boolean type in the language and you want
> to invent a new one? :)

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.  The yesno
field, in this case, knows how to render itself into a yes/no radio button.
This is why there is probably a more philosophical discussion to be had
before moving forward -- what is a "field" in Modus?  I had not envisioned a
field as merely a data type, but as a functional unit that can do useful
things for someone who wants to make HTML-based applications in CFML.

This brings up another question I have: should fields be rule aware?  That
is, should a "yesno" field automatically run a boolean rule check, or should
the developer need to specify that separately in the descriptor?

 - n

[Modus-devs] XML descriptor of linked contentObjects, WAS: Collections of content objects and performance

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

Sean asked . . .
------------------------------------------------------------------------
  <field name="related"
    label="Related Press Releases"
    type="org.bacfug.modus.fields.contentObject"
    multiple="yes">
   <objectType name="modustest.contentObjects.pressRelease"/>
  </field>

So this is an array of modustest.contentObjects.pressRelease? What has
"type=..." got to do with this? What value has the type got to do with
anything?

I'm still confused by this XML example - it seems very strange to have,
effectively, two types specifies for this field... Nathan, can you
elaborate?
---------------------------------------------------------------------------

Well, this is not flushed out yet, but the idea is that there is a field
type called "contentObject" that knows how to deal with having a
contentObject (or a collection of them) as its value.  That way, the
baseContentObject nor the baseField needs to have the machinery for dealing
with this case -- we can build a field type that knows about this, since it
is seems like a special case.  Thus, I say this is a fieldType of
org.bacfug.modus.fields.contentObject (which probably should go back to
being contentObjectCollection) and I then need to tell it which
contentObject type it will hold.  I do like Jeremy's suggestion of having a
"key" and I would probably add a "label" (so that I could know how to render
the SELECT field for choosing which of the press releases were related ;)

This also brings up the more generic question of how to best manage having
"custom" configuration within the descriptor, but that's another thread
altogether.

While we're on this topic, I am not sure how Jeremy's suggestion would work:


  <field name="posts"
    label="Posts"
    type="org.bacfug.modus.fields.objectcollection"
    key="postid"/>

I do not understand how it knows it is dealing with the post component.
Please explain.

 - n

[Modus-devs] HTML SELECT, WAS: Collections of content objects and performance

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

Sean asks: What has an HTML SELECT got to do with data descriptors????

Yes, what does an HTML SELECT have to do with a data descriptor??  OK, I
should have said that the categoryPicker manifests itself as a form widget
with an HTML SELECT.  The original issue was that I wanted a way to have a
field that needed to be chosen from a discrete list of values.  The way to
get this done in the "real world" was with a SELECT field.  The CFPROPERTY
tags did not allow me to specify much about what those options might be, so
I did an experiment by creating my own "custom" field type called
categoryPicker.  categoryPicker.cfc uses the formFieldFactory to make a
SELECT with some options in it.  This really goes to the more philosophical
discussion about how much a contentObject (or, really, a field) should know
about how to render itself (see the generic discussion post that precedes
this message).

Sean says he shudders when he sees:

<field name="type"
label="Type"
type="org.bacfug.modus.fields.picklist">
   <options>
      <option value="normal" label="Normal"/>
      <option value="special" label="Special"/>
   </options>
</field>

I have mixed feelings about it.  When I had to build the categoryPicker it
felt "dirty" -- I didn't want to have go build new field types every time I
just wanted a discrete list to choose from for a given field.  So, when
moving to XML it seemed to offer a good deal of freedom to do something
simple like have a generic "picklist" field that can be fed some options.  I
am very open to suggestions on to accomplish this in a better way.  It did
not seem sufficient to me to just say that "type" in this case is just a
"string" and then make the developer worry about what the options for "type"
might be -- I don't see how that has much advantage over the "old way" with
an RDBMS and a bunch of templates for rendering forms.  I also don't think
that every time I want to pick from a list of things that it should be a
list of other contentObjects -- seems like overkill for a "type" or a
"category" or a "state" to have to be a contentObject, when all it needs to
be is one (or more) from a list of defined options (though
org.bacfug.modus.fields.usastate is probably a candidate to be a built-in
field given how often it's used).

Re: [Modus-devs] Collections of content objects and performance

[Jeremy F. <jfi...@ma...>]

I've offered this as an alternative to the objectType:

<contentType label=3D"Thread">
 <fields>
  <field name=3D"thread"
    label=3D"Thread"
    type=3D"org.bacfug.modus.fields.text">
   <rules>
    <rule type=3D"org.bacfug.modus.validation.full"/>
    <rule type=3D"org.bacfug.modus.validation.maxlength" value=3D"100"/>
   </rules>=20
  </field>
 <field name=3D"postid"
    type=3D"org.bacfug.modus.fields.hidden"/>
  <field name=3D"posts"
    label=3D"Posts"
    type=3D"org.bacfug.modus.fields.objectcollection"
    key=3D"postid"/>=20
 </fields>
</contentType>

  "Just to clarify: the init() call would not instantiate/retrieve the =
subobjects, that would only happen on the call to getObjects(), yes?"

Right, no instantiation until the item is required. Of course this is =
not a problem if only one post is needed, but if all of the posts are =
requested (getObjects('posts')) then things become crunchingly slow. =
However, this would be the case whether the posts were wrapped inside of =
the thread component or if they were requested externally with the =
post.getAll() method which I've already said irks me.

In either case, CFMX just doesn't seem up to the task of instantiating =
dozens of objects on a single request. In my crude performance tests it =
took roughly 50ms per object to retrieve a collection of threads from =
the cache.
  ----- Original Message -----=20
  From: Sean A Corfield=20
  To: mod...@li...=20
  Sent: Friday, November 01, 2002 10:26 AM
  Subject: Re: [Modus-devs] Collections of content objects and =
performance


  On Friday, Nov 1, 2002, at 06:48 US/Pacific, Jeremy Firsenbaum wrote:

    Sean - I've jumped into this thing in midstream, so I'm wondering =
what you're referring to when you say "our system."


  Oh, sorry. Macromedia. Well, my team at Macromedia. We prototyped a =
persistence mechanism that was pretty similar to what Modus tries to do =
(and was what Nathan was referring to in one of his earlier messages =
when he named me).


    I appreciate your concern with the descriptor mixing display and =
data attributes. It seems like a few of the items in the descriptor =
right now are there just to make renderSimpleForm() work and may be =
superfluous to the actual object model.=20


  Yes, I'm not convinced that it is possible to build a generic =
form-rendering engine (without a huge amount of machinery) and I feel - =
very strongly as y'all might gather! - that this sort of display =
machinery doesn't belong in a content model. What if your display is =
Flash? WML? XML?


    As for clustering the XML descriptor for a group of objects I would =
say no. I think it's legitimate to reference other objects within a =
descriptor ( a forum has threads), but the descriptor should continue to =
describe one content type. It seems cleaner and much more manageable to =
have separate forum, thread, and message descriptors than to wrap them =
all together in one mega/meta-file.


  OK, just wanted to get a sense of the folks here on that one.


    <cfset forum =3D =
createObject("component","path.to.forum").init(attributes.forumID)>
    <cfset threads =3D forum.getObjects('threads')>


  Just to clarify: the init() call would not instantiate/retrieve the =
subobjects, that would only happen on the call to getObjects(), yes? =
That was part of the problem we had with performance: if the first =
init() call created the entire object (i.e., including nested =
subobjects) it became very slow very quickly.


      <field name=3D"related"
        label=3D"Related Press Releases"
        type=3D"org.bacfug.modus.fields.contentObject"
        multiple=3D"yes">
       <objectType name=3D"modustest.contentObjects.pressRelease"/>
      </field> =20

    So this is an array of modustest.contentObjects.pressRelease? What =
has "type=3D..." got to do with this? What value has the type got to do =
with anything?


  I'm still confused by this XML example - it seems very strange to =
have, effectively, two types specifies for this field... Nathan, can you =
elaborate?

Re: [Modus-devs] Collections of content objects and performance

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

On Friday, Nov 1, 2002, at 06:48 US/Pacific, Jeremy Firsenbaum wrote:
> Sean - I've jumped into this thing in midstream, so I'm wondering what=20=

> you're referring to when you say "our system."

Oh, sorry. Macromedia. Well, my team at Macromedia. We prototyped a=20
persistence mechanism that was pretty similar to what Modus tries to do=20=

(and was what Nathan was referring to in one of his earlier messages=20
when he named me).

> I appreciate your concern with the descriptor mixing display=A0and =
data=20
> attributes.=A0It seems like a=A0few of the items in the descriptor =
right=20
> now are there just to make renderSimpleForm() work and may be=20
> superfluous to the actual object model.=A0

Yes, I'm not convinced that it is possible to build a generic=20
form-rendering engine (without a huge amount of machinery) and I feel -=20=

very strongly as y'all might gather! - that this sort of display=20
machinery doesn't belong in a content model. What if your display is=20
Flash? WML? XML?

> As for=A0clustering the XML descriptor for a group of objects I would=20=

> say no. I think it's legitimate to reference other objects within a=20
> descriptor ( a forum has threads), but the descriptor should continue=20=

> to describe one content type. It seems cleaner and much more=20
> manageable to have separate forum, thread, and message descriptors=20
> than to wrap them all together in one mega/meta-file.

OK, just wanted to get a sense of the folks here on that one.

> <cfset forum =3D=20
> createObject("component","path.to.forum").init(attributes.forumID)>
> <cfset threads =3D forum.getObjects('threads')>

Just to clarify: the init() call would not instantiate/retrieve the=20
subobjects, that would only happen on the call to getObjects(), yes?=20
That was part of the problem we had with performance: if the first=20
init() call created the entire object (i.e., including nested=20
subobjects) it became very slow very quickly.

> =A0=A0<field=A0name=3D"related"
> =A0=A0=A0=A0label=3D"Related Press Releases"
> =A0=A0=A0=A0type=3D"org.bacfug.modus.fields.contentObject"
> =A0=A0=A0=A0multiple=3D"yes">
> =A0=A0=A0<objectType name=3D"modustest.contentObjects.pressRelease"/>
> =A0=A0</field>=A0=A0
>
> So this is an array of modustest.contentObjects.pressRelease? What has=20=

> "type=3D..." got to do with this? What value has the type got to do =
with=20
> anything?

I'm still confused by this XML example - it seems very strange to have,=20=

effectively, two types specifies for this field... Nathan, can you=20
elaborate?

"SOAP is not so much a means of transmitting data
  but a mechanism for calling COM objects over the Web."
-- not Microsoft (surprisingly!)

Re: [Modus-devs] Collections of content objects and performance

[Jeremy F. <jfi...@ma...>]

Sean - I've jumped into this thing in midstream, so I'm wondering what =
you're referring to when you say "our system."=20

I appreciate your concern with the descriptor mixing display and data =
attributes. It seems like a few of the items in the descriptor right now =
are there just to make renderSimpleForm() work and may be superfluous to =
the actual object model. I know that Nathan has been pushing Modus to be =
a complete system, with form generation built, but the system may be =
losing some of its "lightness" in doing so. I look forward to seeing his =
reply.

As for clustering the XML descriptor for a group of objects I would say =
no. I think it's legitimate to reference other objects within a =
descriptor ( a forum has threads), but the descriptor should continue to =
describe one content type. It seems cleaner and much more manageable to =
have separate forum, thread, and message descriptors than to wrap them =
all together in one mega/meta-file.
And you have to consider embedded vs referenced. The latter acts like a =
foreign key relationship, the former gets you into the same 'mess' as =
trying to implement arrays natively (as does trying to implement nested =
structs natively as far as I can see).I've been playing with nesting =
content objects a lot and the method that seems to offer the best =
balance of efficiency and flexibility is a mix of embedded and =
referenced objects. The init method basically constructs a map of all =
nested objects or subcomponents (the reference part), and a call to =
retrieve a subcomponent will then instantiate it. What this affords a =
developer using the modus API is to do something like:

<cfset forum =3D =
createObject("component","path.to.forum").init(attributes.forumID)>
<cfset threads =3D forum.getObjects('threads')>

I've got an example that I'll email you off list.

-Jeremy

  ----- Original Message -----=20
  From: Sean A Corfield=20
  To: mod...@li...=20
  Sent: Friday, November 01, 2002 12:24 AM
  Subject: Re: [Modus-devs] Collections of content objects and =
performance


  On Thursday, Oct 31, 2002, at 14:52 US/Pacific, Nathan Dintenfass =
wrote:

    We are very much on the same track.  I agree that "join" is the =
wrong word in the OO context.  Collection is much better.  In fact, they =
probably should even be arrays, they should be structs (in CF terms).


  See my other comment about complex fields. That's where our system =
began to break down. Part of the issue seems to be around how 'holistic' =
you want the XML descriptor to be: in a forum application, for examples, =
we have multiple 'forum' objects, each 'forum' has zero or more 'thread' =
objects, each 'thread' has zero or more 'message' objects, a message =
object has zero or more replies which are themselves 'message' objects. =
Should there be a separate description for each object, or is one =
descriptor sufficient (or desirable) for that cluster of objects.


      <field name=3D"related"
        label=3D"Related Press Releases"
        type=3D"org.bacfug.modus.fields.contentObject"
        multiple=3D"yes">
       <objectType name=3D"modustest.contentObjects.pressRelease"/>
      </field> =20


  So this is an array of modustest.contentObjects.pressRelease? What has =
"type=3D..." got to do with this? What value has the type got to do with =
anything?


  "I can smell your brains!"
  -- Mittens the Kitten : http://www.matazone.co.uk/theotherside.html

Re: [Modus-devs] Collections of content objects and performance

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

On Thursday, Oct 31, 2002, at 15:51 US/Pacific, Nathan Dintenfass wrote:
> Actually, it just creates a SELECT box of categories -- no child=20
> objects at all.=A0 That was my first attempt at having fields drawn =
from=20
> discrete options.

What has an HTML SELECT got to do with data descriptors????

"I have always wished that my computer would be as easy to use as my=20
telephone.
  My wish has come true - I no longer know how to use my telephone."
-- Bjarne Stroustrup

Re: [Modus-devs] Collections of content objects and performance

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

On Thursday, Oct 31, 2002, at 15:38 US/Pacific, Jeremy Firsenbaum wrote:
> I'd like to think that if it's not a simple value then it should be an=20=

> object

Agreed!

> I would do the latter, put the handle attribute in the collection=20
> description. Which brings me to a nagging issue I have with OO in=20
> general - objects returning=A0collections of themselves.=A0Is it =
really=20
> "clean" to have a getAll() method in basecontentobject? I see this=20
> kind of thing all of the time in Java programs and it always makes me=20=

> cringe.

Yup. Legal but *ugly*...



"I have always wished that my computer would be as easy to use as my=20
telephone.
  My wish has come true - I no longer know how to use my telephone."
-- Bjarne Stroustrup

Re: [Modus-devs] Collections of content objects and performance

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

On Thursday, Oct 31, 2002, at 14:52 US/Pacific, Nathan Dintenfass wrote:
> We are very much on the same track.=A0 I agree that "join" is the =
wrong=20
> word in the OO context.=A0 Collection is much better.=A0 In fact, they=20=

> probably should=A0even be arrays,=A0they should be structs (in CF =
terms).

See my other comment about complex fields. That's where our system=20
began to break down. Part of the issue seems to be around how=20
'holistic' you want the XML descriptor to be: in a forum application,=20
for examples, we have multiple 'forum' objects, each 'forum' has zero=20
or more 'thread' objects, each 'thread' has zero or more 'message'=20
objects, a message object has zero or more replies which are themselves=20=

'message' objects. Should there be a separate description for each=20
object, or is one descriptor sufficient (or desirable) for that cluster=20=

of objects.

> =A0=A0<field=A0name=3D"related"
> =A0=A0=A0=A0label=3D"Related Press Releases"
> =A0=A0=A0=A0type=3D"org.bacfug.modus.fields.contentObject"
> =A0=A0=A0=A0multiple=3D"yes">
> =A0=A0=A0<objectType name=3D"modustest.contentObjects.pressRelease"/>
> =A0=A0</field>=A0=A0

So this is an array of modustest.contentObjects.pressRelease? What has=20=

"type=3D..." got to do with this? What value has the type got to do with=20=

anything?


"I can smell your brains!"
-- Mittens the Kitten : http://www.matazone.co.uk/theotherside.html

Re: [Modus-devs] Collections of content objects and performance

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

Now I'm back from DevCon I can plough through this (heavy) thread and 
give some input...

On Tuesday, Oct 29, 2002, at 17:45 US/Pacific, Nathan Dintenfass wrote:
> One idea I floated was that
> there should be a way for a field to be an array of values, 
> independent of
> whether it's contentObjects or not.

Yes, what we tried was isArray="true" as an optional attribute for any 
field. That allowed any field to be multi-valued (and we had to store 
both parent key and 'index' in a side table so that we could 
reconstruct the array in order - in our database). Whilst this was very 
flexible, it was very CPU-intensive and it was too easy for folks to 
create very inefficient content objects. Right now, I have no solid 
thoughts on a better way to approach this in general but I can't help 
wonder how often we really need to represent an array (as an atomic 
content object) since databases don't provide such a thing natively.

> Then, have a way for the value of the
> field to be another contentObject.

And you have to consider embedded vs referenced. The latter acts like a 
foreign key relationship, the former gets you into the same 'mess' as 
trying to implement arrays natively (as does trying to implement nested 
structs natively as far as I can see).

> For instance, renderSimpleForm() on a contentObject -- could get ugly.

Not just ugly, but actually intractable in the general case: the 
presentation of a complex object cannot be managed by the framework in 
any generic manner without a lot of additional 'hints' in the 
descriptor.

And I'm not even convinced that the data descriptor is the right place 
for some of this - I saw the <options/> definition and shuddered: it 
seems to mix presentation logic with data specification.

> Right now I'm thinking that moving towards the XML descriptor is the 
> first
> step to any of this.   I am increasingly convinced that the CFPROPERTY 
> route
> is too limiting from an programming standpoint and apparently is also
> potentially a big problem when it comes to performance (per an off-line
> discussion with Sean Corfield).

Yup. cfproperty is really nice and simple but walking the metadata can 
get slow real quick when you have complex objects and/or inheritance. 
It also adds a construction and memory overhead to every single object 
instance (unless you move to the per-type instance model with 
persistent objects represented not by components but by structs). 
Separating the specification of the data from the component that 
represents it helps a lot as long as you don't then burden any 
component instances with lots of methods (even inherited) and/or 
metadata.

However, you also need to focus on what the XML represents. Is it a 
complete display recipe for the data? I would suggest not.

> <contentObjectType label="Press Release">
>  <fields>

Are you planning to add other children? <fields/> seems redundant here.

>   <field
>    name="title"
>    label="Title"

What would 'label' be used for? How would this fit with localization 
issues? This is part of the display / data separation I talk about 
above.

>   <field
>    name="featured"
>    label="Featured?"
>    type="org.bacfug.modus.fields.yesno"
>    default="no">

Ugh! We have a perfectly good boolean type in the language and you want 
to invent a new one? :)

> First question: does that make sense?

Yes, overall.

> <contentObject label="Forum">
> <field
> name="threads"
> isArray="yes"
> type="myApp.threadComponent">
> </contentObject>

Ah, 'isArray', just like we tried...

> Or, it might look like:
>
> <contentObject label="Forum">
> <childObjects>
>     <objectType type="myApp.threadComponent">
> </childObjects>
> </contentObject>

This doesn't make sense to me. Could you explain how you envisage such 
a parent-child working?

> Or, perhaps:
>
> <contentObject label="Forum">
> <joins>
>     <join type="one2many" objectType="myApp.threadComponent">
> </joins>
> </contentObject>

That seems like a real mixed-metaphor to me... don't like that I'm 
afraid.

"I can smell your brains!"
-- Mittens the Kitten : http://www.matazone.co.uk/theotherside.html

Re: [Modus-devs] Collections of content objects and performance

[Jeremy F. <jfi...@ma...>]

"we need to come up with a consistent scheme for how to pass "extra" =
information in the descriptor"

I'd say go with the way you're doing it now - attributes of objects are =
written as xml attributes and items that are distinct objects are nodes, =
such as field and rule. If it makes a difference, attributes are =
accessed through the xmlAttributes structure and nodes are accessed =
through the xmlChildren array in CFMX.
  ----- Original Message -----=20
  From: Nathan Dintenfass=20
  To: mod...@li...=20
  Sent: Thursday, October 31, 2002 6:51 PM
  Subject: RE: [Modus-devs] Collections of content objects and =
performance


  Actually, it just creates a SELECT box of categories -- no child =
objects at all.  That was my first attempt at having fields drawn from =
discrete options.  With CFPROPERTY there was not good way to tell it =
what the options were, so I built it as a one-off field just to see how =
onerous that would be.  It is OK, but not great.  You may notice the =
field right after that, called "type" -- I have not yet implemented =
that, but the new XML freedom should allow for that kind of thing.  Also =
notice that the second rule of title has an extra attribute called =
maxlength (we need to come up with a consistent scheme for how to pass =
"extra" information in the descriptor.  Should it always be a node, or =
use attributes?


    -----Original Message-----
    From: mod...@li... =
[mailto:mod...@li...]On Behalf Of Jeremy =
Firsenbaum
    Sent: Thursday, October 31, 2002 3:45 PM
    To: mod...@li...
    Subject: Re: [Modus-devs] Collections of content objects and =
performance


    One question about the XML below: how does categoryPicker work? Does =
it define a single field with a collection of category objects, or maybe =
two fields, one with a list of category names (the handles you =
mentioned) and another with a list of categoryids?
      ----- Original Message -----=20
      From: Nathan Dintenfass=20
      To: mod...@li...=20
      Sent: Thursday, October 31, 2002 5:52 PM
      Subject: RE: [Modus-devs] Collections of content objects and =
performance


      We are very much on the same track.  I agree that "join" is the =
wrong word in the OO context.  Collection is much better.  In fact, they =
probably should even be arrays, they should be structs (in CF terms).  I =
extended the XML config I put together after my last post to toy with =
what it might look like.  I came up with:

      <contentObjectType label=3D"Press Release">
       <fields>
        <field
         name=3D"title"
         label=3D"Title"
         type=3D"org.bacfug.modus.fields.text">
         <rules>
          <rule
           name=3D"org.bacfug.modus.validation.full" />
          <rule
           name=3D"org.bacfug.modus.validation.maxlength"=20
           maxlength=3D"50"/>=20
         </rules>
        </field>
        <field
         name=3D"body"
         label=3D"Main Body"
         type=3D"org.bacfug.modus.fields.longText"/>
        <field
         name=3D"image"
         label=3D"Photo"
         type=3D"org.bacfug.modus.fields.webImage"/>
        <field
         name=3D"featured"
         label=3D"Featured?"=20
         type=3D"org.bacfug.modus.fields.yesno"=20
         default=3D"no">
         <rules>
          <rule
           name=3D"org.bacfug.modus.validation.boolean"/>
         </rules>
        </field>
        <field
         name=3D"category"
         label=3D"Category"
         type=3D"modustest.contentObjects.categoryPicker"/>
        <field  name=3D"type"
          label=3D"type"
          type=3D"org.bacfug.modus.fields.picklist">
         <options>
          <option value=3D"normal" label=3D"Normal"/>
          <option value=3D"special" label=3D"Special"/>
         </options> =20
        </field>
        <field name=3D"related"
          label=3D"Related Press Releases"
          type=3D"org.bacfug.modus.fields.contentObject"
          multiple=3D"yes">
         <objectType name=3D"modustest.contentObjects.pressRelease"/>
        </field> =20
       </fields>
      <contentObjectType>/modus-devs

RE: [Modus-devs] Collections of content objects and performance

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

Actually, it just creates a SELECT box of categories -- no child objects at
all.  That was my first attempt at having fields drawn from discrete
options.  With CFPROPERTY there was not good way to tell it what the options
were, so I built it as a one-off field just to see how onerous that would
be.  It is OK, but not great.  You may notice the field right after that,
called "type" -- I have not yet implemented that, but the new XML freedom
should allow for that kind of thing.  Also notice that the second rule of
title has an extra attribute called maxlength (we need to come up with a
consistent scheme for how to pass "extra" information in the descriptor.
Should it always be a node, or use attributes?


  -----Original Message-----
  From: mod...@li...
[mailto:mod...@li...]On Behalf Of Jeremy
Firsenbaum
  Sent: Thursday, October 31, 2002 3:45 PM
  To: mod...@li...
  Subject: Re: [Modus-devs] Collections of content objects and performance


  One question about the XML below: how does categoryPicker work? Does it
define a single field with a collection of category objects, or maybe two
fields, one with a list of category names (the handles you mentioned) and
another with a list of categoryids?
    ----- Original Message -----
    From: Nathan Dintenfass
    To: mod...@li...
    Sent: Thursday, October 31, 2002 5:52 PM
    Subject: RE: [Modus-devs] Collections of content objects and performance


    We are very much on the same track.  I agree that "join" is the wrong
word in the OO context.  Collection is much better.  In fact, they probably
should even be arrays, they should be structs (in CF terms).  I extended the
XML config I put together after my last post to toy with what it might look
like.  I came up with:

    <contentObjectType label="Press Release">
     <fields>
      <field
       name="title"
       label="Title"
       type="org.bacfug.modus.fields.text">
       <rules>
        <rule
         name="org.bacfug.modus.validation.full" />
        <rule
         name="org.bacfug.modus.validation.maxlength"
         maxlength="50"/>
       </rules>
      </field>
      <field
       name="body"
       label="Main Body"
       type="org.bacfug.modus.fields.longText"/>
      <field
       name="image"
       label="Photo"
       type="org.bacfug.modus.fields.webImage"/>
      <field
       name="featured"
       label="Featured?"
       type="org.bacfug.modus.fields.yesno"
       default="no">
       <rules>
        <rule
         name="org.bacfug.modus.validation.boolean"/>
       </rules>
      </field>
      <field
       name="category"
       label="Category"
       type="modustest.contentObjects.categoryPicker"/>
      <field  name="type"
        label="type"
        type="org.bacfug.modus.fields.picklist">
       <options>
        <option value="normal" label="Normal"/>
        <option value="special" label="Special"/>
       </options>
      </field>
      <field name="related"
        label="Related Press Releases"
        type="org.bacfug.modus.fields.contentObject"
        multiple="yes">
       <objectType name="modustest.contentObjects.pressRelease"/>
      </field>
     </fields>
    <contentObjectType>/modus-devs