modus-devs — List for Modus Developers

RE: [Modus-devs] file system persistence

[Brad P. <br...@ro...>]

Yes, makes good sense. As far as formats for the config file. Hmm. Are
there any obvious logical lines that you could draw through the config
parameters? Actually, what are the other config parameters? 

Brad

On Wed, 2002-09-11 at 22:04, Nathan Dintenfass wrote:
> Brad:
> 
> Good questions.
> 
> I am thinking that default persister that uses the file system will likely just use different
> directories for each object type and keep all instances of that type in the same directory.
> Individual instances will be stored with the ID as the name of the file.  I don't think the default
> persister needs to be incredibly scalable, and I think having directories with less than a few
> thousand files will be fine.  If a user needs to have something more scalable they will no doubt
> choose a different persister.  Make sense?
> 
> I do think that we'll need to have some kind of config file, which will have the default persister
> as one of the variables.  I think XML is certainly the way to go for configuration -- any
> suggestions on formats?
> 
> I'm actually working on the new persister right now, hopefully I'll release it before the night is
> over . . .
> 
>  - n
> 
> 
> > -----Original Message-----
> > From: mod...@li...
> > [mailto:mod...@li...]On Behalf Of Brad Pauly
> > Sent: Wednesday, September 11, 2002 8:07 PM
> > To: modus devs
> > Subject: [Modus-devs] file system persistence
> >
> >
> > Hi Everyone,
> >
> > Since this is on Nathan's todo list, I thought I would bring it up and
> > see what people were thinking.
> >
> > It does seem that having all the files in one directory could hinder
> > performance. I have personally never done any tests to back that up. I
> > am guessing the performance could be related to the file system being
> > used.
> >
> > Using the object type sounds like a good scheme. I suppose these could
> > get large as well. Perhaps not large enough to worry about though.
> >
> > I was thinking that there might be a way to use the UUID, or whatever
> > the id is, to create a directory structure. My initial thought was to
> > just replace the "-" with a "/" and call it good. However, I am sure
> > that would lead to waaaay too many directories. What about some kind of
> > function that breaks the id into reasonably sized chunks and creates a
> > value out of it. The value would be in some range (something like 1 to
> > 100) and a directory tree built that way with the last chunk being the
> > file name. Is there any danger of overwriting a file? I don't know if
> > this is more work than makes sense. It might be that just creating
> > something like that hampers performance more than having directories
> > with a large number of files in it.
> >
> > Anybody have any thoughts on this?
> >
> > Brad
> >
> >
> >
> > -------------------------------------------------------
> > In remembrance
> > www.osdn.com/911/
> > _______________________________________________
> > Modus-devs mailing list
> > Mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/modus-devs
> >
> 
> 
> 
> -------------------------------------------------------
> In remembrance
> www.osdn.com/911/
> _______________________________________________
> Modus-devs mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modus-devs
> 
> 

RE: [Modus-devs] file system persistence

[Nathan D. <na...@ch...>]

Brad:

Good questions.

I am thinking that default persister that uses the file system will likely just use different
directories for each object type and keep all instances of that type in the same directory.
Individual instances will be stored with the ID as the name of the file.  I don't think the default
persister needs to be incredibly scalable, and I think having directories with less than a few
thousand files will be fine.  If a user needs to have something more scalable they will no doubt
choose a different persister.  Make sense?

I do think that we'll need to have some kind of config file, which will have the default persister
as one of the variables.  I think XML is certainly the way to go for configuration -- any
suggestions on formats?

I'm actually working on the new persister right now, hopefully I'll release it before the night is
over . . .

 - n


> -----Original Message-----
> From: mod...@li...
> [mailto:mod...@li...]On Behalf Of Brad Pauly
> Sent: Wednesday, September 11, 2002 8:07 PM
> To: modus devs
> Subject: [Modus-devs] file system persistence
>
>
> Hi Everyone,
>
> Since this is on Nathan's todo list, I thought I would bring it up and
> see what people were thinking.
>
> It does seem that having all the files in one directory could hinder
> performance. I have personally never done any tests to back that up. I
> am guessing the performance could be related to the file system being
> used.
>
> Using the object type sounds like a good scheme. I suppose these could
> get large as well. Perhaps not large enough to worry about though.
>
> I was thinking that there might be a way to use the UUID, or whatever
> the id is, to create a directory structure. My initial thought was to
> just replace the "-" with a "/" and call it good. However, I am sure
> that would lead to waaaay too many directories. What about some kind of
> function that breaks the id into reasonably sized chunks and creates a
> value out of it. The value would be in some range (something like 1 to
> 100) and a directory tree built that way with the last chunk being the
> file name. Is there any danger of overwriting a file? I don't know if
> this is more work than makes sense. It might be that just creating
> something like that hampers performance more than having directories
> with a large number of files in it.
>
> Anybody have any thoughts on this?
>
> Brad
>
>
>
> -------------------------------------------------------
> In remembrance
> www.osdn.com/911/
> _______________________________________________
> Modus-devs mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modus-devs
>

[Modus-devs] file system persistence

[Brad P. <br...@ro...>]

Hi Everyone,

Since this is on Nathan's todo list, I thought I would bring it up and
see what people were thinking.

