modus-devs — List for Modus Developers

RE: [Modus-devs] forms and objects

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

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

RE: [Modus-devs] forms and objects

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

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

RE: [Modus-devs] forms and objects

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

> Make sense?

I think so. 

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?

On Mon, 2002-09-09 at 19:28, Nathan Dintenfass wrote:
> The main reason this has not been done is because we didn't want to make too
> many assumptions about the flow a developer would want to use.  The
> "renderBasicForm()" creates a useful form, but we don't want to assume the
> elements found there (isNew, id, etc.) will necessarily exist, so we leave
> it to the user to decide how he/she wants to manage their page flow.  A user
> should, for instance, be able to create their own form by looping through
> fields in an order they choose and still be able to use everything.  As it
> is, all that needs to happen is to have a value associated with the name of
> a field -- the user can decide everything else.  If they want, they can use
> the renderBasicForm() to save time, and they can use the example app as a
> template (it would take just a couple extra lines of code for the sample app
> to work with ANY contentObject type).
> 
> With very few (and necessary) exceptions, Modus does not think about
> "FORM" -- since that may or may not be how a developer chooses to get
> information into a contentObject instance.  The one exception to this right
> now is in the fields/baseFile.cfc -- since using CFFILE ACTION="Upload"
> requires a FORM anyway, I figured it was a safe bet to make that assumption,
> and it was the only way to deal with getting a file into the system and
> still maintain the same API for a user.
> 
> Make sense?
> 
>  - Nathan
> 
> 
> 
> 
> > -----Original Message-----
> > From: mod...@li...
> > [mailto:mod...@li...]On Behalf Of Brad Pauly
> > Sent: Monday, September 09, 2002 4:15 PM
> > To: mod...@li...
> > Subject: [Modus-devs] forms and objects
> >
> >
> > Hey All,
> >
> > I am just getting the hang of how Modus works, so bear with my
> > ignorance. I have some thoughts/questions about forms and content
> > objects.
> >
> > I set up the test application then created my own content object called
> > "event". The first thing I noticed was that I didn't really want to do
> > all the checking that is done when a content object is created. Granted,
> > some of this is due to having one page serve as a both "add" and "edit".
> > However, I would like to be able to do something like:
> >
> > <cfscript>
> >
> > event =
> > createObject("component","modustest.contentobjects.event").init();
> >
> > if(isDefined("url.id")) {
> > 	event.load(url.id);
> > }
> >
> > if (event.hasErrors()) {
> > 	// code to handle errors
> > }
> >
> > </cfscript>
> >
> > <cfoutput>
> > 	#event.renderBasicForm()#
> > </cfoutput>
> >
> >
> > I think the object should know if it has been POSTed and do the right
> > thing. Is it plausible to check for form.id (or form.fieldnames) in the
> > init function and take care of storing etc there?
> >
> > Also, could the id be used to know if an object exists or not? I realize
> > that the init function is assigning the id. Could this be held off until
> > later? Perhaps it could be set to 0 or "" in init, then it being nonzero
> > would signify that it already existed.
> >
> > I am guessing much of this has been considered but thought I would
> > through it out there anyway.
> >
> > 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
> >
> 
> 
> 
> -------------------------------------------------------
> 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...>]

The main reason this has not been done is because we didn't want to make too
many assumptions about the flow a developer would want to use.  The
"renderBasicForm()" creates a useful form, but we don't want to assume the
elements found there (isNew, id, etc.) will necessarily exist, so we leave
it to the user to decide how he/she wants to manage their page flow.  A user
should, for instance, be able to create their own form by looping through
fields in an order they choose and still be able to use everything.  As it
is, all that needs to happen is to have a value associated with the name of
a field -- the user can decide everything else.  If they want, they can use
the renderBasicForm() to save time, and they can use the example app as a
template (it would take just a couple extra lines of code for the sample app
to work with ANY contentObject type).

With very few (and necessary) exceptions, Modus does not think about
"FORM" -- since that may or may not be how a developer chooses to get
information into a contentObject instance.  The one exception to this right
now is in the fields/baseFile.cfc -- since using CFFILE ACTION="Upload"
requires a FORM anyway, I figured it was a safe bet to make that assumption,
and it was the only way to deal with getting a file into the system and
still maintain the same API for a user.

