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