RE: [Modus-devs] XML descriptor

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

No, it was that by having a flexible mechanism to define a content object
type you would have a great deal of flexibility -- even to the point of
defining what objectType you are using at run time.  It was an extreme
example -- I don't yet have a good reason you'd want to go to that extreme.
I'm more interested in overcoming the limitations of CFPROPERTY (lack of
complex config parameters, lack of
dynamic attribute values, etc.).

The original point of the defineDescriptor is that each object type can
decide how it is going to feed its XML to the baseContentObject.  Some might
have some XML right in the contentObject implementation.  Some might read
from a file and pass that.  Some might pull from any number of datasources
to build themselves.  I could see having a new layer in a CMS in which you
had some kind of base object type that would then get extended dynamically
at run time in order to render some specific data -- that would free a
developer to do all kinds of interesting things as far as data storage, etc.

 - n

> -----Original Message-----
> From: mod...@li...
> [mailto:mod...@li...]On Behalf Of Brad Pauly
> Sent: Wednesday, October 23, 2002 7:56 PM
> To: modus devs
> Subject: Re: [Modus-devs] XML descriptor
>
>
> 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.de
> scriptorSo
> > > > > > > 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
> >
> >
>
>
>
>
>
> -------------------------------------------------------
> 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
>