Thread: Bugs with flash persistence
Created on: 08/26/09 09:32 PM Replies: 10
tonyg General Joined: 08/13/07 Posts: 90	Bugs with flash persistence 08/26/09 9:32 PM I noticed from the SVN timeline that you recently added Flash ram objects. Since those changes, I've been getting some bugs. On ColdFusion 8, the framework doesn't even load, I get this error: The value returned from the getFlashScope function is not of type coldbox.system.web.flash.AbstractFlashScope. If the component name is specified as a return type, its possible that a definition file for the component cannot be found or is not accessible. The error occurred in /Users/tony/Sites/frameworks/coldbox_3/system/Plugin.cfc: line 30 Called from /Users/tony/Sites/frameworks/coldbox_3/system/plugins/XMLParser.cfc: line 26 Called from /Users/tony/Sites/frameworks/coldbox_3/system/services/PluginService.cfc: line 50 Called from /Users/tony/Sites/frameworks/coldbox_3/system/services/PluginService.cfc: line 90 Called from /Users/tony/Sites/frameworks/coldbox_3/system/Controller.cfc: line 301 Called from /Users/tony/Sites/frameworks/coldbox_3/system/services/LoaderService.cfc: line 56 Called from /Users/tony/Sites/frameworks/coldbox_3/system/Coldbox.cfc: line 65 Called from /Users/tony/Sites/dev.coldbox/Application.cfc: line 35 28 :          variables.logBox = arguments.controller.getLogBox(); 29 :          // Register Flash RAM 30 :          variables.flash = arguments.controller.getRequestService().getFlashScope(); 31 :           32 :          // Prepare a Plugin properties In Railo 3.1, the framework loads fine. However, the persistVariables() function doesn't seem to work if I use it in a view (works fine in an eventhandler). For example, if I set a value in the RC (in the event) and then in the corresponding view for that event I say persistVariables("myvariable") and then if I have a form on the page, the event that handles that form doesn't have access to the variable I tried to persist from the view (it used to work before the flash ram object changes)
	Link | Top | Bottom
lmajano Veteran Master Joined: 01/29/05 Posts: 1209	RE: Bugs with flash persistence 08/27/09 12:17 AM Thanks Tony, I will investigate, this is a big enhancement and will add more flexibility to our flash ram. Also, the persist variables() methods and the persist arguments are to be deprecated in future versions in order to use the new flash ram scope and objects. Each handler, layouts, views, plugin, interceptor now has a new variables scope object called "flash" which maps to the abstract flash object. You can put, putAll, get, exists, remove, etc on it like a normal structure. You can even get objects from it as the new flash ram capabilities inflate them into the request collection and also into the new flash object. This is much more descriptive than just using request collection variables that seem to appear out of ether. This way, it is a defined contract that when you see the scope "flash" we are talking about flash ram persistence. Thanks and will post my updates soon. Luis Majano
	Link | Top | Bottom
lmajano Veteran Master Joined: 01/29/05 Posts: 1209	RE: Bugs with flash persistence 08/27/09 12:36 AM Hmm, that is interesting, at the moment the only trigger for serializing data to the flash storage is when a relocation is triggered in order to avoid going to the flash storage everytime you want to store something on it. Basically, as of now, since you are doing this in a way that I did not think about, you can use the "saveFlash()" method on the flash object. This basically sends all the data to the flash storage for saving. As of now, the flash storage gets saved when you do a setnextevent, setnextroute or relocate(). So if you are doing something where you flash, present, then relocate. You will have to do this manually as of now, until I can think of a more elegant solution. Maybe adding an argument to the put(), putAll(), persistRC() methods that says: "saveNow or saveImmediate". Example: flash.persistRC(include="hello",saveNow="true") Luis Majano
	Link | Top | Bottom
lmajano Veteran Master Joined: 01/29/05 Posts: 1209	RE: Bugs with flash persistence 08/27/09 12:38 AM Hmm, maybe the deprecated methods should send in the flag of "saveNow" to true to keep backwards compatibility. And the new flash scope method remains intact to be used by the developer? How does this sound? Fix is on SVN also. Luis Majano
	Link | Top | Bottom
tonyg General Joined: 08/13/07 Posts: 90	RE: Bugs with flash persistence 08/27/09 7:05 AM Hi Luis, Thanks for the info on the new flash persistence stuff. I think it will give us more power and flexibility and you're right in that it will make working with flash persistence more descriptive. I'll play with this when I have some time later and let you know how it goes. Regarding backwards compatibility for the deprecated methods, I don't mind refactoring to the new API, but I do think that it would be a good idea to make it so the deprecated methods work like they used to (so having the "saveNow" set to true) in case other people used the persistVariables() method they way I have.
	Link | Top | Bottom
