|
From: Nathan D. <na...@ch...> - 2002-10-23 19:52:54
|
[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.
|
|
From: Brad P. <br...@ro...> - 2002-10-23 20:44:42
|
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.
|
|
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
>
>
|
|
From: Jeremy F. <jfi...@ma...> - 2002-10-24 02:01:22
|
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
|
|
From: Brad P. <br...@ro...> - 2002-10-24 02:30:34
|
Hi Jeremy,
Yes, you are making sense. Perhaps it was the wine (in my hand ;) that
confused me, but mostly I think that I just haven't had my Modus
thinking cap on in a while. I was forgetting how baseContentObject is
the thing making the calls. This makes sense to me now.
Out of curiosity, does a dynamic descriptor make any sense? That was
the first thing I thought of when I saw XML.
Brad
On Wed, 2002-10-23 at 20:01, Jeremy Firsenbaum wrote:
> 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
>
>
>
> -------------------------------------------------------
> 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
>
>
|
|
From: Jeremy F. <jfi...@ma...> - 2002-10-24 02:43:43
|
> 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
|
|
From: Brad P. <br...@ro...> - 2002-10-24 03:10:11
|
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
>
>
|
|
From: Nathan D. <na...@ch...> - 2002-10-24 03:24:01
|
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
>
|