Pain not having model methods with query

[m...@iamjamesgibson.com]

Hey Guys,

I am not sure about anyone else, but I am definitely feeling some pain
trying to work around not having objects in my record sets. Have there
or are there any plans to close the gap?

Thanks,
James

[raulriera]

It would be impossible to have a query of objects, it would require an
array of objects. For performance issues this is not there yet, but it
could be http://code.google.com/p/cfwheels/issues/list

On Jul 11, 3:43 pm, "m...@iamjamesgibson.com"

[Per Djurner]

Don't think that link went through.

I think this is the feature Raul was thinking about:

http://code.google.com/p/cfwheels/issues/detail?id=63

[tpet...@gmail.com]

until cf get the performance issue straighten out, we're kind of
screwed with the whole array of objects approach. it's a pity too. i
believe per is working on getting the calculated properties done.

peter bell also had an interesting concept with his iterated business
object approach:

http://www.pbell.com/index.cfm/IBO

On Jul 10, 4:43 pm, "m...@iamjamesgibson.com"

[James Gibson]

Hey Guys,

What do you think about at least having the rendering framework be
able to render an array of objects with includePartial() or
renderPartial()? That was we can create objects if they are absolutely
necessary and interate over them like we would a query.

James

[Chris Peters]

The problem that everyone is describing is that even having an array of objects to begin with is where the performance issues are.

It looks like the Hibernate support in CF9/Railo could *potentially* solve this problem. (I think I heard that Railo will be working on adding Hibernate to their engine too.) Read Ben Forta's recent blog entry about CF9 ORM. Apparently it returns an array of objects, and one would think that this would be at good performance...
http://forta.com/blog/index.cfm/2009/7/7/ORM-Rethinking-ColdFusion-Database-Integration

[Per Djurner]

James, can you give me a real-world code example of where you are feeling this pain?

Would make it easier for me to think of alternatives.

Thanks.

[Russ Johnson]

I think what James is getting at is this...

If I have a partial that displays a single user record, I have to reference all of the users attributes like user.name, user.email...

Well, if I do a findAll() on my users, we cant include that partial and pass the query to it do display each user because of the way your reference your variables for the object vs. a query... so I would have to create 2 identical partials, one for rendering a single object and one for rendering a single record from a query.

Does that make sense? This may or may not be what James is alluding to, just my interpretation...

- Russ

[Per Djurner]

Actually, you should be able to use the same partial for both queries and objects.

All object properties / record values are passed in as arguments to the partial so you can reference them with arguments.name, arguments.email etc.

More info here:

http://code.google.com/p/cfwheels/wiki/Partials

/ Per

[Per Djurner]

On 2nd thought, arguments.name (as an object property) would clash with the name argument used to decide what file to include.

Maybe it would be better if the object properties and/or record values were made available in arguments.properties (as a struct)?

[Chris Peters]

Either that or rename arguments.name to something else, like arguments.partial?

Oh yeah, the Partials chapter is posted live. Holding back on the blog announcement until I update the rest of the chapters.
http://www.cfwheels.org/docs/chapter/partials

[James Gibson]

Hey Guys,

My real world example is that I am building a very dynamic application
and need to loop through objects to build forms. So there are
currently multiple problems.

1. A form in wheels expects to interact with an object. So if I have a
query returned to me and would like loop through that query to create
form fields, the framework breaks because it is expecting to find an
object to interact with.

2. My models store information in themselves that is specific to the
model. The example is that I have an object "Layout" and it has a file
associated with it. I keep a variable in the Model for the file path
to all layout files as they are associated with an account and
accounts have different storage paths. I can correct this in some
instances and save the file path in the column, but this is not best
practice as paths are hard coded into saved records.

James

On Jul 11, 11:06 am, Chris Peters <ch...@clearcrystalmedia.com> wrote:
> Either that or rename arguments.name to something else, like
> arguments.partial?
>
> Oh yeah, the Partials chapter is posted live. Holding back on the blog

> announcement until I update the rest of the chapters.http://www.cfwheels.org/docs/chapter/partials

>
> On Sat, Jul 11, 2009 at 5:54 AM, Per Djurner <per.djur...@gmail.com> wrote:
> > On 2nd thought, arguments.name (as an object property) would clash with
> > the name argument used to decide what file to include. Maybe it would be
> > better if the object properties and/or record values were made available in
> > arguments.properties (as a struct)?
>

