I'm facing a strange problem in my project. My actions are getting old param values instead of the actual values which are in Request.Params. I created a HomeController.Echo(string text) action to illustrate it (see screenshot). When I call the action for the first time like "Home/Echo?text=aaa" everything works fine. When I call the same action second time with different text value ("Home/Echo/text=bbb"), I get the old "aaa" value again in my action "text" parameter. Strange think is that Request.Params contains the right "bbb" value.
I'm thinking if there's something I could break myself, but can't figure out anything. I'm serving controllers from IoC container, I overrided ControllerActionInvoker.InvokeActionMethodWithFilters method (to inject dependencies into filters from IoC) and I'm handling HttpApplication.AuthenticateRequest. Im'not working with params/binding anyhow in any of these...
screenshot
The problem was caused by some threading issues probably - I forgot to register controllers in my IoC container with per-request lifecycle (they were registered as singletons).
Have you debugged through the application to see where the value is getting switched out. A simple watch on the text variable (whatever you call it in the code) should yield where the variable gets changed. Without code to run through, I have no clue where it is happening.
I would say write a test, but there is still a possibility of UI interfering here. If you find where in the code it is changing, then write a test to confirm the bug and start whacking at it.
I suggest you to start commenting all the methods you overrode until you isolate the problem. In worst case you will get to the point where the ASP.NET MVC wizard left your project when you created it and where parameter binding definitely worked.
Related
I switched to vaadin.eagerServerLoad=true in order to fix the issue with incorrect HTTP status code (I need to return 404 when it is needed).
I also noticed one issue which potentially maybe related to the vaadin.eagerServerLoad=true. On the views with com.vaadin.flow.router.BeforeEnterObserver the method BeforeEnterObserver.beforeEnter is executed twice when I for the very first time enter the page (please note that there is no such issue when I navigate between views in the already constructed UI). This is why now as a temporal fix I have to call removeAll() as a first line in the beforeEnter method.
What am I doing wrong and how to fix it?
I have an application that uses a combination of ContentService.Saved & ContentService.Saving to extend Umbraco to manage content.
I have two websites in one Umbraco installation I am using those methods to keep content up to date in different parts of the tree.
So far I have got everything working the way I wanted to.
Now I want to add a feature that: depending on which Umbraco User is logged in, will either publish the content or simply send it for approval.
So I have changed some lines of code from:
cs.SaveAndPublishWithStatus(savedNode, 0, false)
To this:
cs.SendToPublication(savedNode);
Now the problem that I am finding is that unlike the SaveAndPublishWithStatus() method, the cs.SendToPublication(); doesn't have the option of passing false so that a save event is not raised. So I get into an infinite loop.
When I attach the debugger and manually stop the infinite loop the first time it calls cs.SendToPublication(savedNode); I get exactly the behavior I want.
Any ideas about how I can get round this problem? Is there a different method that I should be using?
You are correct in saying that it currently isn't possible to set raiseEvents to false when sending an item to publication - that's a problem.
I've added that overload in v. 7.6 (http://issues.umbraco.org/issue/U4-9490).
However considering that you need this now, an interim solution could be that you make sure your code is only run once when triggered by the .Saved / .Saving events.
One way to do this would be to check the last saved date (UpdateDate) in your code. If the content was saved within the last second of the current save operation, you know that this is a save event triggered by the save happening in SendToPublication action. Then you also know that the item has already been sent to publication and that this doesn't need to be done again - thereby preventing the endless loop from happening.
I added code which I thought would do the job, but it looks like GrailsLayoutView is somehow interfering with it.
I have a plugin with the following code:
def watchedResources = "file:./src/main/templates/scaffolding/*.gsp"
void onChange(Map<String, Object> event) {
applicationContext.getBean("jspViewResolver").innerViewResolver.generatedViewCache.clear()
}
This seems to do what I expect and the ScaffoldingViewResolver regenerates the view rather than pulling it from its cache. The correctly rendered view then is passed up, but it looks like GrailsLayoutView.renderTemplate calls obtainContent which returns the original content of the scaffolded view rather than the updated content. It then uses the wrong content in the call to decorator.render and all hope of seeing the updated template is lost.
For anyone familiar with this code, am I correctly interpreting the problem and do you know of some way I can get past this? I have some complex scaffolding templates that I would like to work on, but I'm going to give it up if I have to shutdown grails every time I make a change.
Thank you.
I've got a very old php application (1999) that has been worked on during the last ten years. At this point the app starts to show it's age so i'm in te progress of migrating to a "new" framework, symfony 1.4. But since the app is very large, i cannot do this at once. So i'm planning to wrap the old app into the new symfony app, and convert functionality by functionality.
First step in this transition was making the old app appear in the new symfony app. So, i've created the "frontend" application, added a "legacy" module, made it the default homepage, and i've put everyhting i had in my index.php (all pages went through this index.php) in the indexSuccess.php file for the indexAction. I've added the code in the "view" because there are also functions in it and changing that setup would take me more time than i want to spend on the old app.
Unfortunately i've now got an issue with global variables. Let me give you an example (i would have never made this register function like this, but it is, so please look past that.
$session = new ps_session;
$demo = "this is a demo variable";
$session->register('demo');
In ps_session i have this method
public function register($var) {
global $$var;
$_SESSION [$var] = $$var;
}
So it should put the content of $demo in a session var named "demo". Clever right :) Anyway, var_dumping shows me the that $$var is "null" and $demo is filled if i var_dump before and after calling the function. Exact same code without symfony and it returns the correct content.
What am i missing? The global call is spread out in all area's of this massive app so i really don't want to switch to something else, so i'm hoping for a quick fix :)
Maybe relevant, the all code except the index.php content are in frontend/lib/legacy/ folder, the index is in frontend/modules/legacy/ (if there is some scope issue i'm missing)
I think that since your indexSuccess.php file is included inside a function (more precisely, here : lib/vendor/symfony/lib/view/sfPHPView.class.php:185 ), this can't work, because $demo is no longer in the global scope. I don't see any easy workaround for this...
I think you should create a legacy folder in /web , and use routing to redirect to it if the url corresponds to something not migrated yet.
I went with putting the entire old site under web/legacy and redirecting from the default index action to the legacy folder. Most of the url's were made by mod_rewrite so easily fixed. The other url's went through a function so fixing was ok, and only a few were hardcoded. To make it totally transparant, i only need to redo the homepage to start from, so i don't have a visible /legacy/ in my url. Thanks for the help!
I agree with greg0ire that this is an issue with the way sfPHPView includes indexSuccess.
Could you simply require index.php in the default/index action?
there is this code below in sfDoctrineGuardPlugin.
$a = sfConfig::get('app_sf_guard_plugin_success_signin_url');
var_dump($a);
$signinUrl = sfConfig::get('app_sf_guard_plugin_success_signin_url', $user->getReferer($request->getReferer()));
var_dump($signinUrl);
var_dump($user->getReferer($request->getReferer()));
It prints this:
null
string
'http://rs3.localhost/frontend_dev.php/'
(length=38)
string
'http://rs3.localhost/frontend_dev.php/miembros' (length=46)
I don't know why the the second and the third lines are different..any idea?
Regards
Javi
Weird. Spooky.
I wonder if maybe the two calls to getReferer() are in different contexts? Maybe the first (as the second arg to sfConfig::get()) implicitly uses __toString() whereas when you use var_dump(), maybe it's printing the raw value of the referer object?
Hrmm... the API says getReferer() returns a string, so that's probably not it.
What are you trying to do, BTW? Is it not honoring your app_sf_guard_plugin_success_signin_url setting from app.yml?
sfDoctrineGuardPlugin sets a referer attribute in the user, so that it can redirect back to the page originally requested. When you call getReferer it removes the attribute. (This is causing bugs for me, which is what brought me here.)
yitznewton pointed me towards a solution. The sfGuardSecurityUser class uses a method setReferer that saves a referer attribute but only if one is not yet set.
If somehow you manage to get to the executeSignin method in the sfGuard actions twice only the first referer attribute will be saved, this means that the second time the referer in the request and the referer in the user attribute can be different.
The getReferer method removes that attribute, and falls back to the request referer when the attribute is not set. this explains why calling $user->getReferer($request->getReferer()) twice returns different values sometimes.
The solution i found was to overwrite the setReferer method of the sfGuardSecurityUser in the myUser class:
public function setReferer($referer) {
$this->setAttribute('referer', $referer);
}
So far i have not found any side effects, this change ensures the user attribute will allways be the most recent, however there has to be a reason to explain why the symfony folk chose to implement this as it was.
Ive tested this by switching between apps on the login screen, allowing the session to die, killing the session manually and normally using the application and so far i have not found any side effects.