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