Make sense?

 - Nathan




> -----Original Message-----
> From: mod...@li...
> [mailto:mod...@li...]On Behalf Of Brad Pauly
> Sent: Monday, September 09, 2002 4:15 PM
> To: mod...@li...
> Subject: [Modus-devs] forms and objects
>
>
> Hey All,
>
> I am just getting the hang of how Modus works, so bear with my
> ignorance. I have some thoughts/questions about forms and content
> objects.
>
> I set up the test application then created my own content object called
> "event". The first thing I noticed was that I didn't really want to do
> all the checking that is done when a content object is created. Granted,
> some of this is due to having one page serve as a both "add" and "edit".
> However, I would like to be able to do something like:
>
> <cfscript>
>
> event =
> createObject("component","modustest.contentobjects.event").init();
>
> if(isDefined("url.id")) {
> 	event.load(url.id);
> }
>
> if (event.hasErrors()) {
> 	// code to handle errors
> }
>
> </cfscript>
>
> <cfoutput>
> 	#event.renderBasicForm()#
> </cfoutput>
>
>
> I think the object should know if it has been POSTed and do the right
> thing. Is it plausible to check for form.id (or form.fieldnames) in the
> init function and take care of storing etc there?
>
> Also, could the id be used to know if an object exists or not? I realize
> that the init function is assigning the id. Could this be held off until
> later? Perhaps it could be set to 0 or "" in init, then it being nonzero
> would signify that it already existed.
>
> I am guessing much of this has been considered but thought I would
> through it out there anyway.
>
> 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
>

[Modus-devs] forms and objects

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

Hey All,

I am just getting the hang of how Modus works, so bear with my
ignorance. I have some thoughts/questions about forms and content
objects.

I set up the test application then created my own content object called
"event". The first thing I noticed was that I didn't really want to do
all the checking that is done when a content object is created. Granted,
some of this is due to having one page serve as a both "add" and "edit".
However, I would like to be able to do something like:

<cfscript>

event =
createObject("component","modustest.contentobjects.event").init();
	
if(isDefined("url.id")) {
	event.load(url.id);
}
	
if (event.hasErrors()) {
	// code to handle errors
}

</cfscript>

<cfoutput>	
	#event.renderBasicForm()#
</cfoutput>


I think the object should know if it has been POSTed and do the right
thing. Is it plausible to check for form.id (or form.fieldnames) in the
init function and take care of storing etc there?

Also, could the id be used to know if an object exists or not? I realize
that the init function is assigning the id. Could this be held off until
later? Perhaps it could be set to 0 or "" in init, then it being nonzero
would signify that it already existed.

I am guessing much of this has been considered but thought I would
through it out there anyway.

Brad

[Modus-devs] sorting, caching, a welcome message, etc.

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

(welcome to Raymond Camden to modus-devs!)

I just checked in a first pass as sorting, with a getAllSorted() method on
both the basePersister and an interface to it on the baseContentObject.  I'm
not totally happy with the implementation, but it does work.  I updated the
modustest app to sort on the "featured" field descending, then on title, and
it works like a charm.

I also put some basic caching into the basePersister, but due to the bugs
with persistent memory scopes (or perhaps due to some idiocy of my own) it
isn't working, so it's forced to never look in the cache right now (the
isObjectCached() method always returns false), but once SP1 comes out
(assuming it fixes that issue) we can try it out.  The current caching does
a "one a time" method of caching objects, and each persister implementation
can decide how best to use the machinery of the basePersister, which
provides:

isObjectCached(id)
cachePutObject(object)
cacheGetObject(id)

I implemented this in the simpleObjectInstance persister, and it seems like
it will do what it's supposed to do, but I couldn't get it to populate field
values properly.  Not sure if it's a memory-scope issue or not, though.  (I
think for 0.2 I'll build a persistence implementation that uses the file
system instead of a database, so Modus can be used "out of the box" more
easily.)

