Re: [Modus-devs] XML descriptor

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hi Jeremy, 

Yes, you are making sense. Perhaps it was the wine (in my hand ;) that
confused me, but mostly I think that I just haven't had my Modus
thinking cap on in a while. I was forgetting how baseContentObject is
the thing making the calls. This makes sense to me now.

Out of curiosity, does a dynamic descriptor make any sense? That was 
the first thing I thought of when I saw XML.

Brad

On Wed, 2002-10-23 at 20:01, Jeremy Firsenbaum wrote:
> Hi Brad,
> 
> You still need to define where the XML is coming from in the contentType
> cfc. With the defineDescriptor method that Nathan suggested the contentType
> could construct the XML itself, or call on a helper descriptor cfc.
> 
> Examples for extending basedescriptor.cfc
> - file2xmldescriptor (this would probably just read the xml)
> - property2descriptor (this could construct the xml out of the current
> format cfproperty-style descriptor)
> - db2xmldescriptor
> A simple little web-based IDE could even be built to allow a developer to
> define contentTypes to the xml files or database.
> 
> One of these options would be the default defineDescriptor() in
> baseContentObject - maybe the cfproperty style since it doesn't require any
> external datasource.
> 
> Am I making sense typing with a scotch in my hands and the world series on?
> 
> ----- Original Message -----
> From: "Brad Pauly" <br...@ro...>
> To: "modus devs" <mod...@li...>
> Sent: Wednesday, October 23, 2002 9:14 PM
> Subject: Re: [Modus-devs] XML descriptor
> 
> 
> > Thinking about this a little more...It seems like returning XML would be
> > a good thing. I had not thought it threw completely, and setting the
> > location of a file negates the advantage of XML coming from anywhere as
> > mentioned.
> >
> > I am not sure why a contentType would need to have any of its own
> > methods though. If you had something to handle the XML in
> > baseContentObject, couldn't you just use that?
> >
> > Brad
> >
> > On Wed, 2002-10-23 at 14:30, Brad Pauly wrote:
> > > 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.
> > >
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by: Influence the future
> > > of Java(TM) technology. Join the Java Community
> > > Process(SM) (JCP(SM)) program now.
> > > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
> > >
> > > _______________________________________________
> > > Modus-devs mailing list
> > > Mod...@li...
> > > https://lists.sourceforge.net/lists/listinfo/modus-devs
> > >
> > >
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by: Influence the future
> > of Java(TM) technology. Join the Java Community
> > Process(SM) (JCP(SM)) program now.
> > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
> >
> > _______________________________________________
> > Modus-devs mailing list
> > Mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/modus-devs
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: Influence the future 
> of Java(TM) technology. Join the Java Community 
> Process(SM) (JCP(SM)) program now. 
> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
> 
> _______________________________________________
> Modus-devs mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modus-devs
> 
> 