tonyg General Joined: 08/13/07 Posts: 90	RE: Bugs with flash persistence 08/27/09 10:40 PM I've been playing around with this and I've encountered another strange behavior with flash persistence. First I'll set up some test code. So my event, "general.vwForm" just renders this view: <cfoutput> String: #event.getValue('testString','')#<br /> <form action="index.cfm?event=general.processform" method="post"> Input String: <input type="text" name="testString" value="" /> <input type="submit" value="Submit" /> </form> </cfoutput> This is the "general.processform" event: <cffunction name="processform" returntype="void" output="false" hint="Do Something">    <cfargument name="event" required="true">    <cfset setNextEvent(event="general.vwForm",persist="testString") /> </cffunction> So basically, you enter some text in the textbox. When you submit, it takes you to the "general.processform" event, where it persists the rc.testString and then takes you back to the form where the string you entered is displayed. This works as expected. If you keep entering new strings, it keeps updating the string in the form page. However, if instead of hardcoding the event to redirect to, you set that in an RC variable in the original event and then use the flash object to persist and retrieve it, it makes the form field value "permanently" persist. To see what I mean, change the event handler for the display of the form, "general.vwForm", to this: <cffunction name="vwForm" returntype="void" output="false">    <cfargument name="event" required="true">    <cfset var rc = event.getCollection()> <!--- put the event to redirect back to (this event) in the request collection --->       <cfset rc.xeFormRedirect = "general.vwForm" />    <cfset Event.setView("home")> </cffunction> Then at the top of the form vew, add this line: <cfset flash.persistRC(include='xeFormRedirect',saveNow="true") /> So we're persisting the variable with the event name to redirect to in the flash ram. Then change the setNextEvent() call in the "general.processForm" event to <cfset setNextEvent(event=flash.get('xeFormRedirect'),persist="testString") /> So basically instead of hardcoding the event to go to, we're grabbing it from the flash ram. (Make sure to reinit the framework after the changes) What happens now is that after you enter a string in the text box and submit. The value for rc.testString appears to be PERMANENTLY set. Typing in new values and submitting the form doesn't change the output and neither does reinitializing the framework! I thought this was pretty weird and I'm not really sure how using the flash object for a totally different variable would affect the rc.teststring variable.
	Link | Top | Bottom
lmajano Veteran Master Joined: 01/29/05 Posts: 1209	RE: Bugs with flash persistence 08/27/09 11:11 PM HI Tony, this is correct and it happened before. Why? Well, because the request collection gets created first and then the Flash RAM is inflated. Thus, overriding any values in the request collection. This behavior was like this before and it should remain like that, because you rely mostly on the flash variables than what could potentially come in via URL/FORM or remote. On another note, why would you want to persist the value you are submitting? Makes no sense to me unless you are sending them elsewhere, if not, the value will always be submitted. Luis Majano
	Link | Top | Bottom
lmajano Veteran Master Joined: 01/29/05 Posts: 1209	RE: Bugs with flash persistence 08/27/09 11:16 PM Also, The complete behavior of the flash scope can be changed, enhanced and altered. This is totally extensible now for 3.0. You can basically create your own flash scope and then use the "FlashURLPersistScope" setting and map it to the class path of your flash scope. For example, let's say you want to NOT override the behavior of the rc. Then just create a new component, put it for example in your model folder under a folder called flash. /model /flash /MySessionFlashScope.cfc Then make sure this cfc extends from the SessionFlash.cfc, again this is an example. "coldbox.system.web.flash.SessionFlash" Then override the "inflateFlash" method and you could do this: <cffunction name="inflateFlash" output="false" access="public" returntype="void" hint="Inflate the flash storage into the request collection and request temp storage"> <cfscript> var event = getController().getRequestService().getContext(); var flash = getFlash();           // Append flash into request collection.          event.collectionAppend(collection=flash,overwrite=false); // Append flash to temp flash request storage putAll(flash);           // Clear Flash Storage clearFlash(); </cfscript> </cffunction> This is why 3.0 is so powerful with flash scopes, it is completely CUSTOMIZABLE Luis Majano
	Link | Top | Bottom
tonyg General Joined: 08/13/07 Posts: 90	RE: Bugs with flash persistence 08/28/09 6:56 AM Hmmm... I'm going to have to try to wrap my head around what you're saying about the flash ram overriding the request collection because I'm not sure I quite understand. Why would I want to perisist the value I'm submitting with the form, you ask? Well, the code above was just for testing purposes. But someone could use that approach if, for example, form validation fails in the processform event and you want to redirect your user back to the form. Persisting the form values would enable you to pre-populate your form fields so the user doesn't have ot fill everything out again. I know there are various ways one could accompish that and the "persist" argument for setNextEvent is going to be deprecated anyway, as you say. But I just think it was unusual that it gave me very different behavior depending on whether the event name in the setNextEvent() call was hardcoded or came from a variable that was persisted in the flash ram. Like I said, even fwreinit=1 didn't clear the testString variable from the request collection. Should that be expected?
	Link | Top | Bottom
lmajano Veteran Master Joined: 01/29/05 Posts: 1209	RE: Bugs with flash persistence 08/28/09 2:09 PM Thanks Tony, I finally saw what you meant and yes I made a fix on this now. It should work as normal. However, we added some extra bonus methods: keep([keys]) discard([keys]) Once the flash ram get's inflated in a request it is cleared right. Also, the contents are placed in the request collection and the temp flash storage. Those that are placed in the temp flash storage are MARKED for discard as they have been inflated already. So the next request will clear them out or a simple refresh, thus the flash part. However, if you would like to keep one, some or all of these inflated variables so they survive another request, you can use the flash.keep() or flash.keep("myMessage") methods. This tells the flash ram mechanisms to persist them for another relocation. You can build flows with these mechanisms and have the ability to control what persists and what can be discarded. Discard does the inverse. maybe you want to discard all flash variables or just one. Then they are MARKED for removal in comparison to the remove() method which basically does a hard delete. Enjoy!! Luis Majano
	Link | Top | Bottom
tonyg General Joined: 08/13/07 Posts: 90	RE: Bugs with flash persistence 08/28/09 10:13 PM Thanks! Wow, seems like there's a lot's of new stuff going on with this release. I'll keep trying to test things out.
	Link | Top | Bottom