It does seem that having all the files in one directory could hinder
performance. I have personally never done any tests to back that up. I
am guessing the performance could be related to the file system being
used.

Using the object type sounds like a good scheme. I suppose these could
get large as well. Perhaps not large enough to worry about though.

I was thinking that there might be a way to use the UUID, or whatever
the id is, to create a directory structure. My initial thought was to
just replace the "-" with a "/" and call it good. However, I am sure
that would lead to waaaay too many directories. What about some kind of
function that breaks the id into reasonably sized chunks and creates a
value out of it. The value would be in some range (something like 1 to
100) and a directory tree built that way with the last chunk being the
file name. Is there any danger of overwriting a file? I don't know if
this is more work than makes sense. It might be that just creating
something like that hampers performance more than having directories
with a large number of files in it.

Anybody have any thoughts on this?

Brad

RE: [Modus-devs] baseContentObject.init

[Brad P. <br...@ro...>]

I should have read my new mail first. You already did it. =)

On Tue, 2002-09-10 at 16:28, Nathan Dintenfass wrote:
> I also was thinking of making a makeID() method that defaulted to returning
> a UUID but could be modified per object type.

RE: [Modus-devs] baseContentObject.init

[Brad P. <br...@ro...>]

On Tue, 2002-09-10 at 16:28, Nathan Dintenfass wrote:
> That aside, are you comfortable now with the id always being there?

Yep =)
 
> I also was thinking of making a makeID() method that defaulted to returning
> a UUID but could be modified per object type.

That's a good idea. I just tried that and added a makeID() function to
the pressrelease component which returns hash(md5()). Works nicely. I
suppose a user could use anything as long as it didn't break the way
content objects are stored.

>  - n
> 
> 
> 
> > -----Original Message-----
> > From: mod...@li...
> > [mailto:mod...@li...]On Behalf Of Brad Pauly
> > Sent: Tuesday, September 10, 2002 2:45 PM
> > To: modus devs
> > Subject: RE: [Modus-devs] baseContentObject.init
> >
> >
> > Nathan,
> >
> > I could have been more elaborate, sorry 'bout that. I see your point
> > about making the id available for whatever the user might want.
> >
> > My main motivation was to lessen the number of calls to createUUID().
> > Although I can't quantify it, I feel safe saying that it is
> > computationally more expensive than just setting a variable to 0. I
> > think I looked into this at some point (probably more than a year ago),
> > but honestly don't remember. I would imagine it performs some kind of
> > one-way function on a seed based on time or something or other. That was
> > all I was thinking.
> >
> > Brad
> >
> 
> 
> 
> -------------------------------------------------------
> In remembrance
> www.osdn.com/911/
> _______________________________________________
> Modus-devs mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modus-devs
> 
> 

RE: [Modus-devs] project status

[Nathan D. <na...@ch...>]

>
> > -- Implement caching -- I built the first take at this
> > already, but the bug
> > in MX with the incorrect pageContext for CFC instances stored
> > in shared
> > memory scopes seems to be getting in the way, so right now I
> > hard-coded it
> > to not use caching yet.  I am praying that SP1 will fix that issue.
>
> Doesn't this bug only affect output from CFC methods? If so - why is
> this an issue? CFC methods normally should not output directly to the
> screen.

Well, I think it actually effects more than just output, but I don't know
all the details.  I could just have a bug in the code, but I didn't see
anything obvious.  But, if you see the problem and it's NOT an issue with
the shared memory scope, I'd love to hear about it.

RE: [Modus-devs] baseContentObject.init

[Nathan D. <na...@ch...>]

Ah.  Well, to be honest createUUID() is the least of the issue in
instantiating a CFC -- it must traverse the meta data tree and dynamically
create a component for each field -- compared to that createUUID() would
barely register as far as performance.  I don't think Modus will ever be
suitable for millions or even hundreds of thousands of contentObjects for
that reason.

I did run a test:

<cfscript>
	startTime = getTickCount();
	for(ii = 1; ii lte 1000; ii = ii + 1){
		foo = createUUID();
	}
	writeOutput(getTickCount() - startTime & " ms");
</cfscript>

I must say, I was surprised how long it took to run too.

That aside, are you comfortable now with the id always being there?

I also was thinking of making a makeID() method that defaulted to returning
a UUID but could be modified per object type.

 - n



> -----Original Message-----
> From: mod...@li...
> [mailto:mod...@li...]On Behalf Of Brad Pauly
> Sent: Tuesday, September 10, 2002 2:45 PM
> To: modus devs
> Subject: RE: [Modus-devs] baseContentObject.init
>
>
> Nathan,
>
> I could have been more elaborate, sorry 'bout that. I see your point
> about making the id available for whatever the user might want.
>
> My main motivation was to lessen the number of calls to createUUID().
> Although I can't quantify it, I feel safe saying that it is
> computationally more expensive than just setting a variable to 0. I
> think I looked into this at some point (probably more than a year ago),
> but honestly don't remember. I would imagine it performs some kind of
> one-way function on a seed based on time or something or other. That was
> all I was thinking.
>
> Brad
>

Re: [Modus-devs] baseContentObject.init

[Brian G. <br...@vf...>]