I also built:

isCacheInitialized()
cacheInit()

which are used when the persister is initialized, so a user should never
have to think about them.

I am still eager to think about the option of using a large XML DOM and
xPath to do some truly powerful stuff.  The XML would be something like:

<contentObjects>
	<contentObject id="" type="" dateCreated="" dateModified="">
		<field name="" value="">
		<field name="" value="">
	</contentObject>
	<contentObject id="" type="" dateCreated="" dateModified="">
		<field name="" value="">
		<field name="" value="">
	</contentObject>
</contentObjects>



 - n

Re: [Modus-devs] some conventions for Modus

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

I think I would ... good question.  One of two options:

1. Make it part of the main module and when you build a "release", it
strips out those things you don't want (like modus developer docs)

2. Make it a separate module and download but it seems like docs should be
in there by default... ? 


Brian


Nathan Dintenfass wrote:
> 
> Hmm, would you make it a different module, or part of the org/bacfug/modus
> tree in org/bacfug/modus/docs

RE: [Modus-devs] some conventions for Modus

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

Hmm, would you make it a different module, or part of the org/bacfug/modus
tree in org/bacfug/modus/docs


> Nathan Dintenfass wrote:
> >
> > [I have also added this to the documents at SourceForge]
>
> Planning to put this as a file inside the CVS repository?  Would be a good
> idea to have a documentation tree perhaps, with sub trees for modus
> developers and modus users (who are also developers, but with different
> interests).
>
>
> Brian

Re: [Modus-devs] some conventions for Modus

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

Nathan Dintenfass wrote:
> 
> [I have also added this to the documents at SourceForge]

Planning to put this as a file inside the CVS repository?  Would be a good
idea to have a documentation tree perhaps, with sub trees for modus
developers and modus users (who are also developers, but with different
interests).


Brian

[Modus-devs] some conventions for Modus

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

[I have also added this to the documents at SourceForge]

I just checked in some cleanup of the CFFUNCTIon attributes, so everything
now has:

output="no"
access="foo"
returnType="foo"
hint="foo"

From this point forward all methods must have these to be considered
complete.

Also, I have taken to using the convention of storing all "private" data
members in a struct called "instance", so at the top of every component
(every base component, that is), I have:

<cfparam name="instance" default="#structNew()#">

Then, all private stuff is put in instance.

This allows easy stuff like:

instance.foo = arguments.foo

It also allows you to define a CFPROPERTY with a type="instance" and have it
created as a private variable when the component is instantiated.

Also, all CFC's have an init() method that returns "this" and specifies the
base component as the returnType:

At its simplest, they do this:

<!--- the initializer --->
<cffunction name="init" access="public"
returnType="org.bacfug.modus.validation.baseRule" output="no"
hint="initialize this instance">
	<cfreturn this>
</cffunction>

All instance vars typically get their default value in the init(), NOT in
the constructor.  This allows for much fewer headaches during the
implementations of the base components.

In general, method names should be fairly simple.  A few popular prefixes I
am using in Modus:

getFoo()
setFoo()
makeFoo()
BarToFoo()
isFoo()

Outside of that, it tends to be simple:

save()
load()
validate()

camelHump style is used throughout for variable and method names.

All tags are lower case

CFSCRIPT is used heavily, when possible.

ALL local variables inside of methods are created using <CFSET var foo =
"bar">

[Modus-devs] [ modus-Issues to Resolve-603650 ] Mapped Paths and getWebRootRelativePath

[<no...@so...>]

Issues to Resolve item #603650, was opened at 2002-09-02 19:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=497736&aid=603650&group_id=61240

Category: Files
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nathan Dintenfass (ndintenfass)
Assigned to: Nobody/Anonymous (nobody)
Summary: Mapped Paths and getWebRootRelativePath

Initial Comment:
How shall we deal with mapped paths and the 
getWebRootRelativePath() -- it's a bummer to think a 
developer can't put stuff into a directory that is a mapped 
path, so we probably need to create some kind of 
interface to allow mapped paths to manifest themselves 
for a file.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=497736&aid=603650&group_id=61240