Menu
▾
▴
Re: [Modus-devs] XML descriptor
|
From: Brad P. <br...@ro...> - 2002-10-24 01:28:05
|
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
>
>
|
