|
From: Nathan D. <na...@ch...> - 2002-10-23 19:52:54
|
[Hey, modus-devs, I've been having a backchannel discussion with list member
Jeremy Firsenbaum, but I am now moving the thread onto the list. We're
talking about moving away from CFPROPERTY as the method to define the
contentObject type and moving towards an XML descriptor . . . . ]
Something like that, though you should not need to param instance since that
is paramed in the baseContentObject (and you would not want to directly set
any instance vars like that ;).
But, it might be something like:
<cfcomponent extends="org.bacfug.modus.baseContentObject">
<cffunction name="defineDescriptor" . . .>
[SOME LOGIC TO GET or GENERATE THE XML]
<cfreturn aDescriptor>
</cffunction>
</cfcomponent>
In short, all contentObject types would, at least, need to have a
defineDescriptor() method that returns the XML (either as string or DOM).
The init() method in the baseContentObject would then call defineDescriptor
to get the XML and do its thing to make fields, rules, persister, etc.
I had hoped with the CFPROPERTY stuff to avoid needing to define any methods
at all, but given that people working with Modus need to understand
components, it is probably OK. Thoughts?
Seems there might be two "out of the box" ways the people would build
descriptors:
1) Just code the XML right into the objectType CFC -- use CFSAVECONTENT and
then return it.
2) Store a file with the descripter in org.bacfug.modus.contentObjectTypes
(or something like that) and use a method that is in baseContentObject like
readDescriptorFile() (or something like that). This might be too
convoluted, but it makes some sense that we'd provide ways to organize
file-based descriptors.
Another idea is to let you pass a descriptor to the init() method of a
baseContentObject() -- to choose the type at run-time. This might not be as
"clean", though.
As for baseDescriptor.cfc -- I'm not really sure what that would be yet.
Some kind of abstracted mechanism to have a "descriptor warehouse" or
perhaps a "descriptor factory" might be in order. Hmm.
- n
-----Original Message-----
From: Jeremy Firsenbaum [mailto:jfi...@ma...]
Sent: Wednesday, October 23, 2002 12:35 PM
To: na...@ch...
Subject: Re: Modus Forums
Hey, shouldn't we take this to the modus-devs list?
If I'm following you then the minimum that a contentobject cfc would need
might be the following:
<cfcomponent displayname="forum"
extends="org.bacfug.modus.baseContentObject">
<cfparam name="instance" default="#structNew()#">
<cfset instance.descriptorName = "org.bacfug.modus.xmldescriptor"> -
this extends basedescriptor.cfc
<cfset instance.descriptorSource = "forum_descriptor.xml">
</cfcomponent>
And in init() of basecontentobject you call loadDescriptor() which does
something like:
instance.descriptor =
createObject("component",instance.descriptorName).init(instance.descriptorSo
urce);
Or loadDescriptor() could be overriden. For example, just wrap a
loadDescriptor function definition around the existing cfproperty
descriptors in any of the example cfcs.
----- Original Message -----
From: Nathan Dintenfass
To: Jeremy Firsenbaum
Sent: Wednesday, October 23, 2002 2:26 PM
Subject: RE: Modus Forums
I think one beauty of the XML thing is that it could come in almost
anyway -- there would be a method called loadDescripter() (or something like
that) -- then you could either build that directly into the file containing
your type, or you could build a type that gets the definition from somewhere
else (the file system, over the web, from a database -- whatever). Perhaps
even some kind of descripterWarehouse would be in order -- build some kind
of machinery to for dealing with descripters, much as with basePersister for
object persistence.
- n
I completely agree - I wasn't happy with this but was trying to stay
within the implementation. Now if we could do the XML thing, adding a new
attribute to a field or a rule, like maxlength, would be trivial. When I
first saw the cfproperty definitions I immediately thought XML. The question
here, then, would be whether to contain the XML in the cfc or to have an
external descriptor. With the external file, the cfc might not even do any
work other than extending basecontentobject, but would probably still be
needed to have something to point to and instantiate.
|