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

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

I think most of the code that I added to basecontentobject to support =
the objectArray type can be used for the collection implementation. In =
fact, the field type should be easy in comparison.

Correct me if I'm wrong but it looks like adding one conditional to =
addField() and getField() in basecontentobject to check for field type =
would make this work:

For example, from addField line 422:

if it's a simple value do
    thisField.setAttributes(arguments);

if it's a collection do
    //collectionAdd() was objectArrayAdd()
    collection =3D this.collectionAdd(arguments.name, =
arguments.collectionType, arguments.key)
    thisField.setCollection(collection);

I haven't tested this, but if it seems like I'm on the right track I'd =
be happy to try it out over the weekend.

Another thought is that I don't see supporting persistence for =
collections. I can't imagine needing to edit a collection as a =
collection. It would be much simpler to make the persistence calls on =
individual collection items.=20

For example:=20
    post =3D forums.getCollectionItem('posts', 3)
    //make some changes to post, then do   =20
    post.store()

How's that sound?

  ----- Original Message -----=20
  From: Nathan Dintenfass=20
  To: mod...@li...=20
  Sent: Friday, November 01, 2002 3:59 PM
  Subject: RE: [Modus-devs] XML descriptor of linked contentObjects, =
WAS: Collections of content objects and performance



  > Right, but how many 'collection' implementations will you have? Just
  > one in general I suspect so the type=3D"..." 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



  -------------------------------------------------------
  This sf.net email is sponsored by: See the NEW Palm=20
  Tungsten T handheld. Power & Color in a compact size!
  http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
  _______________________________________________
  Modus-devs mailing list
  Mod...@li...
  https://lists.sourceforge.net/lists/listinfo/modus-devs