Persisting objects across requests (not redirecting)

[Brian H.]

It has been a couple of years since I've last tackled this request so
I would like to see if such a feature has been added to M2 before I
roll my own.

I have to implement a multiple-step wizard, setting properties in an
ORM object across multiple requests until a confirm screen, and then a
final orm save to the database.

How I've accomplished this in the past was to roll a small session
persistence system into my session facade:

persistID = sessionFacade.persist(object)
object = sessionFacade.getPersisted(persistID)

Then I have a M2 plugin which watches the event scope, and if it finds
an event-arg named "persistId" then it will automatically pull the
object with that ID into the event scope with the object's original
name. The persistID is just a hidden field passed between form posts.

Not the most complex solution, and it works, but wondering what else
people are doing to solve this requirement. I know the M2 has redirect
level persistence, but I am not doing a redirect.

Thanks for the input!

-Brian

[Brian Klaas]

I'm not aware of this functionality being part of M2, even with the latest build of 1.9.

I think the plugin (or filter) route you are currently using is the way to go. It's what I do myself.

brian

[Joe Bodell]

Is it out of the question to persist the object in the database? It is an ORM object, after all, but it seems like there's a tradeoff between the time it takes to update an "in-progress" record on a few requests in a sequence and the time it takes to persist the entire ORM object in the session scope. If you write the in-progress data to a table that looks like the "complete" data but has a different key, then all you need to persist in the event args is the key value on the in-progress record, and an event redirect including that ID will cover you.

Just a thought...

--Joe

-Brian

--
To post to this group, send email to mach-ii-for...@googlegroups.com
For more options and to unsubscribe, visit this group at http://groups.google.com/group/mach-ii-for-coldfusion?hl=en

SVN: http://svn.mach-ii.com/machii/
Wiki / Documentation / Tickets: http://trac.mach-ii.com/machii/

[Brian H.]

@Brian, good to know that my method isn't off the wall : ) Thanks
for instilling me with confidence.

@Joe, Since the object would be in an invalid state until the end of
the wizard, I did not want to persist the object to it's regular
table. You are suggesting that I store in-progress entities in a
different table? I'm not even sure how to convince ORM to do that.
Unless I created a new entity type just for the WIP, and then copy it
over to the real entity, save the real entity, then delete the WIP. If
I was good, I might try to make use of Table-Per-Class and define the
two entites Entity, and EntityWIP, and they would technically share
the same table, but the EntityWIP would have it's validation disabled,
and ORM's TPC/discriminator would naturally filter out the WIP
entities from all getEntity calls. Slick. Not sure of the gotchas.

I like storing the in-progress entity in the session since session
handling will automatically clean up that memory space. I do -NOT-
like storing the entity in the session because then it makes
clustering all that much more difficult in the future. Choices...

Thanks guys.

-Brian

[Joe Bodell]

Yeah, you definitely have some options with a DB-persistent model -- a different table for WIP data would solve the issue, but then you have to make sure you remove it once it's ready to go to the "real" table. In Reactor, aliasing a single table so one "entity" can be the WIP and the other can be the "real" is easy, but I'll admit that I haven't had much opportunity to play with the baked-in ORM in CF9, so I don't know how that would shake out code-wise. I prefer something more persistent than the session, if only because using the session for things other than scalar datatypes gives me the heebie-jeebies. But that's probably more a personal preference thing than anything :-)

[Brian H.]

Hey Joe.

I think your heebie-jeebies are well placed. They eat up memory, and
cause problems when trying to share sessions across a number of
servers. But then it's just so EASY!

I think that Reactor's alias is similar to Hibernate's table-per-
class / discriminator system. We'll see. I think that I am going to
continue on the session path for this app and perhaps look at a DBed
solution in the future.

-Brian