Re: [Modus-devs] XML descriptor

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

> 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