UUIDs I believe are fairly simple to calculate.  They use a combination of
time-dependent and machine-dependent values to create the number ensuring
it's global uniqueness.  The last half is machine dependent so that is a
"static" variable.  The first half is mostly time based which probably
isn't too bad.

In some (all?) versions of CF you can't calculate more than 1000 UUIDs per
second (millisecond granularity apparently).


Brian


Brad Pauly wrote:
> 
> Nathan,
> 
> I could have been more elaborate, sorry 'bout that. I see your point
> about making the id available for whatever the user might want.
> 
> My main motivation was to lessen the number of calls to createUUID().
> Although I can't quantify it, I feel safe saying that it is
> computationally more expensive than just setting a variable to 0. I
> think I looked into this at some point (probably more than a year ago),
> but honestly don't remember. I would imagine it performs some kind of
> one-way function on a seed based on time or something or other. That was
> all I was thinking.

RE: [Modus-devs] baseContentObject.init

[Brad P. <br...@ro...>]

Nathan,

I could have been more elaborate, sorry 'bout that. I see your point
about making the id available for whatever the user might want.

My main motivation was to lessen the number of calls to createUUID().
Although I can't quantify it, I feel safe saying that it is
computationally more expensive than just setting a variable to 0. I
think I looked into this at some point (probably more than a year ago),
but honestly don't remember. I would imagine it performs some kind of
one-way function on a seed based on time or something or other. That was
all I was thinking.

Brad

On Tue, 2002-09-10 at 11:54, Nathan Dintenfass wrote:
> Brad:
> 
> I am unclear as to what the benefit would be.  I'd still want to have the
> isNew() method, which I suppose could check if the id was blank, but why
> would you want that?  My reasoning was that every instance of a
> contentObject has an ID.  What you choose to do with that ID is up to the
> user, but you always know it's there, so you don't have to do any
> conditional logic just to play with your object.  The isNew() feature does
> let you know whether you're dealing with a new instance or not, but even if
> we started with a default ID I would stick with the wasLoadedFlag internally
> because someone can call an setID() on a new object anyway.
> 
> Perhaps I am missing something, though?
> 
>  - Nathan
> 
> > -----Original Message-----
> > From: mod...@li...
> > [mailto:mod...@li...]On Behalf Of Brad Pauly
> > Sent: Tuesday, September 10, 2002 8:18 AM
> > To: modus devs
> > Subject: [Modus-devs] baseContentObject.init
> >
> >
> > I hope I am not regressing here, but I am still wondering about creating
> > an id for a content object in the init function. Does it make sense to
> > call createUUID in the store function instead? My thought is that there
> > is no need to create an id if you already have one. Potentially you
> > could eliminate the wasLoadedFlag by relying on the id to test for
> > newness.
> >
> > Brad
> >
> >
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Modus-devs mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modus-devs
> 
> 

Re: [Modus-devs] project status

[Brian G. <br...@vf...>]

Nathan Dintenfass wrote:
> I have a feeling that some of the interfaces you have built for your CMS go
> beyond the current scope of Modus, but I think they could also be made to
> sit on top of Modus very nicely.  I did not originally set out to build a
> full-blown CMS, but I can easily imagine how one could from all of this.

Trust me, we do extensive stuff in the interest of over optimization for
speed and efficiency.  I also fail to reuse a lot of my code for that
reason.  I'm on board with Modus because it would be nice to have a
stable, reliable base. :)


Brian

RE: [Modus-devs] baseContentObject.init

[Nathan D. <na...@ch...>]

Brad:

I am unclear as to what the benefit would be.  I'd still want to have the
isNew() method, which I suppose could check if the id was blank, but why
would you want that?  My reasoning was that every instance of a
contentObject has an ID.  What you choose to do with that ID is up to the
user, but you always know it's there, so you don't have to do any
conditional logic just to play with your object.  The isNew() feature does
let you know whether you're dealing with a new instance or not, but even if
we started with a default ID I would stick with the wasLoadedFlag internally
because someone can call an setID() on a new object anyway.

Perhaps I am missing something, though?

 - Nathan

> -----Original Message-----
> From: mod...@li...
> [mailto:mod...@li...]On Behalf Of Brad Pauly
> Sent: Tuesday, September 10, 2002 8:18 AM
> To: modus devs
> Subject: [Modus-devs] baseContentObject.init
>
>
> I hope I am not regressing here, but I am still wondering about creating
> an id for a content object in the init function. Does it make sense to
> call createUUID in the store function instead? My thought is that there
> is no need to create an id if you already have one. Potentially you
> could eliminate the wasLoadedFlag by relying on the id to test for
> newness.
>
> Brad
>
>

RE: [Modus-devs] project status

[Nathan D. <na...@ch...>]

Hmm, never upload an image more than once.  So, the assumption is that you
are fairly likely to use the image in more than one place, right?  I am not
sure what the interface would then be to associate the image with another
object.  Perhaps through the "join" mechanism I talked about in an earlier
email.

I do think that, perhaps, it is an over abstraction that doesn't buy us very
much -- especially since you could get that same functionality with just a
little imagination.  For instance, you could still have an object which has
a single field for the image.  In fact, it could have a field for the image,
a field for the lowsrc image.  That would only leave out the javascript
triggers, which would require additional attributes of the field, or perhaps
a toHTML() method for the contentObject itself in which it could construct
the IMG tag correctly from all the fields (a great candidate for an
out-of-the-box object type).