> > On Sat, Jul 11, 2009 at 9:43 AM, Per Djurner <per.djur...@gmail.com>wrote:
>
> >> Actually, you should be able to use the same partial for both queries and

> >> objects.All object properties / record values are passed in as arguments

> >> to the partial so you can reference them with arguments.name,
> >> arguments.email etc.
>
> >> More info here:
> >>http://code.google.com/p/cfwheels/wiki/Partials
>
> >> / Per
>

> >> On Sat, Jul 11, 2009 at 9:22 AM, Russ Johnson <russ.cfco...@gmail.com>wrote:
>
> >>> I think what James is getting at is this...
> >>> If I have a partial that displays a single user record, I have to
> >>> reference all of the users attributes like user.name, user.email...
>
> >>> Well, if I do a findAll() on my users, we cant include that partial and
> >>> pass the query to it do display each user because of the way your reference
> >>> your variables for the object vs. a query... so I would have to create 2
> >>> identical partials, one for rendering a single object and one for rendering
> >>> a single record from a query.
>
> >>> Does that make sense? This may or may not be what James is alluding to,
> >>> just my interpretation...
>
> >>> - Russ
>
> >>> On Jul 11, 2009, at 3:17 AM, Per Djurner wrote:
>
> >>> James, can you give me a real-world code example of where you are feeling

> >>> this pain?Would make it easier for me to think of alternatives.

> >>> Thanks.
>
> >>> On Sat, Jul 11, 2009 at 5:54 AM, Chris Peters <
> >>> ch...@clearcrystalmedia.com> wrote:
>
> >>>> The problem that everyone is describing is that even having an array of
> >>>> objects to begin with is where the performance issues are.
>
> >>>> It looks like the Hibernate support in CF9/Railo could *potentially*
> >>>> solve this problem. (I think I heard that Railo will be working on adding
> >>>> Hibernate to their engine too.) Read Ben Forta's recent blog entry about CF9
> >>>> ORM. Apparently it returns an array of objects, and one would think that
> >>>> this would be at good performance...
>

> >>>>http://forta.com/blog/index.cfm/2009/7/7/ORM-Rethinking-ColdFusion-Da...

[wfisk]

Hi James,

I have had the same problem as you, and I have just solved it by
writing code in the view, to loop round the view and then create a new
model object for each record. So quite inefficient because (1) I
already have the data loaded and (2) I am loading each record
individually. And also I didn't really like it because I was loading
data in the view - but it worked.

However it did make me think there should be a method that can create
a model object from a record in a query. So, if my query is called
"students" I could be able to write
<cfset student = model("Student").createFromRecord(students) />
and maybe something like this is possible I didn't give it much more
time.

I also solved the second problem you raised simple by defining a
helper function (Which takes the query as a parameter). Again not so
nice but it did the job for me.

William

[wfisk]

One of the (many) things that I like about Wheels is that the model
returns multiple items as a query. Even if the performance was
improved it will still be an issue (see this post for example
http://blog.strikefish.com/blog/index.cfm/2008/12/12/ColdFusion-createObject-Component-and-Pathing-Performance
)

99% of the time (for me anyway) I just want to show some of the values
of each record in a list or a table.

William

[Per Djurner]

I'm pretty sure issue #63 will solve problem #2 (you would be able to calculate the property from a function and within that function access any variable in the model).

[Per Djurner]

There is now a "returnAs" argument on the findAll function (in SVN).

Set it to "objects" to get back an array of objects instead of a query.

This should definitely be used with caution though (for performance reasons mainly).

I would only recommend using it if you need to create/edit multiple objects in one form.

[wfisk]

Per has provided a solution to this with the returnAs option.

Alternatively you can use the function $createInstance (one of the
methods of a model object). I wasn't looking at my code when I wrote
the above and I realise that in fact I have been using it and it seems
to work fine. I have wrapped it up in another function which I called
createModelObject.

In your view file you simply loop over your query and then call
createModelObject as the first instruction. For example
<cfloop query="students">
<cfset student=model("Student").createModelObject( students )>
...
some code using formHelpers
...
</cfloop>

The method createModelObject needs to be declared in Model.cfc. and
looks like this:
<cffunction name="createModelObject" returntype="any" access="public"
output="false">
<cfargument name="dataset" type="query" required="true">
<cfreturn $createInstance(
properties = arguments.dataset,
row = dataset.currentRow,
persisted = true ) />
</cffunction>

William