Menu
▾
▴
modus-devs — List for Modus Developers
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(72) |
Oct
(15) |
Nov
(68) |
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(9) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Jeremy F. <jfi...@ma...> - 2002-10-31 23:45:22
|
One question about the XML below: how does categoryPicker work? Does it =
define a single field with a collection of category objects, or maybe =
two fields, one with a list of category names (the handles you =
mentioned) and another with a list of categoryids?
----- Original Message -----=20
From: Nathan Dintenfass=20
To: mod...@li...=20
Sent: Thursday, October 31, 2002 5:52 PM
Subject: RE: [Modus-devs] Collections of content objects and =
performance
We are very much on the same track. I agree that "join" is the wrong =
word in the OO context. Collection is much better. In fact, they =
probably should even be arrays, they should be structs (in CF terms). I =
extended the XML config I put together after my last post to toy with =
what it might look like. I came up with:
<contentObjectType label=3D"Press Release">
<fields>
<field
name=3D"title"
label=3D"Title"
type=3D"org.bacfug.modus.fields.text">
<rules>
<rule
name=3D"org.bacfug.modus.validation.full" />
<rule
name=3D"org.bacfug.modus.validation.maxlength"=20
maxlength=3D"50"/>=20
</rules>
</field>
<field
name=3D"body"
label=3D"Main Body"
type=3D"org.bacfug.modus.fields.longText"/>
<field
name=3D"image"
label=3D"Photo"
type=3D"org.bacfug.modus.fields.webImage"/>
<field
name=3D"featured"
label=3D"Featured?"=20
type=3D"org.bacfug.modus.fields.yesno"=20
default=3D"no">
<rules>
<rule
name=3D"org.bacfug.modus.validation.boolean"/>
</rules>
</field>
<field
name=3D"category"
label=3D"Category"
type=3D"modustest.contentObjects.categoryPicker"/>
<field name=3D"type"
label=3D"type"
type=3D"org.bacfug.modus.fields.picklist">
<options>
<option value=3D"normal" label=3D"Normal"/>
<option value=3D"special" label=3D"Special"/>
</options> =20
</field>
<field name=3D"related"
label=3D"Related Press Releases"
type=3D"org.bacfug.modus.fields.contentObject"
multiple=3D"yes">
<objectType name=3D"modustest.contentObjects.pressRelease"/>
</field> =20
</fields>
<contentObjectType>/modus-devs |
|
From: Jeremy F. <jfi...@ma...> - 2002-10-31 23:39:05
|
comments follow inline...
----- Original Message -----=20
From: Nathan Dintenfass=20
To: mod...@li...=20
Sent: Thursday, October 31, 2002 5:52 PM
Subject: RE: [Modus-devs] Collections of content objects and =
performance
We are very much on the same track. I agree that "join" is the wrong =
word in the OO context. Collection is much better. In fact, they =
probably should even be arrays, they should be structs (in CF terms). I =
extended the XML config I put together after my last post to toy with =
what it might look like. I came up with:
<contentObjectType label=3D"Press Release">
<fields>
<field
name=3D"title"
label=3D"Title"
type=3D"org.bacfug.modus.fields.text">
<rules>
<rule
name=3D"org.bacfug.modus.validation.full" />
<rule
name=3D"org.bacfug.modus.validation.maxlength"=20
maxlength=3D"50"/>=20
</rules>
</field>
<field
name=3D"body"
label=3D"Main Body"
type=3D"org.bacfug.modus.fields.longText"/>
<field
name=3D"image"
label=3D"Photo"
type=3D"org.bacfug.modus.fields.webImage"/>
<field
name=3D"featured"
label=3D"Featured?"=20
type=3D"org.bacfug.modus.fields.yesno"=20
default=3D"no">
<rules>
<rule
name=3D"org.bacfug.modus.validation.boolean"/>
</rules>
</field>
<field
name=3D"category"
label=3D"Category"
type=3D"modustest.contentObjects.categoryPicker"/>
<field name=3D"type"
label=3D"type"
type=3D"org.bacfug.modus.fields.picklist">
<options>
<option value=3D"normal" label=3D"Normal"/>
<option value=3D"special" label=3D"Special"/>
</options> =20
</field>
<field name=3D"related"
label=3D"Related Press Releases"
type=3D"org.bacfug.modus.fields.contentObject"
multiple=3D"yes">
<objectType name=3D"modustest.contentObjects.pressRelease"/>
</field> =20
</fields>
<contentObjectType>
I had originally called it contentObjectCollection, but then I was =
toying with the idea of "multiple=3Dyes" as a different way. The =
difference is that rather than having a baseCollection I wanted to be =
able to have any field have multiple values. That may be too ambitious =
given the difficulty it creates for the "out-of-the-box" API. But, it =
would be great to be able to just say that any field hold multiple =
values without having to write a textCollection, longTextCollection, =
etc. Of course, it may be that the only time a collection is needed =
would be for other objects, rather than for "simple" values.
I'd like to think that if it's not a simple value then it should be an =
object, but I'm open to suggestions on this one. With the =
basefieldcollection component (whoops, I almost said class) methods =
would just expect to handle arrays or structures. With the =
multiple=3Dyes idea it seems like each method would need some kludgy =
conditional logic.
I rather like the "key" notion you introduce. I was also thinking =
that there might be a reason to have a contentObjectType have a way to =
define what it's "handle" should be -- then, for instance, in =
renderQuickForm() I would be able to just make a SELECT field with press =
releases to choose from, using the "key" field as the value of the =
OPTION tags and the "handle" of the pressRelease object as the label. =
Though, I guess it might be nice if the key and "handle" label were both =
defined in the descriptor that actually defines the collection -- that =
would probably be cleaner. Hmm.
I would do the latter, put the handle attribute in the collection =
description. Which brings me to a nagging issue I have with OO in =
general - objects returning collections of themselves. Is it really =
"clean" to have a getAll() method in basecontentobject? I see this kind =
of thing all of the time in Java programs and it always makes me cringe. =
Maybe it's perfectly legal, but I would rather see something like a =
pressreleaseManager return collections of press releases rather than =
giving an instance that ability. It just doesn't seem appropriate to use =
an instance's interface to gather multiple instances.
In this context, the pressreleaseManager might solve the multiple joins =
problem posed below. With two collections, articles and authors, an =
additional field (2D array) could be used as a "lookup," matching =
authors to articles. In fact, this field could have a fieldType of =
"join" or "lookup" with two "key" attributes and the persister could be =
built to automatically construct the lookup array.=20
And with the new XML parser Brad will build, this will be a snap. By the =
way, where is everybody else? DevCon is over.
With many-to-many it might be OK to just define the relationship on =
both sides. Take a basic example: Say, I have articles that have one or =
more authors. I want to see which authors wrote any given article, but =
I also want to see the articles written by any given author. In that =
case, I might define the contentObject collection in both the articles =
descriptor and the author descriptor to point at each other. But, I'm =
not sure how pretty that is when saving. Hmm.
-----Original Message-----
From: mod...@li... =
[mailto:mod...@li...]On Behalf Of Jeremy =
Firsenbaum
Sent: Thursday, October 31, 2002 2:26 PM
To: modus devs
Subject: Re: [Modus-devs] Collections of content objects and =
performance
Nathan -
As for the XML descriptor format I totally agree. In fact, after we =
discussed this last week I put together an example that is almost =
identical to what you've constructed. This seems to be a no-brainer and =
the parser just needs to be built.
In terms of the array issue I keep harping on, your suggestion of a =
generic 'array' field type got me thinking. What we're really talking =
about here are collections (to use a java term). The "join" terminology =
seems to come from the relational database world, and, please correct me =
if I'm wrong, doesn't really fit into an OO context.=20
What if we extend basefield with a basecollection component. A few =
accessor methods to basecollection are added, or maybe override =
basefield, to enable access to multiple items, be they simple or complex =
values. Then any type of collection can be constructed: the =
contentObject array, an array of string values, maybe even structures. =
Most of the basefield methods work 'out of the box' and problematic =
methods, such as renderSimpleForm(), are overriden or nullified (made to =
throw an exception perhaps). With the new XML descriptor format a 'key' =
property to the collection type allows for simple identification:
<contentType label=3D"Thread">
<fields>
<field name=3D"thread"
label=3D"Thread"
type=3D"org.bacfug.modus.fields.text">
<rules>
<rule type=3D"org.bacfug.modus.validation.full"/>
<rule type=3D"org.bacfug.modus.validation.maxlength" =
value=3D"100"/>
</rules>=20
</field>
<field name=3D"postid"
type=3D"org.bacfug.modus.fields.hidden"/>
<field name=3D"posts"
label=3D"Posts"
type=3D"org.bacfug.modus.fields.objectcollection"
key=3D"postid"/>=20
</fields>
</contentType>
It seems that this should work without having to create a =
baseFieldValue component, as you've suggested - although if you're still =
thinking about that, and it seems to offer more flexibility, let us =
know.
I think a few more concrete examples might help flesh this thing =
out. We've got the simple press release and I've offered a few examples =
of 'parent is composed of child' type relationships. Maybe someone has a =
scenario in which the relationship is not one of composition, such as =
the thread containing posts. I'd be curious to see what a many-to-many =
relationship would look like in object terms. Are there situations in =
which this collection field type won't work?
-Jeremy |
|
From: Nathan D. <na...@ch...> - 2002-10-31 22:51:22
|
We are very much on the same track. I agree that "join" is the wrong word
in the OO context. Collection is much better. In fact, they probably
should even be arrays, they should be structs (in CF terms). I extended the
XML config I put together after my last post to toy with what it might look
like. I came up with:
<contentObjectType label="Press Release">
<fields>
<field
name="title"
label="Title"
type="org.bacfug.modus.fields.text">
<rules>
<rule
name="org.bacfug.modus.validation.full" />
<rule
name="org.bacfug.modus.validation.maxlength"
maxlength="50"/>
</rules>
</field>
<field
name="body"
label="Main Body"
type="org.bacfug.modus.fields.longText"/>
<field
name="image"
label="Photo"
type="org.bacfug.modus.fields.webImage"/>
<field
name="featured"
label="Featured?"
type="org.bacfug.modus.fields.yesno"
default="no">
<rules>
<rule
name="org.bacfug.modus.validation.boolean"/>
</rules>
</field>
<field
name="category"
label="Category"
type="modustest.contentObjects.categoryPicker"/>
<field name="type"
label="type"
type="org.bacfug.modus.fields.picklist">
<options>
<option value="normal" label="Normal"/>
<option value="special" label="Special"/>
</options>
</field>
<field name="related"
label="Related Press Releases"
type="org.bacfug.modus.fields.contentObject"
multiple="yes">
<objectType name="modustest.contentObjects.pressRelease"/>
</field>
</fields>
<contentObjectType>
I had originally called it contentObjectCollection, but then I was toying
with the idea of "multiple=yes" as a different way. The difference is that
rather than having a baseCollection I wanted to be able to have any field
have multiple values. That may be too ambitious given the difficulty it
creates for the "out-of-the-box" API. But, it would be great to be able to
just say that any field hold multiple values without having to write a
textCollection, longTextCollection, etc. Of course, it may be that the only
time a collection is needed would be for other objects, rather than for
"simple" values.
I rather like the "key" notion you introduce. I was also thinking that
there might be a reason to have a contentObjectType have a way to define
what it's "handle" should be -- then, for instance, in renderQuickForm() I
would be able to just make a SELECT field with press releases to choose
from, using the "key" field as the value of the OPTION tags and the "handle"
of the pressRelease object as the label. Though, I guess it might be nice
if the key and "handle" label were both defined in the descriptor that
actually defines the collection -- that would probably be cleaner. Hmm.
With many-to-many it might be OK to just define the relationship on both
sides. Take a basic example: Say, I have articles that have one or more
authors. I want to see which authors wrote any given article, but I also
want to see the articles written by any given author. In that case, I might
define the contentObject collection in both the articles descriptor and the
author descriptor to point at each other. But, I'm not sure how pretty that
is when saving. Hmm.
-----Original Message-----
From: mod...@li...
[mailto:mod...@li...]On Behalf Of Jeremy
Firsenbaum
Sent: Thursday, October 31, 2002 2:26 PM
To: modus devs
Subject: Re: [Modus-devs] Collections of content objects and performance
Nathan -
As for the XML descriptor format I totally agree. In fact, after we
discussed this last week I put together an example that is almost identical
to what you've constructed. This seems to be a no-brainer and the parser
just needs to be built.
In terms of the array issue I keep harping on, your suggestion of a
generic 'array' field type got me thinking. What we're really talking about
here are collections (to use a java term). The "join" terminology seems to
come from the relational database world, and, please correct me if I'm
wrong, doesn't really fit into an OO context.
What if we extend basefield with a basecollection component. A few
accessor methods to basecollection are added, or maybe override basefield,
to enable access to multiple items, be they simple or complex values. Then
any type of collection can be constructed: the contentObject array, an array
of string values, maybe even structures. Most of the basefield methods work
'out of the box' and problematic methods, such as renderSimpleForm(), are
overriden or nullified (made to throw an exception perhaps). With the new
XML descriptor format a 'key' property to the collection type allows for
simple identification:
<contentType label="Thread">
<fields>
<field name="thread"
label="Thread"
type="org.bacfug.modus.fields.text">
<rules>
<rule type="org.bacfug.modus.validation.full"/>
<rule type="org.bacfug.modus.validation.maxlength" value="100"/>
</rules>
</field>
<field name="postid"
type="org.bacfug.modus.fields.hidden"/>
<field name="posts"
label="Posts"
type="org.bacfug.modus.fields.objectcollection"
key="postid"/>
</fields>
</contentType>
It seems that this should work without having to create a baseFieldValue
component, as you've suggested - although if you're still thinking about
that, and it seems to offer more flexibility, let us know.
I think a few more concrete examples might help flesh this thing out.
We've got the simple press release and I've offered a few examples of
'parent is composed of child' type relationships. Maybe someone has a
scenario in which the relationship is not one of composition, such as the
thread containing posts. I'd be curious to see what a many-to-many
relationship would look like in object terms. Are there situations in which
this collection field type won't work?
-Jeremy
----- Original Message -----
From: Nathan Dintenfass
To: mod...@li...
Sent: Tuesday, October 29, 2002 8:45 PM
Subject: RE: [Modus-devs] Collections of content objects and performance
So, the question before us is whether "child" objects or "joined"
objects
should be a separate kind of attribute of a contentObject from a field.
Hmm.
One question I've been thinking about is whether this is about a
parent-child relationship, in which case it makes more sense to use the
way
you've been working on (and I'd consider calling it
getChildren("threads")
or something like that. Or, is it more that a contentObject can have
some
"joins" -- and really we need a way to define a join (as being either
one-to-many or many-to-many, for instance).
Seems the first issue is whether a field should be able to be of a type
that
is actually just another contentObject. An interesting question. I
think
the answer is yes, but I can also see how it causes a lot of problems
for
the API and the cleanliness of the code base. One idea I floated was
that
there should be a way for a field to be an array of values, independent
of
whether it's contentObjects or not. Then, have a way for the value of
the
field to be another contentObject. A field would then, perhaps, have
methods like isArray() and isContentObject() -- which would help a user
who
might want to build some abstracted interfaces. Both arrays of values
and
contentObjects as values creates some nastiness in the interface,
though,
potentially. For instance, renderSimpleForm() on a contentObject --
could
get ugly.
Right now I'm thinking that moving towards the XML descriptor is the
first
step to any of this. I am increasingly convinced that the CFPROPERTY
route
is too limiting from an programming standpoint and apparently is also
potentially a big problem when it comes to performance (per an off-line
discussion with Sean Corfield).
Once we're using XML I think a lot of the other issues will be easier to
tackle. So, for instance, the pressRelease.cfc in the modustest app
might
look like:
<contentObjectType label="Press Release">
<fields>
<field
name="title"
label="Title"
type="org.bacfug.modus.fields.text">
<rules>
<rule
name="org.bacfug.modus.validation.full" />
</rules>
</field>
<field
name="body"
label="Main Body"
type="org.bacfug.modus.fields.longText"/>
<field
name="image"
label="Photo"
type="org.bacfug.modus.fields.webImage"/>
<field
name="featured"
label="Featured?"
type="org.bacfug.modus.fields.yesno"
default="no">
<rules>
<rule
name="org.bacfug.modus.validation.boolean"/>
</rules>
</field>
<field
name="category"
label="Category"
type="modustest.contentObjects.categoryPicker"/>
</fields>
<contentObjectType>
First question: does that make sense?
So, now the issue is if I were building an app with child components (or
joined components) it might look like:
<contentObject label="Forum">
<field
name="threads"
isArray="yes"
type="myApp.threadComponent">
</contentObject>
Or, it might look like:
<contentObject label="Forum">
<childObjects>
<objectType type="myApp.threadComponent">
</childObjects>
</contentObject>
Or, perhaps:
<contentObject label="Forum">
<joins>
<join type="one2many" objectType="myApp.threadComponent">
</joins>
</contentObject>
Any thoughts from the rest of you about which would be best?
In that last one, would we think that the thread than also has a join in
its
definition? Would we need a separate place where a join is defined
outside
of this config file?
Tangent: if we have fields that have arrays of values, do we want to
expose
the CF array, or would we want to create methods to traverse it (using
some
kind of iterator) to maintain the object-based API?
Hope that's enough to continue the conversation . . .
- Nathan
-----Original Message-----
From: mod...@li...
[mailto:mod...@li...]On Behalf Of Jeremy
Firsenbaum
Sent: Tuesday, October 29, 2002 2:51 PM
To: modus devs
Subject: [Modus-devs] Collections of content objects and performance
Thought this thread might be of interest to others on the list. Nathan
and I
have been talking about a couple of issues I've raised, namely,
contentObjects containing collections of other contentObjects and the
performance impact of instantiating so many objects.
Note that this reads from the bottom up:
Nathan - certainly not wed to the interface. But unless, as you suggest,
the
definition of what a field is changes I don't see a way of using
basefield
for content objects. Back to the forum example I've been using -
retrieving
a collection of threads:
The way I suggested:
<cfset forum= createObject("component","forum").init(forumID)>
<cfset threads= category.getObjectArray('threads')>
<cfloop from="1" to="#arrayLen(thread)#" index="i">
<!--- doing stuff with each thread, like: --->
#thread[i].getField('thread').getValue()#
</cfloop>
One possible way of doing what you suggest:
<cfset forum= createObject("component","forum").init(forumID)>
<cfset threads= category.getField('threads').getValue()>
<cfloop from="1" to="#arrayLen(thread)#" index="i">
#thread[i].getField('thread').getValue()#
</cfloop>
As you can see the only difference is the method call for the threads
array.
And of course this gets back to the descriptor for the content object.
In
the first case thread would have a property type of 'objectArray' or
'subcomponent' or something like that, and in the latter it has the type
'field' with a particular fieldType.
If the latter seems cleaner to you, fine. I just did it this way to
avoid
reworking basefield - sort of a proof of concept. The developer using
the
API already needs to know the 'type' for various fields. Most are simple
strings, but anything that extends basefile will certainly be handled
differently, or at least make several new methods available. So making
'contentObject' be a possible fieldType should be doable - the
basefieldValue idea is probably the way to go. Let me think about that a
bit.
As for the performance issue, it comes in precisely when you want to
instantiate a whole array of contentObjects. If I call load() on a 40
page
book object, a new instance has to be created for each of these pages.
The
only way to avoid that is to reference the cached object, which opens up
a
whole other can of worms - locking the server scope, concurrent access
to
writable data... This may be possible, but is this a route worth going
down.
Maybe others have thoughts.
- Jeremy
----- Original Message -----
From: Nathan Dintenfass
To: Jeremy Firsenbaum
Sent: Tuesday, October 29, 2002 12:27 PM
Subject: RE:
Ah, I see what you mean. Yes, get() does that, but only if you wish to
populate from another instance -- which you pass in -- that is, if you
have
an existing contentObject that you want to "load()", then you need to do
this. But, in this case you still never need to recreate a whole new
instance as you already have the one you want to load and the one you
retrieve from the cache (except on the first hit) -- but, what you are
saying is that is a performance bottleneck for you, right? Hmm.
On the "interface" I was talking about -- yes, the API exposed to the
end
user. I figured you were not wed to it. My instinct says that it would
be
better to do an overhaul of what a "field" is. First, I'd make it
possible
to have an array of values, even if not other contentObject. Then, I'd
work
on making it possible to have the value of a field be a contentObject.
Perhaps baseFieldValue.cfc would be one way to get towards that??
I totally agree that one way or another there needs to be a way to have
a
"book" and its "pages" (not to mention many-to-many relationships) and
have
"book" and "page" each be instances of a contentObject.
- Nathan
-----Original Message-----
From: Jeremy Firsenbaum [mailto:jfi...@ma...]
Sent: Monday, October 28, 2002 5:33 PM
To: na...@ch...
Subject: Re:
"By the way, the only place I am using the makeClone() is when I put
objects
into the cache, not when I take them out of the cache"
I'm sorry if I was misleading. "Cloning" takes place going in as well as
coming out, although the makeClone method is only called one way. Going
in,
makeclone calls contentObjectPopulateFromInstance, which does all of the
actually duplicating. Coming out, get() calls
contentObjectPopulateFromInstance as well:
line 41 from simplefilesystempersister.cfc:
if(instance.cache.isObjectCached(arguments.id)){
objectRetrieved = instance.cache.getObject(arguments.id);
if(structCount(arguments) GT 1)
return
contentObjectPopulateFromInstance(arguments[2],objectRetrieved);
else
return objectRetrieved;
}
I found the duplicating from a cached instance in
contentObjectPopulateFromInstance to be the bottleneck.
"I'm not sure I'm personally satisfied with the interface you are using
in
your forums app."
I'm all up for criticism - but not sure what you're referring to by
interface. Do you mean the contentObjectArray within basecontentobject,
or
the way in which the API is used externally to construct the forum.
Obviously this was just an example I was using to work with the idea of
content objects within content objects.
"Are you waiting for a signal from me as to what my alternative might
be?"
Well - kinda, yeah. I mean I would like to know if this approach to
"composition" even makes sense, or whether there's another way of doing
"parts of" relationships within modus. Many systems, content management
or
otherwise, have this kind of structure. An artifact, say a book, has
many
pages, each one of which has been scanned in. At one level, you want to
deal
with the book as a whole (when presenting a library of books), on
another
level, each one of the pages is a content object unto itself (so that
the
book is browsable). I would like to be able to load the book, for a
single
request or in session scope, and have the pages come along for the ride,
just as each thread is available within the forum content object. Does
this
even make sense within the context of what modus was and is being
designed
to do?
----- Original Message -----
From: Nathan Dintenfass
To: Jeremy Firsenbaum
Sent: Monday, October 28, 2002 7:56 PM
Subject: RE:
Ah, yes. Well, right now you are at the cutting edge of that question.
I'm
not sure I'm personally satisfied with the interface you are using in
your
forums app. Doesn't feel clean to me, but I have a hard time justifying
that feeling. Are you waiting for a signal from me as to what my
alternative might be?
By the way, the only place I am using the makeClone() is when I put
objects
into the cache, not when I take them out of the cache -- are you
experiencing serious performance problems with that? My main issue with
performance before the caching was with the getAll(). Load() is still a
bit
slower than I'd like, but I figure that will be rarely called in volume
since getAll would be generally be faster. That is an area to work on,
though.
- n
-----Original Message-----
From: Jeremy Firsenbaum [mailto:jfi...@ma...]
Sent: Monday, October 28, 2002 4:45 PM
To: na...@ch...
Subject: Re:
Sorry for being obtuse - I mean being able to declare other content
objects
as being contained within another content object: forums are composed of
threads, which are composed of posts...
----- Original Message -----
From: Nathan Dintenfass
To: Jeremy Firsenbaum
Sent: Monday, October 28, 2002 7:37 PM
Subject: RE:
When you say "composition of content object" what do you mean?
- n
-----Original Message-----
From: Jeremy Firsenbaum [mailto:jfi...@ma...]
Sent: Monday, October 28, 2002 4:33 PM
To: na...@ch...
Subject: Re:
Fair enough. Maybe it's all of the nested subcomponents that accounts
for
the slowness in cloning from the cache.
I'd love to do some more work on modus, maybe sink my teeth in the XML
descriptor thing, but I feel like I can't do much with it until I know
whether composition of content objects is feasible. This seems to be the
most important feature needed to model more complex systems. Looking
forward
to seeing what you think.
-Jeremy
----- Original Message -----
From: Nathan Dintenfass
To: Jeremy Firsenbaum
Sent: Monday, October 28, 2002 7:13 PM
Subject: RE:
Jeremy:
I hadn't yet gotten to look in depth at your changes. I agree the
clone()
method is far from optimal (as I mentioned in that posting).
My comment was based on the dramatic performance enhancement I witnessed
on
the modustest app after implementing the caching. My calls to getAll()
went
from over 400ms with a handful of "press releases" to 20ms.
- n
-----Original Message-----
From: Jeremy Firsenbaum [mailto:jfi...@ma...]
Sent: Monday, October 28, 2002 3:52 PM
To: Nathan Dintenfass
Subject:
Hey Nathan
I saw your post to CFCDev today:
"I have taken pages that were slow because they had to instantiate
dozens of
components and made them very fast by just grabbing from the cache in
the
server scope."
This got me wondering if you have looked into the performance issue with
clone() that I mentioned last week. It seems like it wouldn't make a
difference whether the subcomponents were instantiated within the
contentObject, as I had tried to do, or if this were left to the
developer
to do externally: forums = createObject (forum.cfc), loop for threads =
createObject(thread.cfc). If you need "dozens of components" the clone
technique doesn't seem to be optimal.
Were my performance numbers similar to yours (if you've had time to look
into this) or am I totally off base here?
Jeremy
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Modus-devs mailing list
Mod...@li...
https://lists.sourceforge.net/lists/listinfo/modus-devs
|
|
From: Jeremy F. <jfi...@ma...> - 2002-10-31 22:26:18
|
Nathan -
As for the XML descriptor format I totally agree. In fact, after we =
discussed this last week I put together an example that is almost =
identical to what you've constructed. This seems to be a no-brainer and =
the parser just needs to be built.
In terms of the array issue I keep harping on, your suggestion of a =
generic 'array' field type got me thinking. What we're really talking =
about here are collections (to use a java term). The "join" terminology =
seems to come from the relational database world, and, please correct me =
if I'm wrong, doesn't really fit into an OO context.=20
What if we extend basefield with a basecollection component. A few =
accessor methods to basecollection are added, or maybe override =
basefield, to enable access to multiple items, be they simple or complex =
values. Then any type of collection can be constructed: the =
contentObject array, an array of string values, maybe even structures. =
Most of the basefield methods work 'out of the box' and problematic =
methods, such as renderSimpleForm(), are overriden or nullified (made to =
throw an exception perhaps). With the new XML descriptor format a 'key' =
property to the collection type allows for simple identification:
<contentType label=3D"Thread">
<fields>
<field name=3D"thread"
label=3D"Thread"
type=3D"org.bacfug.modus.fields.text">
<rules>
<rule type=3D"org.bacfug.modus.validation.full"/>
<rule type=3D"org.bacfug.modus.validation.maxlength" value=3D"100"/>
</rules>=20
</field>
<field name=3D"postid"
type=3D"org.bacfug.modus.fields.hidden"/>
<field name=3D"posts"
label=3D"Posts"
type=3D"org.bacfug.modus.fields.objectcollection"
key=3D"postid"/>=20
</fields>
</contentType>
It seems that this should work without having to create a baseFieldValue =
component, as you've suggested - although if you're still thinking about =
that, and it seems to offer more flexibility, let us know.
I think a few more concrete examples might help flesh this thing out. =
We've got the simple press release and I've offered a few examples of =
'parent is composed of child' type relationships. Maybe someone has a =
scenario in which the relationship is not one of composition, such as =
the thread containing posts. I'd be curious to see what a many-to-many =
relationship would look like in object terms. Are there situations in =
which this collection field type won't work?
-Jeremy
----- Original Message -----=20
From: Nathan Dintenfass=20
To: mod...@li...=20
Sent: Tuesday, October 29, 2002 8:45 PM
Subject: RE: [Modus-devs] Collections of content objects and =
performance
So, the question before us is whether "child" objects or "joined" =
objects
should be a separate kind of attribute of a contentObject from a =
field.
Hmm.
One question I've been thinking about is whether this is about a
parent-child relationship, in which case it makes more sense to use =
the way
you've been working on (and I'd consider calling it =
getChildren("threads")
or something like that. Or, is it more that a contentObject can have =
some
"joins" -- and really we need a way to define a join (as being either
one-to-many or many-to-many, for instance).
Seems the first issue is whether a field should be able to be of a =
type that
is actually just another contentObject. An interesting question. I =
think
the answer is yes, but I can also see how it causes a lot of problems =
for
the API and the cleanliness of the code base. One idea I floated was =
that
there should be a way for a field to be an array of values, =
independent of
whether it's contentObjects or not. Then, have a way for the value of =
the
field to be another contentObject. A field would then, perhaps, have
methods like isArray() and isContentObject() -- which would help a =
user who
might want to build some abstracted interfaces. Both arrays of values =
and
contentObjects as values creates some nastiness in the interface, =
though,
potentially. For instance, renderSimpleForm() on a contentObject -- =
could
get ugly.
Right now I'm thinking that moving towards the XML descriptor is the =
first
step to any of this. I am increasingly convinced that the CFPROPERTY =
route
is too limiting from an programming standpoint and apparently is also
potentially a big problem when it comes to performance (per an =
off-line
discussion with Sean Corfield).
Once we're using XML I think a lot of the other issues will be easier =
to
tackle. So, for instance, the pressRelease.cfc in the modustest app =
might
look like:
<contentObjectType label=3D"Press Release">
<fields>
<field
name=3D"title"
label=3D"Title"
type=3D"org.bacfug.modus.fields.text">
<rules>
<rule
name=3D"org.bacfug.modus.validation.full" />
</rules>
</field>
<field
name=3D"body"
label=3D"Main Body"
type=3D"org.bacfug.modus.fields.longText"/>
<field
name=3D"image"
label=3D"Photo"
type=3D"org.bacfug.modus.fields.webImage"/>
<field
name=3D"featured"
label=3D"Featured?"
type=3D"org.bacfug.modus.fields.yesno"
default=3D"no">
<rules>
<rule
name=3D"org.bacfug.modus.validation.boolean"/>
</rules>
</field>
<field
name=3D"category"
label=3D"Category"
type=3D"modustest.contentObjects.categoryPicker"/>
</fields>
<contentObjectType>
First question: does that make sense?
So, now the issue is if I were building an app with child components =
(or
joined components) it might look like:
<contentObject label=3D"Forum">
<field
name=3D"threads"
isArray=3D"yes"
type=3D"myApp.threadComponent">
</contentObject>
Or, it might look like:
<contentObject label=3D"Forum">
<childObjects>
<objectType type=3D"myApp.threadComponent">
</childObjects>
</contentObject>
Or, perhaps:
<contentObject label=3D"Forum">
<joins>
<join type=3D"one2many" objectType=3D"myApp.threadComponent">
</joins>
</contentObject>
Any thoughts from the rest of you about which would be best?
In that last one, would we think that the thread than also has a join =
in its
definition? Would we need a separate place where a join is defined =
outside
of this config file?
Tangent: if we have fields that have arrays of values, do we want to =
expose
the CF array, or would we want to create methods to traverse it (using =
some
kind of iterator) to maintain the object-based API?
Hope that's enough to continue the conversation . . .
- Nathan
-----Original Message-----
From: mod...@li...
[mailto:mod...@li...]On Behalf Of Jeremy
Firsenbaum
Sent: Tuesday, October 29, 2002 2:51 PM
To: modus devs
Subject: [Modus-devs] Collections of content objects and performance
Thought this thread might be of interest to others on the list. Nathan =
and I
have been talking about a couple of issues I've raised, namely,
contentObjects containing collections of other contentObjects and the
performance impact of instantiating so many objects.
Note that this reads from the bottom up:
Nathan - certainly not wed to the interface. But unless, as you =
suggest, the
definition of what a field is changes I don't see a way of using =
basefield
for content objects. Back to the forum example I've been using - =
retrieving
a collection of threads:
The way I suggested:
<cfset forum=3D createObject("component","forum").init(forumID)>
<cfset threads=3D category.getObjectArray('threads')>
<cfloop from=3D"1" to=3D"#arrayLen(thread)#" index=3D"i">
<!--- doing stuff with each thread, like: --->
#thread[i].getField('thread').getValue()#
</cfloop>
One possible way of doing what you suggest:
<cfset forum=3D createObject("component","forum").init(forumID)>
<cfset threads=3D category.getField('threads').getValue()>
<cfloop from=3D"1" to=3D"#arrayLen(thread)#" index=3D"i">
#thread[i].getField('thread').getValue()#
</cfloop>
As you can see the only difference is the method call for the threads =
array.
And of course this gets back to the descriptor for the content object. =
In
the first case thread would have a property type of 'objectArray' or
'subcomponent' or something like that, and in the latter it has the =
type
'field' with a particular fieldType.
If the latter seems cleaner to you, fine. I just did it this way to =
avoid
reworking basefield - sort of a proof of concept. The developer using =
the
API already needs to know the 'type' for various fields. Most are =
simple
strings, but anything that extends basefile will certainly be handled
differently, or at least make several new methods available. So making
'contentObject' be a possible fieldType should be doable - the
basefieldValue idea is probably the way to go. Let me think about that =
a
bit.
As for the performance issue, it comes in precisely when you want to
instantiate a whole array of contentObjects. If I call load() on a 40 =
page
book object, a new instance has to be created for each of these pages. =
The
only way to avoid that is to reference the cached object, which opens =
up a
whole other can of worms - locking the server scope, concurrent access =
to
writable data... This may be possible, but is this a route worth going =
down.
Maybe others have thoughts.
- Jeremy
----- Original Message -----
From: Nathan Dintenfass
To: Jeremy Firsenbaum
Sent: Tuesday, October 29, 2002 12:27 PM
Subject: RE:
Ah, I see what you mean. Yes, get() does that, but only if you wish =
to
populate from another instance -- which you pass in -- that is, if you =
have
an existing contentObject that you want to "load()", then you need to =
do
this. But, in this case you still never need to recreate a whole new
instance as you already have the one you want to load and the one you
retrieve from the cache (except on the first hit) -- but, what you are
saying is that is a performance bottleneck for you, right? Hmm.
On the "interface" I was talking about -- yes, the API exposed to the =
end
user. I figured you were not wed to it. My instinct says that it =
would be
better to do an overhaul of what a "field" is. First, I'd make it =
possible
to have an array of values, even if not other contentObject. Then, =
I'd work
on making it possible to have the value of a field be a contentObject.
Perhaps baseFieldValue.cfc would be one way to get towards that??
I totally agree that one way or another there needs to be a way to =
have a
"book" and its "pages" (not to mention many-to-many relationships) and =
have
"book" and "page" each be instances of a contentObject.
- Nathan
-----Original Message-----
From: Jeremy Firsenbaum [mailto:jfi...@ma...]
Sent: Monday, October 28, 2002 5:33 PM
To: na...@ch...
Subject: Re:
"By the way, the only place I am using the makeClone() is when I put =
objects
into the cache, not when I take them out of the cache"
I'm sorry if I was misleading. "Cloning" takes place going in as well =
as
coming out, although the makeClone method is only called one way. =
Going in,
makeclone calls contentObjectPopulateFromInstance, which does all of =
the
actually duplicating. Coming out, get() calls
contentObjectPopulateFromInstance as well:
line 41 from simplefilesystempersister.cfc:
if(instance.cache.isObjectCached(arguments.id)){
objectRetrieved =3D instance.cache.getObject(arguments.id);
if(structCount(arguments) GT 1)
return =
contentObjectPopulateFromInstance(arguments[2],objectRetrieved);
else
return objectRetrieved;
}
I found the duplicating from a cached instance in
contentObjectPopulateFromInstance to be the bottleneck.
"I'm not sure I'm personally satisfied with the interface you are =
using in
your forums app."
I'm all up for criticism - but not sure what you're referring to by
interface. Do you mean the contentObjectArray within =
basecontentobject, or
the way in which the API is used externally to construct the forum.
Obviously this was just an example I was using to work with the idea =
of
content objects within content objects.
"Are you waiting for a signal from me as to what my alternative might =
be?"
Well - kinda, yeah. I mean I would like to know if this approach to
"composition" even makes sense, or whether there's another way of =
doing
"parts of" relationships within modus. Many systems, content =
management or
otherwise, have this kind of structure. An artifact, say a book, has =
many
pages, each one of which has been scanned in. At one level, you want =
to deal
with the book as a whole (when presenting a library of books), on =
another
level, each one of the pages is a content object unto itself (so that =
the
book is browsable). I would like to be able to load the book, for a =
single
request or in session scope, and have the pages come along for the =
ride,
just as each thread is available within the forum content object. Does =
this
even make sense within the context of what modus was and is being =
designed
to do?
----- Original Message -----
From: Nathan Dintenfass
To: Jeremy Firsenbaum
Sent: Monday, October 28, 2002 7:56 PM
Subject: RE:
Ah, yes. Well, right now you are at the cutting edge of that =
question. I'm
not sure I'm personally satisfied with the interface you are using in =
your
forums app. Doesn't feel clean to me, but I have a hard time =
justifying
that feeling. Are you waiting for a signal from me as to what my
alternative might be?
By the way, the only place I am using the makeClone() is when I put =
objects
into the cache, not when I take them out of the cache -- are you
experiencing serious performance problems with that? My main issue =
with
performance before the caching was with the getAll(). Load() is still =
a bit
slower than I'd like, but I figure that will be rarely called in =
volume
since getAll would be generally be faster. That is an area to work =
on,
though.
- n
-----Original Message-----
From: Jeremy Firsenbaum [mailto:jfi...@ma...]
Sent: Monday, October 28, 2002 4:45 PM
To: na...@ch...
Subject: Re:
Sorry for being obtuse - I mean being able to declare other content =
objects
as being contained within another content object: forums are composed =
of
threads, which are composed of posts...
----- Original Message -----
From: Nathan Dintenfass
To: Jeremy Firsenbaum
Sent: Monday, October 28, 2002 7:37 PM
Subject: RE:
When you say "composition of content object" what do you mean?
- n
-----Original Message-----
From: Jeremy Firsenbaum [mailto:jfi...@ma...]
Sent: Monday, October 28, 2002 4:33 PM
To: na...@ch...
Subject: Re:
Fair enough. Maybe it's all of the nested subcomponents that accounts =
for
the slowness in cloning from the cache.
I'd love to do some more work on modus, maybe sink my teeth in the XML
descriptor thing, but I feel like I can't do much with it until I know
whether composition of content objects is feasible. This seems to be =
the
most important feature needed to model more complex systems. Looking =
forward
to seeing what you think.
-Jeremy
----- Original Message -----
From: Nathan Dintenfass
To: Jeremy Firsenbaum
Sent: Monday, October 28, 2002 7:13 PM
Subject: RE:
Jeremy:
I hadn't yet gotten to look in depth at your changes. I agree the =
clone()
method is far from optimal (as I mentioned in that posting).
My comment was based on the dramatic performance enhancement I =
witnessed on
the modustest app after implementing the caching. My calls to =
getAll() went
from over 400ms with a handful of "press releases" to 20ms.
- n
-----Original Message-----
From: Jeremy Firsenbaum [mailto:jfi...@ma...]
Sent: Monday, October 28, 2002 3:52 PM
To: Nathan Dintenfass
Subject:
Hey Nathan
I saw your post to CFCDev today:
"I have taken pages that were slow because they had to instantiate =
dozens of
components and made them very fast by just grabbing from the cache in =
the
server scope."
This got me wondering if you have looked into the performance issue =
with
clone() that I mentioned last week. It seems like it wouldn't make a
difference whether the subcomponents were instantiated within the
contentObject, as I had tried to do, or if this were left to the =
developer
to do externally: forums =3D createObject (forum.cfc), loop for =
threads =3D
createObject(thread.cfc). If you need "dozens of components" the clone
technique doesn't seem to be optimal.
Were my performance numbers similar to yours (if you've had time to =
look
into this) or am I totally off base here?
Jeremy
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Modus-devs mailing list
Mod...@li...
https://lists.sourceforge.net/lists/listinfo/modus-devs |
|
From: Nathan D. <na...@ch...> - 2002-10-30 01:44:08
|
So, the question before us is whether "child" objects or "joined" objects
should be a separate kind of attribute of a contentObject from a field.
Hmm.
One question I've been thinking about is whether this is about a
parent-child relationship, in which case it makes more sense to use the way
you've been working on (and I'd consider calling it getChildren("threads")
or something like that. Or, is it more that a contentObject can have some
"joins" -- and really we need a way to define a join (as being either
one-to-many or many-to-many, for instance).
Seems the first issue is whether a field should be able to be of a type that
is actually just another contentObject. An interesting question. I think
the answer is yes, but I can also see how it causes a lot of problems for
the API and the cleanliness of the code base. One idea I floated was that
there should be a way for a field to be an array of values, independent of
whether it's contentObjects or not. Then, have a way for the value of the
field to be another contentObject. A field would then, perhaps, have
methods like isArray() and isContentObject() -- which would help a user who
might want to build some abstracted interfaces. Both arrays of values and
contentObjects as values creates some nastiness in the interface, though,
potentially. For instance, renderSimpleForm() on a contentObject -- could
get ugly.
Right now I'm thinking that moving towards the XML descriptor is the first
step to any of this. I am increasingly convinced that the CFPROPERTY route
is too limiting from an programming standpoint and apparently is also
potentially a big problem when it comes to performance (per an off-line
discussion with Sean Corfield).
Once we're using XML I think a lot of the other issues will be easier to
tackle. So, for instance, the pressRelease.cfc in the modustest app might
look like:
<contentObjectType label="Press Release">
<fields>
<field
name="title"
label="Title"
type="org.bacfug.modus.fields.text">
<rules>
<rule
name="org.bacfug.modus.validation.full" />
</rules>
</field>
<field
name="body"
label="Main Body"
type="org.bacfug.modus.fields.longText"/>
<field
name="image"
label="Photo"
type="org.bacfug.modus.fields.webImage"/>
<field
name="featured"
label="Featured?"
type="org.bacfug.modus.fields.yesno"
default="no">
<rules>
<rule
name="org.bacfug.modus.validation.boolean"/>
</rules>
</field>
<field
name="category"
label="Category"
type="modustest.contentObjects.categoryPicker"/>
</fields>
<contentObjectType>
First question: does that make sense?
So, now the issue is if I were building an app with child components (or
joined components) it might look like:
<contentObject label="Forum">
<field
name="threads"
isArray="yes"
type="myApp.threadComponent">
</contentObject>
Or, it might look like:
<contentObject label="Forum">
<childObjects>
<objectType type="myApp.threadComponent">
</childObjects>
</contentObject>
Or, perhaps:
<contentObject label="Forum">
<joins>
<join type="one2many" objectType="myApp.threadComponent">
</joins>
</contentObject>
Any thoughts from the rest of you about which would be best?
In that last one, would we think that the thread than also has a join in its
definition? Would we need a separate place where a join is defined outside
of this config file?
Tangent: if we have fields that have arrays of values, do we want to expose
the CF array, or would we want to create methods to traverse it (using some
kind of iterator) to maintain the object-based API?
Hope that's enough to continue the conversation . . .
- Nathan
-----Original Message-----
From: mod...@li...
[mailto:mod...@li...]On Behalf Of Jeremy
Firsenbaum
Sent: Tuesday, October 29, 2002 2:51 PM
To: modus devs
Subject: [Modus-devs] Collections of content objects and performance
Thought this thread might be of interest to others on the list. Nathan and I
have been talking about a couple of issues I've raised, namely,
contentObjects containing collections of other contentObjects and the
performance impact of instantiating so many objects.
Note that this reads from the bottom up:
Nathan - certainly not wed to the interface. But unless, as you suggest, the
definition of what a field is changes I don't see a way of using basefield
for content objects. Back to the forum example I've been using - retrieving
a collection of threads:
The way I suggested:
<cfset forum= createObject("component","forum").init(forumID)>
<cfset threads= category.getObjectArray('threads')>
<cfloop from="1" to="#arrayLen(thread)#" index="i">
<!--- doing stuff with each thread, like: --->
#thread[i].getField('thread').getValue()#
</cfloop>
One possible way of doing what you suggest:
<cfset forum= createObject("component","forum").init(forumID)>
<cfset threads= category.getField('threads').getValue()>
<cfloop from="1" to="#arrayLen(thread)#" index="i">
#thread[i].getField('thread').getValue()#
</cfloop>
As you can see the only difference is the method call for the threads array.
And of course this gets back to the descriptor for the content object. In
the first case thread would have a property type of 'objectArray' or
'subcomponent' or something like that, and in the latter it has the type
'field' with a particular fieldType.
If the latter seems cleaner to you, fine. I just did it this way to avoid
reworking basefield - sort of a proof of concept. The developer using the
API already needs to know the 'type' for various fields. Most are simple
strings, but anything that extends basefile will certainly be handled
differently, or at least make several new methods available. So making
'contentObject' be a possible fieldType should be doable - the
basefieldValue idea is probably the way to go. Let me think about that a
bit.
As for the performance issue, it comes in precisely when you want to
instantiate a whole array of contentObjects. If I call load() on a 40 page
book object, a new instance has to be created for each of these pages. The
only way to avoid that is to reference the cached object, which opens up a
whole other can of worms - locking the server scope, concurrent access to
writable data... This may be possible, but is this a route worth going down.
Maybe others have thoughts.
- Jeremy
----- Original Message -----
From: Nathan Dintenfass
To: Jeremy Firsenbaum
Sent: Tuesday, October 29, 2002 12:27 PM
Subject: RE:
Ah, I see what you mean. Yes, get() does that, but only if you wish to
populate from another instance -- which you pass in -- that is, if you have
an existing contentObject that you want to "load()", then you need to do
this. But, in this case you still never need to recreate a whole new
instance as you already have the one you want to load and the one you
retrieve from the cache (except on the first hit) -- but, what you are
saying is that is a performance bottleneck for you, right? Hmm.
On the "interface" I was talking about -- yes, the API exposed to the end
user. I figured you were not wed to it. My instinct says that it would be
better to do an overhaul of what a "field" is. First, I'd make it possible
to have an array of values, even if not other contentObject. Then, I'd work
on making it possible to have the value of a field be a contentObject.
Perhaps baseFieldValue.cfc would be one way to get towards that??
I totally agree that one way or another there needs to be a way to have a
"book" and its "pages" (not to mention many-to-many relationships) and have
"book" and "page" each be instances of a contentObject.
- Nathan
-----Original Message-----
From: Jeremy Firsenbaum [mailto:jfi...@ma...]
Sent: Monday, October 28, 2002 5:33 PM
To: na...@ch...
Subject: Re:
"By the way, the only place I am using the makeClone() is when I put objects
into the cache, not when I take them out of the cache"
I'm sorry if I was misleading. "Cloning" takes place going in as well as
coming out, although the makeClone method is only called one way. Going in,
makeclone calls contentObjectPopulateFromInstance, which does all of the
actually duplicating. Coming out, get() calls
contentObjectPopulateFromInstance as well:
line 41 from simplefilesystempersister.cfc:
if(instance.cache.isObjectCached(arguments.id)){
objectRetrieved = instance.cache.getObject(arguments.id);
if(structCount(arguments) GT 1)
return contentObjectPopulateFromInstance(arguments[2],objectRetrieved);
else
return objectRetrieved;
}
I found the duplicating from a cached instance in
contentObjectPopulateFromInstance to be the bottleneck.
"I'm not sure I'm personally satisfied with the interface you are using in
your forums app."
I'm all up for criticism - but not sure what you're referring to by
interface. Do you mean the contentObjectArray within basecontentobject, or
the way in which the API is used externally to construct the forum.
Obviously this was just an example I was using to work with the idea of
content objects within content objects.
"Are you waiting for a signal from me as to what my alternative might be?"
Well - kinda, yeah. I mean I would like to know if this approach to
"composition" even makes sense, or whether there's another way of doing
"parts of" relationships within modus. Many systems, content management or
otherwise, have this kind of structure. An artifact, say a book, has many
pages, each one of which has been scanned in. At one level, you want to deal
with the book as a whole (when presenting a library of books), on another
level, each one of the pages is a content object unto itself (so that the
book is browsable). I would like to be able to load the book, for a single
request or in session scope, and have the pages come along for the ride,
just as each thread is available within the forum content object. Does this
even make sense within the context of what modus was and is being designed
to do?
----- Original Message -----
From: Nathan Dintenfass
To: Jeremy Firsenbaum
Sent: Monday, October 28, 2002 7:56 PM
Subject: RE:
Ah, yes. Well, right now you are at the cutting edge of that question. I'm
not sure I'm personally satisfied with the interface you are using in your
forums app. Doesn't feel clean to me, but I have a hard time justifying
that feeling. Are you waiting for a signal from me as to what my
alternative might be?
By the way, the only place I am using the makeClone() is when I put objects
into the cache, not when I take them out of the cache -- are you
experiencing serious performance problems with that? My main issue with
performance before the caching was with the getAll(). Load() is still a bit
slower than I'd like, but I figure that will be rarely called in volume
since getAll would be generally be faster. That is an area to work on,
though.
- n
-----Original Message-----
From: Jeremy Firsenbaum [mailto:jfi...@ma...]
Sent: Monday, October 28, 2002 4:45 PM
To: na...@ch...
Subject: Re:
Sorry for being obtuse - I mean being able to declare other content objects
as being contained within another content object: forums are composed of
threads, which are composed of posts...
----- Original Message -----
From: Nathan Dintenfass
To: Jeremy Firsenbaum
Sent: Monday, October 28, 2002 7:37 PM
Subject: RE:
When you say "composition of content object" what do you mean?
- n
-----Original Message-----
From: Jeremy Firsenbaum [mailto:jfi...@ma...]
Sent: Monday, October 28, 2002 4:33 PM
To: na...@ch...
Subject: Re:
Fair enough. Maybe it's all of the nested subcomponents that accounts for
the slowness in cloning from the cache.
I'd love to do some more work on modus, maybe sink my teeth in the XML
descriptor thing, but I feel like I can't do much with it until I know
whether composition of content objects is feasible. This seems to be the
most important feature needed to model more complex systems. Looking forward
to seeing what you think.
-Jeremy
----- Original Message -----
From: Nathan Dintenfass
To: Jeremy Firsenbaum
Sent: Monday, October 28, 2002 7:13 PM
Subject: RE:
Jeremy:
I hadn't yet gotten to look in depth at your changes. I agree the clone()
method is far from optimal (as I mentioned in that posting).
My comment was based on the dramatic performance enhancement I witnessed on
the modustest app after implementing the caching. My calls to getAll() went
from over 400ms with a handful of "press releases" to 20ms.
- n
-----Original Message-----
From: Jeremy Firsenbaum [mailto:jfi...@ma...]
Sent: Monday, October 28, 2002 3:52 PM
To: Nathan Dintenfass
Subject:
Hey Nathan
I saw your post to CFCDev today:
"I have taken pages that were slow because they had to instantiate dozens of
components and made them very fast by just grabbing from the cache in the
server scope."
This got me wondering if you have looked into the performance issue with
clone() that I mentioned last week. It seems like it wouldn't make a
difference whether the subcomponents were instantiated within the
contentObject, as I had tried to do, or if this were left to the developer
to do externally: forums = createObject (forum.cfc), loop for threads =
createObject(thread.cfc). If you need "dozens of components" the clone
technique doesn't seem to be optimal.
Were my performance numbers similar to yours (if you've had time to look
into this) or am I totally off base here?
Jeremy
|
|
From: Jeremy F. <jfi...@ma...> - 2002-10-29 22:51:37
|
Thought this thread might be of interest to others on the list. Nathan =
and I have been talking about a couple of issues I've raised, namely, =
contentObjects containing collections of other contentObjects and the =
performance impact of instantiating so many objects.
Note that this reads from the bottom up:
Nathan - certainly not wed to the interface. But unless, as you suggest, =
the definition of what a field is changes I don't see a way of using =
basefield for content objects. Back to the forum example I've been using =
- retrieving a collection of threads:
The way I suggested:
<cfset forum=3D createObject("component","forum").init(forumID)>
<cfset threads=3D category.getObjectArray('threads')>
<cfloop from=3D"1" to=3D"#arrayLen(thread)#" index=3D"i">
<!--- doing stuff with each thread, like: --->
#thread[i].getField('thread').getValue()#=20
</cfloop>
One possible way of doing what you suggest:
<cfset forum=3D createObject("component","forum").init(forumID)>
<cfset threads=3D category.getField('threads').getValue()>
<cfloop from=3D"1" to=3D"#arrayLen(thread)#" index=3D"i">
#thread[i].getField('thread').getValue()#
</cfloop>
As you can see the only difference is the method call for the threads =
array. And of course this gets back to the descriptor for the content =
object. In the first case thread would have a property type of =
'objectArray' or 'subcomponent' or something like that, and in the =
latter it has the type 'field' with a particular fieldType.=20
If the latter seems cleaner to you, fine. I just did it this way to =
avoid reworking basefield - sort of a proof of concept. The developer =
using the API already needs to know the 'type' for various fields. Most =
are simple strings, but anything that extends basefile will certainly be =
handled differently, or at least make several new methods available. So =
making 'contentObject' be a possible fieldType should be doable - the =
basefieldValue idea is probably the way to go. Let me think about that a =
bit.
As for the performance issue, it comes in precisely when you want to =
instantiate a whole array of contentObjects. If I call load() on a 40 =
page book object, a new instance has to be created for each of these =
pages. The only way to avoid that is to reference the cached object, =
which opens up a whole other can of worms - locking the server scope, =
concurrent access to writable data... This may be possible, but is this =
a route worth going down. Maybe others have thoughts.
- Jeremy
----- Original Message -----=20
From: Nathan Dintenfass=20
To: Jeremy Firsenbaum=20
Sent: Tuesday, October 29, 2002 12:27 PM
Subject: RE:=20
Ah, I see what you mean. Yes, get() does that, but only if you wish =
to populate from another instance -- which you pass in -- that is, if =
you have an existing contentObject that you want to "load()", then you =
need to do this. But, in this case you still never need to recreate a =
whole new instance as you already have the one you want to load and the =
one you retrieve from the cache (except on the first hit) -- but, what =
you are saying is that is a performance bottleneck for you, right? Hmm.
On the "interface" I was talking about -- yes, the API exposed to the =
end user. I figured you were not wed to it. My instinct says that it =
would be better to do an overhaul of what a "field" is. First, I'd make =
it possible to have an array of values, even if not other contentObject. =
Then, I'd work on making it possible to have the value of a field be a =
contentObject. Perhaps baseFieldValue.cfc would be one way to get =
towards that??
I totally agree that one way or another there needs to be a way to =
have a "book" and its "pages" (not to mention many-to-many =
relationships) and have "book" and "page" each be instances of a =
contentObject.
- Nathan
-----Original Message-----
From: Jeremy Firsenbaum [mailto:jfi...@ma...]
Sent: Monday, October 28, 2002 5:33 PM
To: na...@ch...
Subject: Re:=20
"By the way, the only place I am using the makeClone() is when I put =
objects into the cache, not when I take them out of the cache"
I'm sorry if I was misleading. "Cloning" takes place going in as =
well as coming out, although the makeClone method is only called one =
way. Going in, makeclone calls contentObjectPopulateFromInstance, which =
does all of the actually duplicating. Coming out, get() calls =
contentObjectPopulateFromInstance as well:
line 41 from simplefilesystempersister.cfc:
if(instance.cache.isObjectCached(arguments.id)){
objectRetrieved =3D instance.cache.getObject(arguments.id);
if(structCount(arguments) GT 1)
return =
contentObjectPopulateFromInstance(arguments[2],objectRetrieved);
else
return objectRetrieved;=20
}
I found the duplicating from a cached instance in =
contentObjectPopulateFromInstance to be the bottleneck.
"I'm not sure I'm personally satisfied with the interface you are =
using in your forums app."
I'm all up for criticism - but not sure what you're referring to by =
interface. Do you mean the contentObjectArray within basecontentobject, =
or the way in which the API is used externally to construct the forum. =
Obviously this was just an example I was using to work with the idea of =
content objects within content objects.
"Are you waiting for a signal from me as to what my alternative =
might be?"
Well - kinda, yeah. I mean I would like to know if this approach to =
"composition" even makes sense, or whether there's another way of doing =
"parts of" relationships within modus. Many systems, content management =
or otherwise, have this kind of structure. An artifact, say a book, has =
many pages, each one of which has been scanned in. At one level, you =
want to deal with the book as a whole (when presenting a library of =
books), on another level, each one of the pages is a content object unto =
itself (so that the book is browsable). I would like to be able to load =
the book, for a single request or in session scope, and have the pages =
come along for the ride, just as each thread is available within the =
forum content object. Does this even make sense within the context of =
what modus was and is being designed to do?
----- Original Message -----=20
From: Nathan Dintenfass=20
To: Jeremy Firsenbaum=20
Sent: Monday, October 28, 2002 7:56 PM
Subject: RE:=20
Ah, yes. Well, right now you are at the cutting edge of that =
question. I'm not sure I'm personally satisfied with the interface you =
are using in your forums app. Doesn't feel clean to me, but I have a =
hard time justifying that feeling. Are you waiting for a signal from me =
as to what my alternative might be?
By the way, the only place I am using the makeClone() is when I =
put objects into the cache, not when I take them out of the cache -- are =
you experiencing serious performance problems with that? My main issue =
with performance before the caching was with the getAll(). Load() is =
still a bit slower than I'd like, but I figure that will be rarely =
called in volume since getAll would be generally be faster. That is an =
area to work on, though.
- n
-----Original Message-----
From: Jeremy Firsenbaum [mailto:jfi...@ma...]
Sent: Monday, October 28, 2002 4:45 PM
To: na...@ch...
Subject: Re:=20
Sorry for being obtuse - I mean being able to declare other =
content objects as being contained within another content object: forums =
are composed of threads, which are composed of posts...
----- Original Message -----=20
From: Nathan Dintenfass=20
To: Jeremy Firsenbaum=20
Sent: Monday, October 28, 2002 7:37 PM
Subject: RE:=20
When you say "composition of content object" what do you mean?
- n
-----Original Message-----
From: Jeremy Firsenbaum [mailto:jfi...@ma...]
Sent: Monday, October 28, 2002 4:33 PM
To: na...@ch...
Subject: Re:=20
Fair enough. Maybe it's all of the nested subcomponents that =
accounts for the slowness in cloning from the cache.
I'd love to do some more work on modus, maybe sink my teeth =
in the XML descriptor thing, but I feel like I can't do much with it =
until I know whether composition of content objects is feasible. This =
seems to be the most important feature needed to model more complex =
systems. Looking forward to seeing what you think.=20
-Jeremy
----- Original Message -----=20
From: Nathan Dintenfass=20
To: Jeremy Firsenbaum=20
Sent: Monday, October 28, 2002 7:13 PM
Subject: RE:=20
Jeremy:
I hadn't yet gotten to look in depth at your changes. I =
agree the clone() method is far from optimal (as I mentioned in that =
posting).
My comment was based on the dramatic performance =
enhancement I witnessed on the modustest app after implementing the =
caching. My calls to getAll() went from over 400ms with a handful of =
"press releases" to 20ms.
- n
-----Original Message-----
From: Jeremy Firsenbaum [mailto:jfi...@ma...]
Sent: Monday, October 28, 2002 3:52 PM
To: Nathan Dintenfass
Subject:=20
Hey Nathan
I saw your post to CFCDev today:
"I have taken pages that were slow because they had to =
instantiate dozens of components and made them very fast by just =
grabbing from the cache in the server scope."
This got me wondering if you have looked into the =
performance issue with clone() that I mentioned last week. It seems like =
it wouldn't make a difference whether the subcomponents were =
instantiated within the contentObject, as I had tried to do, or if this =
were left to the developer to do externally: forums =3D createObject =
(forum.cfc), loop for threads =3D createObject(thread.cfc). If you need =
"dozens of components" the clone technique doesn't seem to be optimal.
Were my performance numbers similar to yours (if you've =
had time to look into this) or am I totally off base here?
Jeremy
|
|
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
>
|
|
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: 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 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: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 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: 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: 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-09-25 03:11:18
|
Hehe. I agree that it if you can stick to one way of doing something,
that is a Good Thing(tm). I just put the call to setDirectory back into
the code that handles the POST. I don't think it's a big deal to do it
there. Maybe if you had a dozen defaults that you wanted to change it
might be worth doing it somewhere else. I played with a setDefaults
method...seemed like overkill for one thing.
On Tue, 2002-09-24 at 20:42, Nathan Dintenfass wrote:
> I feel like there were good reasons I didn't do that, but the only one
> coming to mind is that you sometimes need to pass arguments to an init()
> method, and they should either be always hidden or never hidden. Though, I
> guess whatever you pass to init() you could just make a different method.
> And perhaps it need not be so absolute.
>
> Hmm.
>
> Ah, now I remember. It's that if you have a parent that calls it's own
> init() in the "constructor" then that will happen before the child has a
> chance to run its constructor, which you don't always want. Or something
> like that ;)
>
> - Nathan
>
>
>
> > -----Original Message-----
> > From: mod...@li...
> > [mailto:mod...@li...]On Behalf Of Brad Pauly
> > Sent: Tuesday, September 24, 2002 7:24 PM
> > To: modus devs
> > Subject: RE: [Modus-devs] file upload
> >
> >
> > I call init() in the "constructor" of the code component, then call
> > setDirectory() there as well. I actually like it there. No need to call
> > it when instantiating. What about having components responsible for
> > calling init()?
> >
> >
> > On Tue, 2002-09-24 at 19:51, Nathan Dintenfass wrote:
> > > Well, that is exactly why having access to the parent init would be so
> > > nice -- I could build a new init() in baseFile that calls the
> > parent init
> > > and then calls the setDefaultDirectory() (sort of like the
> > newID() in the
> > > baseContentObject).
> > >
> > > I see the problem you have, though -- you can't call
> > setDirectory() until
> > > you init. Damn. Well, you could manually init() inside of
> > your object, but
> > > that may be confusing for the end user. This brings up an
> > issue about what
> > > should be set vs. CFPARAM'd during an init. This, I think, was
> > the reason I
> > > did:
> > >
> > > <cfparam name="instance.directory" default="#expandPath("/")#">
> > >
> > > inside of the baseFile.cfc instead of:
> > >
> > > <cfset instance.directory = expandPath("/")>
> > >
> > > Hmm, you may just be stuck using setDirectory() where you have
> > it now. I'm
> > > open to suggestions on this, though.
> > >
> > > - n
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: mod...@li...
> > > > [mailto:mod...@li...]On Behalf Of Brad Pauly
> > > > Sent: Tuesday, September 24, 2002 6:05 PM
> > > > To: modus devs
> > > > Subject: RE: [Modus-devs] file upload
> > > >
> > > >
> > > > super() would indeed be nice. Perhaps I am missing something, but to
> > > > call setDirectory() in the "constructor" I need to call init() first.
> > > > Which works just fine, I was just wondering if I could do it
> > another way
> > > > and always call init() as part of instantiating an object.
> > > >
> > > >
> > > > On Tue, 2002-09-24 at 17:45, Nathan Dintenfass wrote:
> > > > > Brad:
> > > > >
> > > > > First, I am psyched to see someone actually trying to use Modus!
> > > > >
> > > > > setDirectory() is probably something that should actually be
> > > > refactored in
> > > > > some way. I think a "defaultFileDirectory" might also be
> > > > appropriate for
> > > > > the config file. But, to your question . . .
> > > > >
> > > > > I am not sure why it's counterintuitive that you would need
> > to set the
> > > > > directory before setting the value. Remember, the
> > > > setFieldValues() calls
> > > > > the setValue() on each field, and for the baseFile the
> > > > setValue() method is
> > > > > what actually deals with the upload of the file. Thus, it needs to
> > > > > understand what directory it is going to use before the
> > value gets set.
> > > > >
> > > > > I wish there was a super() in CFC's, because then the baseFile
> > > > would have
> > > > > it's own init() method that called the init() of the
> > baseField and then
> > > > > added a setDefaultDirectory() method that could be overridden in
> > > > > implementations of a base file. But, I digress.
> > > > >
> > > > > I also would probably put the setDirectory() declaration
> > inside of your
> > > > > "code" component -- in the "constructor". That should work
> > > > nicely (assuming
> > > > > all "code" instances should store their files in the same
> > > > place!) and hide
> > > > > the need to know much about the location on the front.
> > > > >
> > > > > Make sense?
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: mod...@li...
> > > > > > [mailto:mod...@li...]On Behalf
> > Of Brad Pauly
> > > > > > Sent: Tuesday, September 24, 2002 4:28 PM
> > > > > > To: modus devs
> > > > > > Subject: [Modus-devs] file upload
> > > > > >
> > > > > >
> > > > > > Hi all... I was playing around some more and I noticed something
> > > > > > interesting. I have dug into it a little, but thought I would
> > > > post here
> > > > > > and see what came of it.
> > > > > >
> > > > > > I made a code object that uses basefile to upload files.
> > (I have been
> > > > > > recreating some of the things on the bacfug site, hence the
> > > > code object,
> > > > > > in hopes that my exploring will produce some
> > documentation on how to
> > > > > > create a simple site with Modus) The code object has a
> > three fields:
> > > > > > title, file, and description. I wanted to change where
> > the file was
> > > > > > uploaded, so I took advantage of the setDirectory method.
> > Here is the
> > > > > > snippet that does this:
> > > > > >
> > > > > >
> > > > > > // create an initizlie a code object
> > > > > > code =
> > createObject("component","bacfug.contentobjects.code").init();
> > > > > >
> > > > > > // if the form was POSTed process it
> > > > > > if (isDefined("form.fieldnames")) {
> > > > > >
> > > > > > // set the id
> > > > > > // i need to explore this more, but it
> > > > > > // seems to work in place of a isNew field
> > > > > > code.setID(form.id);
> > > > > >
> > > > > > // set the directory to upload to
> > > > > >
> > code.getField("file").setDirectory("#expandPath("/bacfug/code/")#");
> > > > > >
> > > > > > // set the field values based on the form
> > > > > > code.setFieldValues(argumentCollection=form);
> > > > > >
> > > > > > // if there are no errors, commit it to the database
> > > > > > if(NOT code.hasErrors()){
> > > > > >
> > > > > > // send it to the database
> > > > > > code.store();
> > > > > >
> > > > > > // reinitialize
> > > > > > code.init();
> > > > > > }
> > > > > > }
> > > > > >
> > > > > >
> > > > > > This works fine. However, if I call setFieldValues before
> > > > setDirectory,
> > > > > > the file is uploaded into the default directory ("/").
> > This is almost
> > > > > > counterintuitive to me. I thought perhaps the setValue calls in
> > > > > > setFieldValues might overwrite something. Looking into these two
> > > > > > methods, I couldn't find anything that would cause one to
> > > > overwrite the
> > > > > > other. That makes me think that I should be able to call
> > > > these in either
> > > > > > order and get the desired outcome.
> > > > > >
> > > > > > Any thoughs?
> > > > > >
> > > > > > Brad
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > -------------------------------------------------------
> > > > > > This sf.net email is sponsored by:ThinkGeek
> > > > > > Welcome to geek heaven.
> > > > > > http://thinkgeek.com/sf
> > > > > > _______________________________________________
> > > > > > Modus-devs mailing list
> > > > > > Mod...@li...
> > > > > > https://lists.sourceforge.net/lists/listinfo/modus-devs
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > -------------------------------------------------------
> > > > > This sf.net email is sponsored by:ThinkGeek
> > > > > Welcome to geek heaven.
> > > > > http://thinkgeek.com/sf
> > > > > _______________________________________________
> > > > > Modus-devs mailing list
> > > > > Mod...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/modus-devs
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This sf.net email is sponsored by:ThinkGeek
> > > > Welcome to geek heaven.
> > > > http://thinkgeek.com/sf
> > > > _______________________________________________
> > > > Modus-devs mailing list
> > > > Mod...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/modus-devs
> > > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by:ThinkGeek
> > > Welcome to geek heaven.
> > > http://thinkgeek.com/sf
> > > _______________________________________________
> > > Modus-devs mailing list
> > > Mod...@li...
> > > https://lists.sourceforge.net/lists/listinfo/modus-devs
> > >
> > >
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Modus-devs mailing list
> > Mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/modus-devs
> >
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Modus-devs mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modus-devs
>
>
|
|
From: Nathan D. <na...@ch...> - 2002-09-25 02:42:05
|
I feel like there were good reasons I didn't do that, but the only one
coming to mind is that you sometimes need to pass arguments to an init()
method, and they should either be always hidden or never hidden. Though, I
guess whatever you pass to init() you could just make a different method.
And perhaps it need not be so absolute.
Hmm.
Ah, now I remember. It's that if you have a parent that calls it's own
init() in the "constructor" then that will happen before the child has a
chance to run its constructor, which you don't always want. Or something
like that ;)
- Nathan
> -----Original Message-----
> From: mod...@li...
> [mailto:mod...@li...]On Behalf Of Brad Pauly
> Sent: Tuesday, September 24, 2002 7:24 PM
> To: modus devs
> Subject: RE: [Modus-devs] file upload
>
>
> I call init() in the "constructor" of the code component, then call
> setDirectory() there as well. I actually like it there. No need to call
> it when instantiating. What about having components responsible for
> calling init()?
>
>
> On Tue, 2002-09-24 at 19:51, Nathan Dintenfass wrote:
> > Well, that is exactly why having access to the parent init would be so
> > nice -- I could build a new init() in baseFile that calls the
> parent init
> > and then calls the setDefaultDirectory() (sort of like the
> newID() in the
> > baseContentObject).
> >
> > I see the problem you have, though -- you can't call
> setDirectory() until
> > you init. Damn. Well, you could manually init() inside of
> your object, but
> > that may be confusing for the end user. This brings up an
> issue about what
> > should be set vs. CFPARAM'd during an init. This, I think, was
> the reason I
> > did:
> >
> > <cfparam name="instance.directory" default="#expandPath("/")#">
> >
> > inside of the baseFile.cfc instead of:
> >
> > <cfset instance.directory = expandPath("/")>
> >
> > Hmm, you may just be stuck using setDirectory() where you have
> it now. I'm
> > open to suggestions on this, though.
> >
> > - n
> >
> >
> >
> > > -----Original Message-----
> > > From: mod...@li...
> > > [mailto:mod...@li...]On Behalf Of Brad Pauly
> > > Sent: Tuesday, September 24, 2002 6:05 PM
> > > To: modus devs
> > > Subject: RE: [Modus-devs] file upload
> > >
> > >
> > > super() would indeed be nice. Perhaps I am missing something, but to
> > > call setDirectory() in the "constructor" I need to call init() first.
> > > Which works just fine, I was just wondering if I could do it
> another way
> > > and always call init() as part of instantiating an object.
> > >
> > >
> > > On Tue, 2002-09-24 at 17:45, Nathan Dintenfass wrote:
> > > > Brad:
> > > >
> > > > First, I am psyched to see someone actually trying to use Modus!
> > > >
> > > > setDirectory() is probably something that should actually be
> > > refactored in
> > > > some way. I think a "defaultFileDirectory" might also be
> > > appropriate for
> > > > the config file. But, to your question . . .
> > > >
> > > > I am not sure why it's counterintuitive that you would need
> to set the
> > > > directory before setting the value. Remember, the
> > > setFieldValues() calls
> > > > the setValue() on each field, and for the baseFile the
> > > setValue() method is
> > > > what actually deals with the upload of the file. Thus, it needs to
> > > > understand what directory it is going to use before the
> value gets set.
> > > >
> > > > I wish there was a super() in CFC's, because then the baseFile
> > > would have
> > > > it's own init() method that called the init() of the
> baseField and then
> > > > added a setDefaultDirectory() method that could be overridden in
> > > > implementations of a base file. But, I digress.
> > > >
> > > > I also would probably put the setDirectory() declaration
> inside of your
> > > > "code" component -- in the "constructor". That should work
> > > nicely (assuming
> > > > all "code" instances should store their files in the same
> > > place!) and hide
> > > > the need to know much about the location on the front.
> > > >
> > > > Make sense?
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: mod...@li...
> > > > > [mailto:mod...@li...]On Behalf
> Of Brad Pauly
> > > > > Sent: Tuesday, September 24, 2002 4:28 PM
> > > > > To: modus devs
> > > > > Subject: [Modus-devs] file upload
> > > > >
> > > > >
> > > > > Hi all... I was playing around some more and I noticed something
> > > > > interesting. I have dug into it a little, but thought I would
> > > post here
> > > > > and see what came of it.
> > > > >
> > > > > I made a code object that uses basefile to upload files.
> (I have been
> > > > > recreating some of the things on the bacfug site, hence the
> > > code object,
> > > > > in hopes that my exploring will produce some
> documentation on how to
> > > > > create a simple site with Modus) The code object has a
> three fields:
> > > > > title, file, and description. I wanted to change where
> the file was
> > > > > uploaded, so I took advantage of the setDirectory method.
> Here is the
> > > > > snippet that does this:
> > > > >
> > > > >
> > > > > // create an initizlie a code object
> > > > > code =
> createObject("component","bacfug.contentobjects.code").init();
> > > > >
> > > > > // if the form was POSTed process it
> > > > > if (isDefined("form.fieldnames")) {
> > > > >
> > > > > // set the id
> > > > > // i need to explore this more, but it
> > > > > // seems to work in place of a isNew field
> > > > > code.setID(form.id);
> > > > >
> > > > > // set the directory to upload to
> > > > >
> code.getField("file").setDirectory("#expandPath("/bacfug/code/")#");
> > > > >
> > > > > // set the field values based on the form
> > > > > code.setFieldValues(argumentCollection=form);
> > > > >
> > > > > // if there are no errors, commit it to the database
> > > > > if(NOT code.hasErrors()){
> > > > >
> > > > > // send it to the database
> > > > > code.store();
> > > > >
> > > > > // reinitialize
> > > > > code.init();
> > > > > }
> > > > > }
> > > > >
> > > > >
> > > > > This works fine. However, if I call setFieldValues before
> > > setDirectory,
> > > > > the file is uploaded into the default directory ("/").
> This is almost
> > > > > counterintuitive to me. I thought perhaps the setValue calls in
> > > > > setFieldValues might overwrite something. Looking into these two
> > > > > methods, I couldn't find anything that would cause one to
> > > overwrite the
> > > > > other. That makes me think that I should be able to call
> > > these in either
> > > > > order and get the desired outcome.
> > > > >
> > > > > Any thoughs?
> > > > >
> > > > > Brad
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > -------------------------------------------------------
> > > > > This sf.net email is sponsored by:ThinkGeek
> > > > > Welcome to geek heaven.
> > > > > http://thinkgeek.com/sf
> > > > > _______________________________________________
> > > > > Modus-devs mailing list
> > > > > Mod...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/modus-devs
> > > > >
> > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This sf.net email is sponsored by:ThinkGeek
> > > > Welcome to geek heaven.
> > > > http://thinkgeek.com/sf
> > > > _______________________________________________
> > > > Modus-devs mailing list
> > > > Mod...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/modus-devs
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by:ThinkGeek
> > > Welcome to geek heaven.
> > > http://thinkgeek.com/sf
> > > _______________________________________________
> > > Modus-devs mailing list
> > > Mod...@li...
> > > https://lists.sourceforge.net/lists/listinfo/modus-devs
> > >
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Modus-devs mailing list
> > Mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/modus-devs
> >
> >
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Modus-devs mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modus-devs
>
|
|
From: Brad P. <br...@ro...> - 2002-09-25 02:32:09
|
I call init() in the "constructor" of the code component, then call
setDirectory() there as well. I actually like it there. No need to call
it when instantiating. What about having components responsible for
calling init()?
On Tue, 2002-09-24 at 19:51, Nathan Dintenfass wrote:
> Well, that is exactly why having access to the parent init would be so
> nice -- I could build a new init() in baseFile that calls the parent init
> and then calls the setDefaultDirectory() (sort of like the newID() in the
> baseContentObject).
>
> I see the problem you have, though -- you can't call setDirectory() until
> you init. Damn. Well, you could manually init() inside of your object, but
> that may be confusing for the end user. This brings up an issue about what
> should be set vs. CFPARAM'd during an init. This, I think, was the reason I
> did:
>
> <cfparam name="instance.directory" default="#expandPath("/")#">
>
> inside of the baseFile.cfc instead of:
>
> <cfset instance.directory = expandPath("/")>
>
> Hmm, you may just be stuck using setDirectory() where you have it now. I'm
> open to suggestions on this, though.
>
> - n
>
>
>
> > -----Original Message-----
> > From: mod...@li...
> > [mailto:mod...@li...]On Behalf Of Brad Pauly
> > Sent: Tuesday, September 24, 2002 6:05 PM
> > To: modus devs
> > Subject: RE: [Modus-devs] file upload
> >
> >
> > super() would indeed be nice. Perhaps I am missing something, but to
> > call setDirectory() in the "constructor" I need to call init() first.
> > Which works just fine, I was just wondering if I could do it another way
> > and always call init() as part of instantiating an object.
> >
> >
> > On Tue, 2002-09-24 at 17:45, Nathan Dintenfass wrote:
> > > Brad:
> > >
> > > First, I am psyched to see someone actually trying to use Modus!
> > >
> > > setDirectory() is probably something that should actually be
> > refactored in
> > > some way. I think a "defaultFileDirectory" might also be
> > appropriate for
> > > the config file. But, to your question . . .
> > >
> > > I am not sure why it's counterintuitive that you would need to set the
> > > directory before setting the value. Remember, the
> > setFieldValues() calls
> > > the setValue() on each field, and for the baseFile the
> > setValue() method is
> > > what actually deals with the upload of the file. Thus, it needs to
> > > understand what directory it is going to use before the value gets set.
> > >
> > > I wish there was a super() in CFC's, because then the baseFile
> > would have
> > > it's own init() method that called the init() of the baseField and then
> > > added a setDefaultDirectory() method that could be overridden in
> > > implementations of a base file. But, I digress.
> > >
> > > I also would probably put the setDirectory() declaration inside of your
> > > "code" component -- in the "constructor". That should work
> > nicely (assuming
> > > all "code" instances should store their files in the same
> > place!) and hide
> > > the need to know much about the location on the front.
> > >
> > > Make sense?
> > >
> > >
> > > > -----Original Message-----
> > > > From: mod...@li...
> > > > [mailto:mod...@li...]On Behalf Of Brad Pauly
> > > > Sent: Tuesday, September 24, 2002 4:28 PM
> > > > To: modus devs
> > > > Subject: [Modus-devs] file upload
> > > >
> > > >
> > > > Hi all... I was playing around some more and I noticed something
> > > > interesting. I have dug into it a little, but thought I would
> > post here
> > > > and see what came of it.
> > > >
> > > > I made a code object that uses basefile to upload files. (I have been
> > > > recreating some of the things on the bacfug site, hence the
> > code object,
> > > > in hopes that my exploring will produce some documentation on how to
> > > > create a simple site with Modus) The code object has a three fields:
> > > > title, file, and description. I wanted to change where the file was
> > > > uploaded, so I took advantage of the setDirectory method. Here is the
> > > > snippet that does this:
> > > >
> > > >
> > > > // create an initizlie a code object
> > > > code = createObject("component","bacfug.contentobjects.code").init();
> > > >
> > > > // if the form was POSTed process it
> > > > if (isDefined("form.fieldnames")) {
> > > >
> > > > // set the id
> > > > // i need to explore this more, but it
> > > > // seems to work in place of a isNew field
> > > > code.setID(form.id);
> > > >
> > > > // set the directory to upload to
> > > > code.getField("file").setDirectory("#expandPath("/bacfug/code/")#");
> > > >
> > > > // set the field values based on the form
> > > > code.setFieldValues(argumentCollection=form);
> > > >
> > > > // if there are no errors, commit it to the database
> > > > if(NOT code.hasErrors()){
> > > >
> > > > // send it to the database
> > > > code.store();
> > > >
> > > > // reinitialize
> > > > code.init();
> > > > }
> > > > }
> > > >
> > > >
> > > > This works fine. However, if I call setFieldValues before
> > setDirectory,
> > > > the file is uploaded into the default directory ("/"). This is almost
> > > > counterintuitive to me. I thought perhaps the setValue calls in
> > > > setFieldValues might overwrite something. Looking into these two
> > > > methods, I couldn't find anything that would cause one to
> > overwrite the
> > > > other. That makes me think that I should be able to call
> > these in either
> > > > order and get the desired outcome.
> > > >
> > > > Any thoughs?
> > > >
> > > > Brad
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This sf.net email is sponsored by:ThinkGeek
> > > > Welcome to geek heaven.
> > > > http://thinkgeek.com/sf
> > > > _______________________________________________
> > > > Modus-devs mailing list
> > > > Mod...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/modus-devs
> > > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by:ThinkGeek
> > > Welcome to geek heaven.
> > > http://thinkgeek.com/sf
> > > _______________________________________________
> > > Modus-devs mailing list
> > > Mod...@li...
> > > https://lists.sourceforge.net/lists/listinfo/modus-devs
> > >
> > >
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Modus-devs mailing list
> > Mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/modus-devs
> >
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Modus-devs mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modus-devs
>
>
|
|
From: Nathan D. <na...@ch...> - 2002-09-25 01:51:01
|
Well, that is exactly why having access to the parent init would be so
nice -- I could build a new init() in baseFile that calls the parent init
and then calls the setDefaultDirectory() (sort of like the newID() in the
baseContentObject).
I see the problem you have, though -- you can't call setDirectory() until
you init. Damn. Well, you could manually init() inside of your object, but
that may be confusing for the end user. This brings up an issue about what
should be set vs. CFPARAM'd during an init. This, I think, was the reason I
did:
<cfparam name="instance.directory" default="#expandPath("/")#">
inside of the baseFile.cfc instead of:
<cfset instance.directory = expandPath("/")>
Hmm, you may just be stuck using setDirectory() where you have it now. I'm
open to suggestions on this, though.
- n
> -----Original Message-----
> From: mod...@li...
> [mailto:mod...@li...]On Behalf Of Brad Pauly
> Sent: Tuesday, September 24, 2002 6:05 PM
> To: modus devs
> Subject: RE: [Modus-devs] file upload
>
>
> super() would indeed be nice. Perhaps I am missing something, but to
> call setDirectory() in the "constructor" I need to call init() first.
> Which works just fine, I was just wondering if I could do it another way
> and always call init() as part of instantiating an object.
>
>
> On Tue, 2002-09-24 at 17:45, Nathan Dintenfass wrote:
> > Brad:
> >
> > First, I am psyched to see someone actually trying to use Modus!
> >
> > setDirectory() is probably something that should actually be
> refactored in
> > some way. I think a "defaultFileDirectory" might also be
> appropriate for
> > the config file. But, to your question . . .
> >
> > I am not sure why it's counterintuitive that you would need to set the
> > directory before setting the value. Remember, the
> setFieldValues() calls
> > the setValue() on each field, and for the baseFile the
> setValue() method is
> > what actually deals with the upload of the file. Thus, it needs to
> > understand what directory it is going to use before the value gets set.
> >
> > I wish there was a super() in CFC's, because then the baseFile
> would have
> > it's own init() method that called the init() of the baseField and then
> > added a setDefaultDirectory() method that could be overridden in
> > implementations of a base file. But, I digress.
> >
> > I also would probably put the setDirectory() declaration inside of your
> > "code" component -- in the "constructor". That should work
> nicely (assuming
> > all "code" instances should store their files in the same
> place!) and hide
> > the need to know much about the location on the front.
> >
> > Make sense?
> >
> >
> > > -----Original Message-----
> > > From: mod...@li...
> > > [mailto:mod...@li...]On Behalf Of Brad Pauly
> > > Sent: Tuesday, September 24, 2002 4:28 PM
> > > To: modus devs
> > > Subject: [Modus-devs] file upload
> > >
> > >
> > > Hi all... I was playing around some more and I noticed something
> > > interesting. I have dug into it a little, but thought I would
> post here
> > > and see what came of it.
> > >
> > > I made a code object that uses basefile to upload files. (I have been
> > > recreating some of the things on the bacfug site, hence the
> code object,
> > > in hopes that my exploring will produce some documentation on how to
> > > create a simple site with Modus) The code object has a three fields:
> > > title, file, and description. I wanted to change where the file was
> > > uploaded, so I took advantage of the setDirectory method. Here is the
> > > snippet that does this:
> > >
> > >
> > > // create an initizlie a code object
> > > code = createObject("component","bacfug.contentobjects.code").init();
> > >
> > > // if the form was POSTed process it
> > > if (isDefined("form.fieldnames")) {
> > >
> > > // set the id
> > > // i need to explore this more, but it
> > > // seems to work in place of a isNew field
> > > code.setID(form.id);
> > >
> > > // set the directory to upload to
> > > code.getField("file").setDirectory("#expandPath("/bacfug/code/")#");
> > >
> > > // set the field values based on the form
> > > code.setFieldValues(argumentCollection=form);
> > >
> > > // if there are no errors, commit it to the database
> > > if(NOT code.hasErrors()){
> > >
> > > // send it to the database
> > > code.store();
> > >
> > > // reinitialize
> > > code.init();
> > > }
> > > }
> > >
> > >
> > > This works fine. However, if I call setFieldValues before
> setDirectory,
> > > the file is uploaded into the default directory ("/"). This is almost
> > > counterintuitive to me. I thought perhaps the setValue calls in
> > > setFieldValues might overwrite something. Looking into these two
> > > methods, I couldn't find anything that would cause one to
> overwrite the
> > > other. That makes me think that I should be able to call
> these in either
> > > order and get the desired outcome.
> > >
> > > Any thoughs?
> > >
> > > Brad
> > >
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by:ThinkGeek
> > > Welcome to geek heaven.
> > > http://thinkgeek.com/sf
> > > _______________________________________________
> > > Modus-devs mailing list
> > > Mod...@li...
> > > https://lists.sourceforge.net/lists/listinfo/modus-devs
> > >
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Modus-devs mailing list
> > Mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/modus-devs
> >
> >
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Modus-devs mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modus-devs
>
|
|
From: Brad P. <br...@ro...> - 2002-09-25 01:12:51
|
super() would indeed be nice. Perhaps I am missing something, but to
call setDirectory() in the "constructor" I need to call init() first.
Which works just fine, I was just wondering if I could do it another way
and always call init() as part of instantiating an object.
On Tue, 2002-09-24 at 17:45, Nathan Dintenfass wrote:
> Brad:
>
> First, I am psyched to see someone actually trying to use Modus!
>
> setDirectory() is probably something that should actually be refactored in
> some way. I think a "defaultFileDirectory" might also be appropriate for
> the config file. But, to your question . . .
>
> I am not sure why it's counterintuitive that you would need to set the
> directory before setting the value. Remember, the setFieldValues() calls
> the setValue() on each field, and for the baseFile the setValue() method is
> what actually deals with the upload of the file. Thus, it needs to
> understand what directory it is going to use before the value gets set.
>
> I wish there was a super() in CFC's, because then the baseFile would have
> it's own init() method that called the init() of the baseField and then
> added a setDefaultDirectory() method that could be overridden in
> implementations of a base file. But, I digress.
>
> I also would probably put the setDirectory() declaration inside of your
> "code" component -- in the "constructor". That should work nicely (assuming
> all "code" instances should store their files in the same place!) and hide
> the need to know much about the location on the front.
>
> Make sense?
>
>
> > -----Original Message-----
> > From: mod...@li...
> > [mailto:mod...@li...]On Behalf Of Brad Pauly
> > Sent: Tuesday, September 24, 2002 4:28 PM
> > To: modus devs
> > Subject: [Modus-devs] file upload
> >
> >
> > Hi all... I was playing around some more and I noticed something
> > interesting. I have dug into it a little, but thought I would post here
> > and see what came of it.
> >
> > I made a code object that uses basefile to upload files. (I have been
> > recreating some of the things on the bacfug site, hence the code object,
> > in hopes that my exploring will produce some documentation on how to
> > create a simple site with Modus) The code object has a three fields:
> > title, file, and description. I wanted to change where the file was
> > uploaded, so I took advantage of the setDirectory method. Here is the
> > snippet that does this:
> >
> >
> > // create an initizlie a code object
> > code = createObject("component","bacfug.contentobjects.code").init();
> >
> > // if the form was POSTed process it
> > if (isDefined("form.fieldnames")) {
> >
> > // set the id
> > // i need to explore this more, but it
> > // seems to work in place of a isNew field
> > code.setID(form.id);
> >
> > // set the directory to upload to
> > code.getField("file").setDirectory("#expandPath("/bacfug/code/")#");
> >
> > // set the field values based on the form
> > code.setFieldValues(argumentCollection=form);
> >
> > // if there are no errors, commit it to the database
> > if(NOT code.hasErrors()){
> >
> > // send it to the database
> > code.store();
> >
> > // reinitialize
> > code.init();
> > }
> > }
> >
> >
> > This works fine. However, if I call setFieldValues before setDirectory,
> > the file is uploaded into the default directory ("/"). This is almost
> > counterintuitive to me. I thought perhaps the setValue calls in
> > setFieldValues might overwrite something. Looking into these two
> > methods, I couldn't find anything that would cause one to overwrite the
> > other. That makes me think that I should be able to call these in either
> > order and get the desired outcome.
> >
> > Any thoughs?
> >
> > Brad
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Modus-devs mailing list
> > Mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/modus-devs
> >
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Modus-devs mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modus-devs
>
>
|
|
From: Brad P. <br...@ro...> - 2002-09-25 00:03:39
|
Ah ha! Makes perfect sense, and it is not counterintuitive. It's funny
how I can fail to see things sometimes. I looked directly at the
setValue method and was looking at how it uploaded files. I just didn't
make the connection between that and setFieldValues. /me is feeling
silly.
That is a good idea to put it in the "consturctor". I will give that a
try. Using Modus has been a fun way for me to try and get back up to
speed with CF after a little hiatus.
What happened to the framework discussion?? =)
On Tue, 2002-09-24 at 17:45, Nathan Dintenfass wrote:
> Brad:
>
> First, I am psyched to see someone actually trying to use Modus!
>
> setDirectory() is probably something that should actually be refactored in
> some way. I think a "defaultFileDirectory" might also be appropriate for
> the config file. But, to your question . . .
>
> I am not sure why it's counterintuitive that you would need to set the
> directory before setting the value. Remember, the setFieldValues() calls
> the setValue() on each field, and for the baseFile the setValue() method is
> what actually deals with the upload of the file. Thus, it needs to
> understand what directory it is going to use before the value gets set.
>
> I wish there was a super() in CFC's, because then the baseFile would have
> it's own init() method that called the init() of the baseField and then
> added a setDefaultDirectory() method that could be overridden in
> implementations of a base file. But, I digress.
>
> I also would probably put the setDirectory() declaration inside of your
> "code" component -- in the "constructor". That should work nicely (assuming
> all "code" instances should store their files in the same place!) and hide
> the need to know much about the location on the front.
>
> Make sense?
>
>
> > -----Original Message-----
> > From: mod...@li...
> > [mailto:mod...@li...]On Behalf Of Brad Pauly
> > Sent: Tuesday, September 24, 2002 4:28 PM
> > To: modus devs
> > Subject: [Modus-devs] file upload
> >
> >
> > Hi all... I was playing around some more and I noticed something
> > interesting. I have dug into it a little, but thought I would post here
> > and see what came of it.
> >
> > I made a code object that uses basefile to upload files. (I have been
> > recreating some of the things on the bacfug site, hence the code object,
> > in hopes that my exploring will produce some documentation on how to
> > create a simple site with Modus) The code object has a three fields:
> > title, file, and description. I wanted to change where the file was
> > uploaded, so I took advantage of the setDirectory method. Here is the
> > snippet that does this:
> >
> >
> > // create an initizlie a code object
> > code = createObject("component","bacfug.contentobjects.code").init();
> >
> > // if the form was POSTed process it
> > if (isDefined("form.fieldnames")) {
> >
> > // set the id
> > // i need to explore this more, but it
> > // seems to work in place of a isNew field
> > code.setID(form.id);
> >
> > // set the directory to upload to
> > code.getField("file").setDirectory("#expandPath("/bacfug/code/")#");
> >
> > // set the field values based on the form
> > code.setFieldValues(argumentCollection=form);
> >
> > // if there are no errors, commit it to the database
> > if(NOT code.hasErrors()){
> >
> > // send it to the database
> > code.store();
> >
> > // reinitialize
> > code.init();
> > }
> > }
> >
> >
> > This works fine. However, if I call setFieldValues before setDirectory,
> > the file is uploaded into the default directory ("/"). This is almost
> > counterintuitive to me. I thought perhaps the setValue calls in
> > setFieldValues might overwrite something. Looking into these two
> > methods, I couldn't find anything that would cause one to overwrite the
> > other. That makes me think that I should be able to call these in either
> > order and get the desired outcome.
> >
> > Any thoughs?
> >
> > Brad
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Modus-devs mailing list
> > Mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/modus-devs
> >
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Modus-devs mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modus-devs
>
>
|
|
From: Nathan D. <na...@ch...> - 2002-09-24 23:45:19
|
Brad:
First, I am psyched to see someone actually trying to use Modus!
setDirectory() is probably something that should actually be refactored in
some way. I think a "defaultFileDirectory" might also be appropriate for
the config file. But, to your question . . .
I am not sure why it's counterintuitive that you would need to set the
directory before setting the value. Remember, the setFieldValues() calls
the setValue() on each field, and for the baseFile the setValue() method is
what actually deals with the upload of the file. Thus, it needs to
understand what directory it is going to use before the value gets set.
I wish there was a super() in CFC's, because then the baseFile would have
it's own init() method that called the init() of the baseField and then
added a setDefaultDirectory() method that could be overridden in
implementations of a base file. But, I digress.
I also would probably put the setDirectory() declaration inside of your
"code" component -- in the "constructor". That should work nicely (assuming
all "code" instances should store their files in the same place!) and hide
the need to know much about the location on the front.
Make sense?
> -----Original Message-----
> From: mod...@li...
> [mailto:mod...@li...]On Behalf Of Brad Pauly
> Sent: Tuesday, September 24, 2002 4:28 PM
> To: modus devs
> Subject: [Modus-devs] file upload
>
>
> Hi all... I was playing around some more and I noticed something
> interesting. I have dug into it a little, but thought I would post here
> and see what came of it.
>
> I made a code object that uses basefile to upload files. (I have been
> recreating some of the things on the bacfug site, hence the code object,
> in hopes that my exploring will produce some documentation on how to
> create a simple site with Modus) The code object has a three fields:
> title, file, and description. I wanted to change where the file was
> uploaded, so I took advantage of the setDirectory method. Here is the
> snippet that does this:
>
>
> // create an initizlie a code object
> code = createObject("component","bacfug.contentobjects.code").init();
>
> // if the form was POSTed process it
> if (isDefined("form.fieldnames")) {
>
> // set the id
> // i need to explore this more, but it
> // seems to work in place of a isNew field
> code.setID(form.id);
>
> // set the directory to upload to
> code.getField("file").setDirectory("#expandPath("/bacfug/code/")#");
>
> // set the field values based on the form
> code.setFieldValues(argumentCollection=form);
>
> // if there are no errors, commit it to the database
> if(NOT code.hasErrors()){
>
> // send it to the database
> code.store();
>
> // reinitialize
> code.init();
> }
> }
>
>
> This works fine. However, if I call setFieldValues before setDirectory,
> the file is uploaded into the default directory ("/"). This is almost
> counterintuitive to me. I thought perhaps the setValue calls in
> setFieldValues might overwrite something. Looking into these two
> methods, I couldn't find anything that would cause one to overwrite the
> other. That makes me think that I should be able to call these in either
> order and get the desired outcome.
>
> Any thoughs?
>
> Brad
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Modus-devs mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modus-devs
>
|
|
From: Brad P. <br...@ro...> - 2002-09-24 23:36:11
|
Hi all... I was playing around some more and I noticed something
interesting. I have dug into it a little, but thought I would post here
and see what came of it.
I made a code object that uses basefile to upload files. (I have been
recreating some of the things on the bacfug site, hence the code object,
in hopes that my exploring will produce some documentation on how to
create a simple site with Modus) The code object has a three fields:
title, file, and description. I wanted to change where the file was
uploaded, so I took advantage of the setDirectory method. Here is the
snippet that does this:
// create an initizlie a code object
code = createObject("component","bacfug.contentobjects.code").init();
// if the form was POSTed process it
if (isDefined("form.fieldnames")) {
// set the id
// i need to explore this more, but it
// seems to work in place of a isNew field
code.setID(form.id);
// set the directory to upload to
code.getField("file").setDirectory("#expandPath("/bacfug/code/")#");
// set the field values based on the form
code.setFieldValues(argumentCollection=form);
// if there are no errors, commit it to the database
if(NOT code.hasErrors()){
// send it to the database
code.store();
// reinitialize
code.init();
}
}
This works fine. However, if I call setFieldValues before setDirectory,
the file is uploaded into the default directory ("/"). This is almost
counterintuitive to me. I thought perhaps the setValue calls in
setFieldValues might overwrite something. Looking into these two
methods, I couldn't find anything that would cause one to overwrite the
other. That makes me think that I should be able to call these in either
order and get the desired outcome.
Any thoughs?
Brad
|
|
From: Brad P. <br...@ro...> - 2002-09-20 05:39:28
|
I only have one small comment right now. I have been messing around a little creating simple content objects, like a "link", thinking in terms of the BACFUG site. Anyway, I was using renderBasicForm so ran into the field ordering issue. It is really quite simple to handle it on your own, and I would tend to agree that the core architecture shouldn't worry about that. My $0.01 for the evening. Brad On Thu, 2002-09-19 at 19:22, Nathan Dintenfass wrote: > [I've been out of town, but the discussion of frameworks is a great one to > have] > > FYI: I released the head as 0.2 today because I posted a message to the > CFGURU list that talked about Modus persistence, and didn't want people > downloading 0.1. > > Basic differences since 0.1: > > Sorting of contentObjects > New field validation rules > New form field rendering component > New default persister using the file system > Basic caching of object instances > makeClone() method in the baseContentObject() [used in caching] > makeID() in the baseContentObject() -- to allow implementations to have > their own default ID generation > > Also, cleaned up the code, so all tag attributes for CFFUNCTION and > CFARGUMENT should now be in place. > > Still to do (from the original list I wanted for 0.2, now for 0.3): > > -- Building SELECT form fields and multiple radio fields > > -- Working on fields with multiple values and the MULTI-SELECT/Checkbox form > fields for that > > -- Filtering of results. For instance, "get all press releases created > since one month ago". > > (following is repost from an old thread, but just to keep these items fresh > in the mind . . . ) > > Then, after that things like: > > -- Joins: how will we have many-to-many and one-to-many relationships > between object types? > > -- Searching: how will we do searching of field values > > -- Field ordering. Unfortunately, the metaData of a CFC does not return > properties in the order in which they appear in the CFML, so fields come out > in random order. This is kind of a bummer for things like > renderSimpleForm(), though I also could see an argument that order of > display is a front-end issue, not something the core architecture should > worry about, so I may skip this one for now, as I can't think of a really > clean way to make it happen. > > -- contentObjects as field values -- would it ever make sense? > > -- clustered caching: this is not a high priority for me because Modus does > not have huge scalability as a primary design consideration, but it should > > -- sample applications: something a bit more robust than what we have now > > -- documentation > > I also think there could be higher level kinds of things like: > > -- workflow and something like Spectra PLP's > > -- pluggable security mechanisms > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Modus-devs mailing list > Mod...@li... > https://lists.sourceforge.net/lists/listinfo/modus-devs > > |
|
From: Nathan D. <na...@ch...> - 2002-09-20 01:20:55
|
[I've been out of town, but the discussion of frameworks is a great one to have] FYI: I released the head as 0.2 today because I posted a message to the CFGURU list that talked about Modus persistence, and didn't want people downloading 0.1. Basic differences since 0.1: Sorting of contentObjects New field validation rules New form field rendering component New default persister using the file system Basic caching of object instances makeClone() method in the baseContentObject() [used in caching] makeID() in the baseContentObject() -- to allow implementations to have their own default ID generation Also, cleaned up the code, so all tag attributes for CFFUNCTION and CFARGUMENT should now be in place. Still to do (from the original list I wanted for 0.2, now for 0.3): -- Building SELECT form fields and multiple radio fields -- Working on fields with multiple values and the MULTI-SELECT/Checkbox form fields for that -- Filtering of results. For instance, "get all press releases created since one month ago". (following is repost from an old thread, but just to keep these items fresh in the mind . . . ) Then, after that things like: -- Joins: how will we have many-to-many and one-to-many relationships between object types? -- Searching: how will we do searching of field values -- Field ordering. Unfortunately, the metaData of a CFC does not return properties in the order in which they appear in the CFML, so fields come out in random order. This is kind of a bummer for things like renderSimpleForm(), though I also could see an argument that order of display is a front-end issue, not something the core architecture should worry about, so I may skip this one for now, as I can't think of a really clean way to make it happen. -- contentObjects as field values -- would it ever make sense? -- clustered caching: this is not a high priority for me because Modus does not have huge scalability as a primary design consideration, but it should -- sample applications: something a bit more robust than what we have now -- documentation I also think there could be higher level kinds of things like: -- workflow and something like Spectra PLP's -- pluggable security mechanisms |
|
From: Brad P. <br...@ro...> - 2002-09-18 19:16:30
|
I think I agree with you. I am not saying it is wrong, I just don't like it. =) The qForms examples at pengoworks.com didn't work for me. Admittedly I am using a browser (Galeon) that isn't at the top of the "we need to make sure our app works on these browsers" list. Maybe it is possible to have a good user experience without client side validation. I am not advocating one way or the other (despite my personal preference), I just want to consider all the possibilities. Brad On Wed, 2002-09-18 at 12:58, Brian Ghidinelli wrote: > > Client side validation is an important piece of the user experience pie. > It is not, however, to ensure data integrity. A proper application > includes both pieces. > > Check out qForms at http://www.pengoworks.com. > > > Brian > > > Brad Pauly wrote: > > > > How could I forget forms. I am not a fan of client side validation. > > Having a way to create form fields and define there validation rules, > > yet have it all handled for me via the framework, that would be nice. > > Oh, and make it flexible enough so I have full control of the layout. > > > > Brad > > > ------------------------------------------------------- > This SF.NET email is sponsored by: AMD - Your access to the experts > on Hammer Technology! Open Source & Linux Developers, register now > for the AMD Developer Symposium. Code: EX8664 > http://www.developwithamd.com/developerlab > _______________________________________________ > Modus-devs mailing list > Mod...@li... > https://lists.sourceforge.net/lists/listinfo/modus-devs > > |
4 messages has been excluded from this view by a project administrator.
