Losing persist on redirect

[jamarl]

Hi everyone.

My team and I just upgraded to Machii 1.5. In using the new persist
feature with redirect, we've ran into an issue concerning information
persistence. We persist and object over a redirect. The initial run
through works fine, however, should the user refresh the page, the
information is lost. Has anyone else experienced this 'feature'? If
so, does anyone know a fix or a work around to this?

Thanks everyone,

Jamarl

[Peter J. Farrell]

jamarl said the following on 11/12/2007 4:00 PM:

It's not a feature -- it's how it works. Redirect only persists data
for the time between redirect and the request for the next page. It's
not a long term storage option, but a "flash" scope -- since redirecting
stops the execution of the current request, tells the browser to request
a new resource and another CF request starts. Think of it as a way to
continue event data between the two requests -- making it feel like
"one" request. If you want data to stick around longer, you'll have to
write something to stick it ino the session scope etc. on the other side
of the redirect.

.pjf

[jamarl]

Hi Peter.

Thanks for the swift response.

[Hussein Grant]

Hi Peter,

Wouldn't it be more useful if the framework had an option to make the
session data stick around instead of writing custom code to accomplish
this?

Thanks,
Hussein

[Matt Woodward]

The framework shouldn't be sticking stuff in the session permanently
for you. Once you get beyond the scope of a single request using the
flash scope, how is Mach-II going to know when you're done with it? If
you're concerned about the data persisting beyond the scope of a
single request, it doesn't seem at all unusual to me to put the onus
on the developer to handle that.

--
Matt Woodward
mpwoo...@gmail.com
http://www.mattwoodward.com

[Hussein Grant]

Hi Matt,

Thanks for the reply. I perfectly understand your point and the
concept behind the current redirect persist function, but I reckoned
it could of been more user friendly if persistence beyond the first
request can be stored and expired by framework via a simple command
directive. Maybe I am looking at this the wrong way.
I personally don't mind writing a component to handle this but I
thought it would have been an excellent option to have. Again I could
be missing the point. I do from time to time. :)

Thanks,
Hussein

On Nov 13, 11:41 am, "Matt Woodward" <mpwoodw...@gmail.com> wrote:
> The framework shouldn't be sticking stuff in the session permanently
> for you. Once you get beyond the scope of a single request using the
> flash scope, how is Mach-II going to know when you're done with it? If
> you're concerned about the data persisting beyond the scope of a
> single request, it doesn't seem at all unusual to me to put the onus
> on the developer to handle that.
>

> mpwoodw...@gmail.comhttp://www.mattwoodward.com

[Matt Woodward]

Well, I guess my point is if you have to tell Mach-II you want to put
it in the session permanently (well, for the duration of the session
at any rate), and you also have to tell Mach-II when you'd want it
removed, then Mach-II is just playing middle man in that process and
isn't making your development life any easier really. Being able to
say to Mach-II "keep track of this for the duration of the request"
makes sense. Having to say to Mach-II "keep track of this until I tell
you otherwise" and then at some later time having to say "get rid of
that now" doesn't make sense to me. Either you'd have to give Mach-II
the name of a variable to put in the session scope, or Mach-II would
have to tell you what name it gave the variable and you'd have to keep
track of that somehow ... I'm just not seeing the benefit or how this
would work that would be simpler than the developer just sticking it
in session scope and clearing it out later if they so desire.

Of course I could be missing the point as well, and to me it's always
good to bring this kind of stuff up. You never know what might come
out of the proverbial "You know what would be cool ..." questions. ;-)

--

[Peter J. Farrell]

Hussein Grant said the following on 11/13/2007 10:58 AM:

> Hi Matt,
>
> Thanks for the reply. I perfectly understand your point and the
> concept behind the current redirect persist function, but I reckoned
> it could of been more user friendly if persistence beyond the first
> request can be stored and expired by framework via a simple command
> directive. Maybe I am looking at this the wrong way.
> I personally don't mind writing a component to handle this but I
> thought it would have been an excellent option to have. Again I could
> be missing the point. I do from time to time. :)
>

I think that an enhancement like this would be hard to implement in a
manner that would satisfy 90% of developers which is typically my
threshold when thinking about new features. A few questions immediately
come up in my mind if this was to be added (and I'm going to side with
Matt on this one)...

1. What happens if the resource you requested no longer exists? Does an
exception be generated? (I would think so). Wouldn't you rather have
the option to announce another event (such as starting a process over)
if the resource does not exists? This makes it already harder.
2. Where does this information get stored and how do you access it? An
API would have to be created? With redirect as it stands, you have an
option to key into into the session, application or server scopes. But
due to the black box nature of this, we don't have to provide an API to
getting at the data as it is all managed.
3. Isn't a cflocation (aka redirect command) drastically different than
a feature like this? Redirect's persist features solves the problem
that complex objects cannot be serialized in an URL over a cflocation.
Persist gave the ability to persist transient object across this
barrier. Since a redirect is used to "update" the url in the client's
browser, this makes sense that you may have to persist complex data
types from one request to another -- however long term storage of data
is best left to other means.

I'm sending this email as "thinking out loud" versus "why did you
suggest this"...I love getting suggestions and I don't want to sound
like we're flat out turning suggestion down without reason thus the
email. Hussein, thanks for the suggestion and any more points can be
brought up on list...

Best,
.Peter

[Hussein Grant]

Thanks Matt and Peter. It never crossed my mind for a second that you
guys turn down ideas that are thrown out there.
The Mach-II team has done an outstanding job. Managing, prioritizing
and sometimes rejecting incoming needs and wants is not an easy
undertaking.

My initial response was based on the fact that a simple and harmless
browser refresh by a user could screw up your application unless you
persists the data beyond the first request.
It may be trivial to some but it just didn't sit with me the first
time.

Anyway, I've read both perspectives on the matter and I will sleep on
it some more.

Thanks Again,
Hussein