Re: [Modus-devs] XML descriptor

[Brad P. <br...@ro...>]

Sounds like a good idea. A quick thought that popped into my head at
first glance. What about a setDescriptorFile method in
baseContentObject?

<cfcomponent extends="org.bacfug.modus.baseContentObject">
    <cfscript>
	this.setDescriptorFile("/some/path/myComponent.xml");
    </cfscript>    
</cfcomponent>

Hmm. Is this the same as your #2 example? I guess it is a bit
convoluted. However, I think it would be nice to have the XML separate
from the CFC.

Fully less than two cents =)

Brad


On Wed, 2002-10-23 at 13:54, Nathan Dintenfass wrote:
> [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.