This conversation makes me think the baseContentObject probably needs its
own toHTML(), which defaults to just looping through the fields calling the
toHTML() of each one (perhaps separated by a line break or something like
that) -- this assumes the default toHTML() on a contentObject itself would
rarely be called unless you had defined one in the contentObject type
component (ie: your fullWebImage.cfc that we're describing here).

But either way there is probably a need to create "object bundles".

I have a feeling that some of the interfaces you have built for your CMS go
beyond the current scope of Modus, but I think they could also be made to
sit on top of Modus very nicely.  I did not originally set out to build a
full-blown CMS, but I can easily imagine how one could from all of this.

Thanks for the interesting questions.

 - Nathan




> -----Original Message-----
> From: mod...@li...
> [mailto:mod...@li...]On Behalf Of Brian
> Ghidinelli
> Sent: Tuesday, September 10, 2002 8:05 AM
> To: mod...@li...
> Subject: Re: [Modus-devs] project status
>
>
>
> The only reason to really desire an image as a full object is for
> repurposing. We've tended to do some "high-design" CMS type work where all
> of those extra attributes (including lowsrc!) came in handy.  It will
> definitely work as extra fields but it just won't be globally updateable,
> correct?  Our goal was to never have to upload an image more than once.  I
> don't know that such a goal is particularly necessary though, so I bring
> this up in the interest of discussion as much as anything.
>
> Brian
>
> Nathan Dintenfass wrote:
> >
> > Hmm.
> >
> > I can see how you'd want this extra data about an image, and the current
> > webImage field type would not accommodate that.  I'll have to
> noodle on how
> > we would have those.  I still think they would be extra
> information about
> > the "field" rather than a full object.  I don't think you'd
> want to have:

[Modus-devs] baseContentObject.init

[Brad P. <br...@ro...>]

I hope I am not regressing here, but I am still wondering about creating
an id for a content object in the init function. Does it make sense to
call createUUID in the store function instead? My thought is that there
is no need to create an id if you already have one. Potentially you
could eliminate the wasLoadedFlag by relying on the id to test for
newness. 

Brad

Re: [Modus-devs] project status

[Brian G. <br...@vf...>]

The only reason to really desire an image as a full object is for
repurposing. We've tended to do some "high-design" CMS type work where all
of those extra attributes (including lowsrc!) came in handy.  It will
definitely work as extra fields but it just won't be globally updateable,
correct?  Our goal was to never have to upload an image more than once.  I
don't know that such a goal is particularly necessary though, so I bring
this up in the interest of discussion as much as anything.

Brian

Nathan Dintenfass wrote:
> 
> Hmm.
> 
> I can see how you'd want this extra data about an image, and the current
> webImage field type would not accommodate that.  I'll have to noodle on how
> we would have those.  I still think they would be extra information about
> the "field" rather than a full object.  I don't think you'd want to have:

RE: [Modus-devs] project status

[Raymond C. <ra...@ca...>]

> -- Implement caching -- I built the first take at this 
> already, but the bug
> in MX with the incorrect pageContext for CFC instances stored 
> in shared
> memory scopes seems to be getting in the way, so right now I 
> hard-coded it
> to not use caching yet.  I am praying that SP1 will fix that issue.

Doesn't this bug only affect output from CFC methods? If so - why is
this an issue? CFC methods normally should not output directly to the
screen.

=======================================================================
Raymond Camden, ColdFusion Jedi Master for Hire

Email    : jed...@ma...
Yahoo IM : cfjedimaster

"My ally is the Force, and a powerful ally it is." - Yoda 

RE: [Modus-devs] project status

[Nathan D. <na...@ch...>]

Hmm.

I can see how you'd want this extra data about an image, and the current
webImage field type would not accommodate that.  I'll have to noodle on how
we would have those.  I still think they would be extra information about
the "field" rather than a full object.  I don't think you'd want to have:

<cfcomponent extends="org.bacfug.modus.baseContentObject"
displayName="webImage">
<cfproperty type="field" fieldType="javascriptDirective" name="onMouseOver"
value="somejshere">
<cfproperty type="field" fieldType="javascriptDirective" name="onMouseOut"
value="somejshere">
etc.
</cfcomponent>

Though, I suppose I could see it.  Would that mean there would be a toHTML
method for a contentObject itself, rather than just for each "field".  What
if we had some way to have complex values for fields instead?  Or some other
way to have additional attributes of a field.  setAttribute() on a field,
perhaps?

For your Clinton example, you could do this now in v0_1_2 with just a little
bit of work to build a new field type which could extend the baseFile field
(like webImage does) for "WMVMovie" and for "QTMovie" -- the only thing they
would really need would to define the toHTML() method of the field to show
the OBJECT tag correctly (or however it gets rendered in HTML).  You would
then have a contentObject type like:

<cfcomponent extends="org.bacfug.modus.baseContentObject"
displayName="videoPackage">
<cfproperty
type="field"
name="name"
fieldType="org.bacfug.modus.fields.text"
label="Name"
rules="org.bacfug.modus.validation.full">

<cfproperty
type="field"
name="wmv56K"
fieldType="org.bacfug.modus.fields.WMVMovie"
label="WMV 56K Version">

<cfproperty
type="field"
name="wmvDSL"
fieldType="org.bacfug.modus.fields.WMVMovie"
label="WMV DSL Version">

<cfproperty
type="field"
name="QT56K"
fieldType="org.bacfug.modus.fields.QTMovie"
label="QuickTime 56K Version">

<cfproperty
type="field"
name="QTDSL"
fieldType="org.bacfug.modus.fields.QTMovie"
label="QuickTime DSL Version">

<cfproperty
name="label"
type="instance"
value="Video Package">
<cfcomponent>

Would that be sufficient for that example?  Maybe I'll build that out in the
morning (shouldn't take too long), so we can have a real working example to
play with.

I am not sure what value having each movie file be its own contentObject
would be in this case, but I am eager to hear more about the work you've
done in the past to make all of that happen.

I am starting to see how we may want to define some display methods for a
contentObject and/or have some kind of handler model to ease the displaying
of entire contentObjects in different contexts.

Does this make any sense?

 - n


> -----Original Message-----
> From: mod...@li...
> [mailto:mod...@li...]On Behalf Of Brian
> Ghidinelli
> Sent: Monday, September 09, 2002 11:18 PM
> To: mod...@li...
> Subject: Re: [Modus-devs] project status
>
>
>
> In my content management work in the past, images are always objects.
> They have:
>
> URL (relative usually) to the file
> width
> height
> alt text
> onClick function
> onMouseOver function
> onMouseOut function
> lowsrc alternate
>
> I'm not sure how you wrap this into a single URL field?  Likewise, your
> press kit example:  One of our content objects was a video object that was
> an array of various video clips at various bandwidths.  So a clip of "Bill
> Clinton playing the sax" might be comprised of four clips - two in WMV and
> two in QT, each having one at 56k and DSL speeds.  Collectively though,
> they were a single video content object.
>
>
> Brian
>
>
> Nathan Dintenfass wrote:
> >
> > Hmm, interesting.
> >
> > You could pull this off now by having a property that is of type
> > org.bacfug.fields.webImage with a default value of a path on
> the server to
> > an image.  Would that not be sufficient?  Keep in mind, an
> "image" is not a
> > contentObject in Modus -- it is a field of a contentObject.  A better
> > example of "nested objects" might be an array of press releases
> as a field
> > of a "press kit" object.  That would require some serious
> rethinking, and I
> > am not sure it would be worth it, since building a press kit from a few
> > different objects wouldn't be that hard anyway, right?  Perhaps, though,
> > having a way for a field to point to another object type would
> be good, but
> > that is starting to sound a lot like what I was talking about
> with "joins"
> > rather than actually nested objects.  Hmm.
> >
> > One quick thought is that this all makes me think that a field should
> > probably have a way to "hide" it for editing and/or in display
> (so you could
> > have a default image for your press release that didn't show up in a
> > simpleForm, for instance).
> >
> >  - n
> >
> > > -----Original Message-----
> > > From: mod...@li...
> > > [mailto:mod...@li...]On Behalf Of Brian
> > > Ghidinelli
> > > Sent: Monday, September 09, 2002 10:58 PM
> > > To: mod...@li...
> > > Subject: Re: [Modus-devs] project status
> > >
> > >
> > >
> > > Nathan Dintenfass wrote:
> > > > -- contentObjects as field values -- would it ever make sense?
> > >
> > > Is this ~nested content objects?  This is key - consider images as a
> > > content object; the ability to nest one image (say a logo) as
> a content
> > > object that belongs to all press releases is critical.
> > >
> > >
> > > Brian
> > >
> > >
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by: OSDN - Tired of that same old
> > > cell phone?  Get a new here for FREE!
> > > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> > > _______________________________________________
> > > Modus-devs mailing list
> > > Mod...@li...
> > > https://lists.sourceforge.net/lists/listinfo/modus-devs
> > >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by: OSDN - Tired of that same old
> > cell phone?  Get a new here for FREE!
> > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> > _______________________________________________
> > Modus-devs mailing list
> > Mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/modus-devs
>
> --
> brian ghidinelli  >  principal, technical  >  http://www.vfive.com
> 410 jessie street suite #701, sf ca 94103  >  415.227.9885
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Modus-devs mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modus-devs
>
>

RE: [Modus-devs] project status

[Nathan D. <na...@ch...>]

I was thinking of making a directory under WEB-INF called modus and having a
storage directory.  Then, I'd have a directory for each contentObjectType
and store individual files with the UUID as the file name.  Alternatively, I
considered storing it all in one big file, but that won't scale well.

As for a conf file, I suspect there will be one.  I am not yet sure exactly
what it will have, but a "default persister" path would be an excellent
candidate for a configuration variable.

It would be great if once the contentObject stuff is fairly well figured out
the project can expand to include more "application framework" elements, and
a conf file is probably the start of that kind of thinking.

 - Nathan

> -----Original Message-----
> From: mod...@li...
> [mailto:mod...@li...]On Behalf Of Brad Pauly
> Sent: Monday, September 09, 2002 11:21 PM
> To: mod...@li...
> Subject: RE: [Modus-devs] project status
>
>
> On Mon, 2002-09-09 at 22:54, Nathan Dintenfass wrote:
> > -- Changing the default persistence mechanism to use the file
> system.  This
> > will both help validate that I can truly have pluggable persistence
> > mechanisms and make Modus easier to use "out of the box".
>
> I was thinking about this when I was setting up the database. How are
> you thinking of doing it? The UUID seems like a good candidate for
> coming up with a directory structure. Related to this, I was wondering
> if there was going to be some kind of conf file. It might specify db or
> file system as well as where the file system would live.
>
> Brad
>
>
>

RE: [Modus-devs] project status

[Brad P. <br...@ro...>]

On Mon, 2002-09-09 at 22:54, Nathan Dintenfass wrote:
> -- Changing the default persistence mechanism to use the file system.  This
> will both help validate that I can truly have pluggable persistence
> mechanisms and make Modus easier to use "out of the box".

I was thinking about this when I was setting up the database. How are
you thinking of doing it? The UUID seems like a good candidate for
coming up with a directory structure. Related to this, I was wondering
if there was going to be some kind of conf file. It might specify db or
file system as well as where the file system would live.

Brad

Re: [Modus-devs] project status

[Brian G. <br...@vf...>]

In my content management work in the past, images are always objects. 
They have:

URL (relative usually) to the file
width
height
alt text
onClick function
onMouseOver function
onMouseOut function
lowsrc alternate

I'm not sure how you wrap this into a single URL field?  Likewise, your
press kit example:  One of our content objects was a video object that was
an array of various video clips at various bandwidths.  So a clip of "Bill
Clinton playing the sax" might be comprised of four clips - two in WMV and
two in QT, each having one at 56k and DSL speeds.  Collectively though,
they were a single video content object.


Brian


Nathan Dintenfass wrote:
> 
> Hmm, interesting.
> 
> You could pull this off now by having a property that is of type
> org.bacfug.fields.webImage with a default value of a path on the server to
> an image.  Would that not be sufficient?  Keep in mind, an "image" is not a
> contentObject in Modus -- it is a field of a contentObject.  A better
> example of "nested objects" might be an array of press releases as a field
> of a "press kit" object.  That would require some serious rethinking, and I
> am not sure it would be worth it, since building a press kit from a few
> different objects wouldn't be that hard anyway, right?  Perhaps, though,
> having a way for a field to point to another object type would be good, but
> that is starting to sound a lot like what I was talking about with "joins"
> rather than actually nested objects.  Hmm.
> 
> One quick thought is that this all makes me think that a field should
> probably have a way to "hide" it for editing and/or in display (so you could
> have a default image for your press release that didn't show up in a
> simpleForm, for instance).
> 
>  - n
> 
> > -----Original Message-----
> > From: mod...@li...
> > [mailto:mod...@li...]On Behalf Of Brian
> > Ghidinelli
> > Sent: Monday, September 09, 2002 10:58 PM
> > To: mod...@li...
> > Subject: Re: [Modus-devs] project status
> >
> >
> >
> > Nathan Dintenfass wrote:
> > > -- contentObjects as field values -- would it ever make sense?
> >
> > Is this ~nested content objects?  This is key - consider images as a
> > content object; the ability to nest one image (say a logo) as a content
> > object that belongs to all press releases is critical.
> >
> >
> > Brian
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by: OSDN - Tired of that same old
> > cell phone?  Get a new here for FREE!
> > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> > _______________________________________________
> > Modus-devs mailing list
> > Mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/modus-devs
> >
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Modus-devs mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modus-devs

-- 
brian ghidinelli  >  principal, technical  >  http://www.vfive.com
410 jessie street suite #701, sf ca 94103  >  415.227.9885

RE: [Modus-devs] project status

[Nathan D. <na...@ch...>]

Hmm, interesting.

You could pull this off now by having a property that is of type
org.bacfug.fields.webImage with a default value of a path on the server to
an image.  Would that not be sufficient?  Keep in mind, an "image" is not a
contentObject in Modus -- it is a field of a contentObject.  A better
example of "nested objects" might be an array of press releases as a field
of a "press kit" object.  That would require some serious rethinking, and I
am not sure it would be worth it, since building a press kit from a few
different objects wouldn't be that hard anyway, right?  Perhaps, though,
having a way for a field to point to another object type would be good, but
that is starting to sound a lot like what I was talking about with "joins"
rather than actually nested objects.  Hmm.

One quick thought is that this all makes me think that a field should
probably have a way to "hide" it for editing and/or in display (so you could
have a default image for your press release that didn't show up in a
simpleForm, for instance).

 - n


> -----Original Message-----
> From: mod...@li...
> [mailto:mod...@li...]On Behalf Of Brian
> Ghidinelli
> Sent: Monday, September 09, 2002 10:58 PM
> To: mod...@li...
> Subject: Re: [Modus-devs] project status
>
>
>
> Nathan Dintenfass wrote:
> > -- contentObjects as field values -- would it ever make sense?
>
> Is this ~nested content objects?  This is key - consider images as a
> content object; the ability to nest one image (say a logo) as a content
> object that belongs to all press releases is critical.
>
>
> Brian
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Modus-devs mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modus-devs
>

Re: [Modus-devs] project status

[Brian G. <br...@vf...>]

Nathan Dintenfass wrote:
> -- contentObjects as field values -- would it ever make sense?

Is this ~nested content objects?  This is key - consider images as a
content object; the ability to nest one image (say a logo) as a content
object that belongs to all press releases is critical.


Brian

RE: [Modus-devs] project status

[Nathan D. <na...@ch...>]

We are trying to transition from "proof-of-concept" to "workable release".

Also, when I say "we" I really mean "I", as nobody else has really gotten
involved in development yet.  But the handful of folks on this list are all
interested in doing so when they have some time.

Things on my immediate plate to work on:

-- 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".

-- Changing the default persistence mechanism to use the file system.  This
will both help validate that I can truly have pluggable persistence
mechanisms and make Modus easier to use "out of the box".

-- Implement caching -- I built the first take at this already, but the bug
in MX with the incorrect pageContext for CFC instances stored in shared
memory scopes seems to be getting in the way, so right now I hard-coded it
to not use caching yet.  I am praying that SP1 will fix that issue.

Once I get those things, I'll call it 0.2 and do another release of a .zip
file.

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

I also think building out a library of contentObject types and building some
more interesting field types would be good for the future of the project.

All that said, feedback from users will be the critical driver of the
direction of Modus.

 - Nathan






> -----Original Message-----
> From: mod...@li...
> [mailto:mod...@li...]On Behalf Of Brad Pauly
> Sent: Monday, September 09, 2002 7:41 PM
> To: mod...@li...
> Subject: [Modus-devs] project status
>
>
> Alrighty, now that I am slowly getting up to speed, I was wondering what
> the status of the project is now. What kind of issues are being
> addressed, and things like that.
>
> Brad
>
>
> >

[Modus-devs] project status

[Brad P. <br...@ro...>]

Alrighty, now that I am slowly getting up to speed, I was wondering what
the status of the project is now. What kind of issues are being
addressed, and things like that.

Brad 

RE: [Modus-devs] forms and objects

[Brad P. <br...@ro...>]

Cool. I think fields and such made me think "form". It took me a sec,
but I follow now.

On Mon, 2002-09-09 at 20:32, Nathan Dintenfass wrote:
> Yes, you are.  The thing I'd add is that in addition to being a container
> for a collection of fields, a contentObject brokers issues like persistence
> for those fields.  I could also see, down the road, a contentObject having
> knowledge of security and other things, but I haven't gotten that far yet.
> 
> I think what you could is extend the baseContentObject to be something like
> a formAwareBaseContentObject, then use that when making your instance
> types -- but I am pretty firmly set on not putting much into the
> baseContentObject that is aware of page flow/page context.  In fact, there
> might be all kinds of ways to extend baseContentObject to do
> context-specific things.
> 
>  - Nathan
> 
> > -----Original Message-----
> > From: mod...@li...
> > [mailto:mod...@li...]On Behalf Of Brad Pauly
> > Sent: Monday, September 09, 2002 7:07 PM
> > To: mod...@li...
> > Subject: RE: [Modus-devs] forms and objects
> >
> >
> > I think I am on the same page. Let's see. A content object is a
> > container for a collection of field component instances along with some
> > other information. The field component instances take care of things
> > like validation and setting their values. I was wondering if a content
> > object could know more about what is going on (i.e. a form POST). It
> > probably could, but that isn't really the point. A content object is not
> > necessarily a form per se.
> >
> > Am I getting there?
> >
> > On Mon, 2002-09-09 at 19:58, Nathan Dintenfass wrote:
> > >
> > >
> > > >
> > > > So if a user only wanted to display a few fields of a component that
> > > > they created, they could do this by passing only those fields to the
> > > > setFieldValues method. Then display it however they like. Am I on the
> > > > right track?
> > >
> > > Well, setFieldValues is really just a convenience method.  If I say:
> > >
> > > contentObject.setFieldValues(argumentCollection=form);
> > >
> > > That is the short-hand equivalent of doing something like:
> > >
> > > for(key in form){
> > > 	contentObject.getField(key).setValue(form[key]);
> > > }
> > >
> > > The key thing to grok here is that a contentObject has a bunch
> > of fields,
> > > each of which is a component instance itself.  It is the field
> > components
> > > that deal with everything about getting/setting values as well as
> > > validation.  The API of the baseContentObject exposes a lot of
> > convenience
> > > methods about fields, but the field is where the work happens.
> > So, a field
> > > instance always has a value.  By default that value is an empty string
> > > (since CF has no NULL).  When you set the value using
> > setFieldValues() on
> > > the content object instance or the setValue() method of the
> > field instance
> > > you are doing just that -- given the field a new value.  When you go to
> > > store() a content object, it persists the values of all the
> > fields (along
> > > with some other instance data about the object).  So, if you
> > create a new
> > > contentObject instance and set the value, when you go to get
> > the value it
> > > will be whatever it was set to.
> > >
> > > While I'm on the subject of setting field values, it's worth noting that
> > > Modus deals with validation a little differently than other CF
> > code I have
> > > ever written.  Rather than validating a value, then setting it in the
> > > database (or wherever), Modus prefers to have a "stateful" error status.
> > > The act of setting the value of a field automatically validates
> > that field.
> > > Thus, a field ALWAYS has an error state (either it has errors, or it
> > > doesn't).  So, you CAN set a field value to a value that is NOT
> > valid, but
> > > you cannot store a field with an invalid value (built into the store()
> > > method of the baseContentObject).  But, it is up the user to
> > decide how they
> > > want to deal with the flow in that case.  They could use
> > CFTHROW and build
> > > their own handling, they could do what the sample app does
> > right now, which
> > > is to do a simple if statement using the hasErrors() method of the
> > > baseContentObject (fields also have a hasErrors() method), and
> > then just to
> > > loop through any error messages in the content object instance
> > to display
> > > messages right on the screen.  Again, few assumptions are made
> > about how an
> > > application will get built, but the tools are there to use a number of
> > > different techniques.
> > >
> > > Does this help?
> > >
> > >  - Nathan
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by: OSDN - Tired of that same old
> > > cell phone?  Get a new here for FREE!
> > > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> > > _______________________________________________
> > > Modus-devs mailing list
> > > Mod...@li...
> > > https://lists.sourceforge.net/lists/listinfo/modus-devs
> > >
> > >
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by: OSDN - Tired of that same old
> > cell phone?  Get a new here for FREE!
> > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> > _______________________________________________
> > Modus-devs mailing list
> > Mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/modus-devs
> >
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Modus-devs mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modus-devs
> 
> 

RE: [Modus-devs] forms and objects

[Nathan D. <na...@ch...>]

Yes, you are.  The thing I'd add is that in addition to being a container
for a collection of fields, a contentObject brokers issues like persistence
for those fields.  I could also see, down the road, a contentObject having
knowledge of security and other things, but I haven't gotten that far yet.

I think what you could is extend the baseContentObject to be something like
a formAwareBaseContentObject, then use that when making your instance
types -- but I am pretty firmly set on not putting much into the
baseContentObject that is aware of page flow/page context.  In fact, there
might be all kinds of ways to extend baseContentObject to do
context-specific things.

 - Nathan

> -----Original Message-----
> From: mod...@li...
> [mailto:mod...@li...]On Behalf Of Brad Pauly
> Sent: Monday, September 09, 2002 7:07 PM
> To: mod...@li...
> Subject: RE: [Modus-devs] forms and objects
>
>
> I think I am on the same page. Let's see. A content object is a
> container for a collection of field component instances along with some
> other information. The field component instances take care of things
> like validation and setting their values. I was wondering if a content
> object could know more about what is going on (i.e. a form POST). It
> probably could, but that isn't really the point. A content object is not
> necessarily a form per se.
>
> Am I getting there?
>
> On Mon, 2002-09-09 at 19:58, Nathan Dintenfass wrote:
> >
> >
> > >
> > > So if a user only wanted to display a few fields of a component that
> > > they created, they could do this by passing only those fields to the
> > > setFieldValues method. Then display it however they like. Am I on the
> > > right track?
> >
> > Well, setFieldValues is really just a convenience method.  If I say:
> >
> > contentObject.setFieldValues(argumentCollection=form);
> >
> > That is the short-hand equivalent of doing something like:
> >
> > for(key in form){
> > 	contentObject.getField(key).setValue(form[key]);
> > }
> >
> > The key thing to grok here is that a contentObject has a bunch
> of fields,
> > each of which is a component instance itself.  It is the field
> components
> > that deal with everything about getting/setting values as well as
> > validation.  The API of the baseContentObject exposes a lot of
> convenience
> > methods about fields, but the field is where the work happens.
> So, a field
> > instance always has a value.  By default that value is an empty string
> > (since CF has no NULL).  When you set the value using
> setFieldValues() on
> > the content object instance or the setValue() method of the
> field instance
> > you are doing just that -- given the field a new value.  When you go to
> > store() a content object, it persists the values of all the
> fields (along
> > with some other instance data about the object).  So, if you
> create a new
> > contentObject instance and set the value, when you go to get
> the value it
> > will be whatever it was set to.
> >
> > While I'm on the subject of setting field values, it's worth noting that
> > Modus deals with validation a little differently than other CF
> code I have
> > ever written.  Rather than validating a value, then setting it in the
> > database (or wherever), Modus prefers to have a "stateful" error status.
> > The act of setting the value of a field automatically validates
> that field.
> > Thus, a field ALWAYS has an error state (either it has errors, or it
> > doesn't).  So, you CAN set a field value to a value that is NOT
> valid, but
> > you cannot store a field with an invalid value (built into the store()
> > method of the baseContentObject).  But, it is up the user to
> decide how they
> > want to deal with the flow in that case.  They could use
> CFTHROW and build
> > their own handling, they could do what the sample app does
> right now, which
> > is to do a simple if statement using the hasErrors() method of the
> > baseContentObject (fields also have a hasErrors() method), and
> then just to
> > loop through any error messages in the content object instance
> to display
> > messages right on the screen.  Again, few assumptions are made
> about how an
> > application will get built, but the tools are there to use a number of
> > different techniques.
> >
> > Does this help?
> >
> >  - Nathan
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by: OSDN - Tired of that same old
> > cell phone?  Get a new here for FREE!
> > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> > _______________________________________________
> > Modus-devs mailing list
> > Mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/modus-devs
> >
> >
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Modus-devs mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modus-devs
>