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

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

comments follow inline...
  ----- 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>
  I had originally called it contentObjectCollection, but then I was =
toying with the idea of "multiple=3Dyes" as a different way.  The =
difference is that rather than having a baseCollection I wanted to be =
able to have any field have multiple values.  That may be too ambitious =
given the difficulty it creates for the "out-of-the-box" API.  But, it =
would be great to be able to just say that any field hold multiple =
values without having to write a textCollection, longTextCollection, =
etc.  Of course, it may be that the only time a collection is needed =
would be for other objects, rather than for "simple" values.

I'd like to think that if it's not a simple value then it should be an =
object, but I'm open to suggestions on this one. With the =
basefieldcollection component (whoops, I almost said class) methods =
would just expect to handle arrays or structures. With the =
multiple=3Dyes idea it seems like each method would need some kludgy =
conditional logic.


  I rather like the "key" notion you introduce.  I was also thinking =
that there might be a reason to have a contentObjectType have a way to =
define what it's "handle" should be -- then, for instance, in =
renderQuickForm() I would be able to just make a SELECT field with press =
releases to choose from, using the "key" field as the value of the =
OPTION tags and the "handle" of the pressRelease object as the label.  =
Though, I guess it might be nice if the key and "handle" label were both =
defined in the descriptor that actually defines the collection -- that =
would probably be cleaner.  Hmm.

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. =
Maybe it's perfectly legal, but I would rather see something like a =
pressreleaseManager return collections of press releases rather than =
giving an instance that ability. It just doesn't seem appropriate to use =
an instance's interface to gather multiple instances.

In this context, the pressreleaseManager might solve the multiple joins =
problem posed below. With two collections, articles and authors, an =
additional field (2D array) could be used as a "lookup," matching =
authors to articles. In fact, this field could have a fieldType of =
"join" or "lookup" with two "key" attributes and the persister could be =
built to automatically construct the lookup array.=20

And with the new XML parser Brad will build, this will be a snap. By the =
way, where is everybody else? DevCon is over.

  With many-to-many it might be OK to just define the relationship on =
both sides.  Take a basic example: Say, I have articles that have one or =
more authors.  I want to see which authors wrote any given article, but =
I also want to see the articles written by any given author.  In that =
case, I might define the contentObject collection in both the articles =
descriptor and the author descriptor to point at each other.  But, I'm =
not sure how pretty that is when saving.  Hmm.











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


    Nathan -

    As for the XML descriptor format I totally agree. In fact, after we =
discussed this last week I put together an example that is almost =
identical to what you've constructed. This seems to be a no-brainer and =
the parser just needs to be built.

    In terms of the array issue I keep harping on, your suggestion of a =
generic 'array' field type got me thinking. What we're really talking =
about here are collections (to use a java term). The "join" terminology =
seems to come from the relational database world, and, please correct me =
if I'm wrong, doesn't really fit into an OO context.=20

    What if we extend basefield with a basecollection component. A few =
accessor methods to basecollection are added, or maybe override =
basefield, to enable access to multiple items, be they simple or complex =
values. Then any type of collection can be constructed: the =
contentObject array, an array of string values, maybe even structures. =
Most of the basefield methods work 'out of the box' and problematic =
methods, such as renderSimpleForm(), are overriden or nullified (made to =
throw an exception perhaps). With the new XML descriptor format a 'key' =
property to the collection type allows for simple identification:

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

    It seems that this should work without having to create a =
baseFieldValue component, as you've suggested - although if you're still =
thinking about that, and it seems to offer more flexibility, let us =
know.

    I think a few more concrete examples might help flesh this thing =
out. We've got the simple press release and I've offered a few examples =
of 'parent is composed of child' type relationships. Maybe someone has a =
scenario in which the relationship is not one of composition, such as =
the thread containing posts. I'd be curious to see what a many-to-many =
relationship would look like in object terms. Are there situations in =
which this collection field type won't work?

    -Jeremy