Re: [Modus-devs] XML descriptor

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

Perhaps. I think I misunderstood what Nathan was saying at first.

I was thinking along the lines of, given one scenario, the component
returns a.xml and given another it returns b.xml. Where a.xml and b.xml
are not files, just different XML. I am not sure how this could be
useful. Maybe if there are some sort of permissions involved in an
application some fields are added when an "admin" is viewing a content
object that are not seen otherwise.

Hmm. I don't think that really works. And the template that controls the
content object could just as easily handle that. Oh well, just an idea. 

On Wed, 2002-10-23 at 20:43, Jeremy Firsenbaum wrote:
> > Out of curiosity, does a dynamic descriptor make any sense? That was
> > the first thing I thought of when I saw XML.
> 
> Nathan seemed to have a similar thought:
> 
> > > > > > 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.
> 
> I, however, can't wrap my feeble brain around a circumstance in which one
> would use a dynamically genereated contentType. Any thoughts come to mind?
> 
> 
> > > 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
> > >
> > >
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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
> 
> 