Re: [Modus-devs] XML descriptor

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

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