I am interesting about an option to run an action in a moment, when is ending the currently action.
More specifically, I want to run an action for download files from my page and after downloading all files this action is ending (usually behavior - this action is running by CRON).
And now I would like to automatically run the second action. This action will be checking the downloaded files...
Exist any way, how to do?
Thank you a lot,
M.
You cannot render multiple times in one request. HTTP requests can only have one response, so if you did, you would end up with the output concatenated, which would probably not be useful.
If you have controller logic from another action that you want to invoke (which does not include rendering), you can do this by simply calling the other action method, or by factoring the logic you need into a separate method on the controller. If you were trying to share logic among separate controllers, you would need to move this method to your ApplicationController.
Related
I have an action as follows:
SomeActions.doAction1(){
//..dispatch event "started"...
//...do some process....
FewActions.doAnotherAction(); //CAN WE DO THIS
//...do something more....
//..dispatch event "completed"..
}
While the above works with no problems, just wondering, if it is valid according to flux pattern/standard or is there a better way.
Also, I guess calling Actions from Stores are a bad idea. Correct me if I am wrong.
Yes, calling an Action within another Action is a bad practice. Actions should be atomic; all changes in the Stores should be in response to a single action. They should describe one thing that happened in the real world: the user clicked on a button, the server responded with data, the screen refreshed, etc.
Most people get confused by Actions when they are thinking about them as imperative instructions (first do A, then do B) instead of descriptions of what happened and the starting point for reactive processes.
This is why I recommend to people that they name their Action types in the past tense: BUTTON_CLICKED. This reminds the programmer of the fundamentally externally-driven, descriptive nature of Actions.
Actions are like a newspaper that gets delivered to all the stores, describing what happened.
Calling Actions from Stores is almost always the wrong thing to do. I can only think of one exception: when the Store responds to the first Action by starting up an asynchronous process. When the async process completes, you want to fire off a second Action. This is the case with a XHR call to the server. But the better way is to put the XHR handling code into a Utils module. The store can then respond to the first Action by calling a method in the Utils module, and then the Utils module has the code to call the second Action when the server response comes back.
I'm trying to understand Flux pattern.
I believe that in any good design the app should consist of relatively independent and universal (and thus reusable) components glued together by specific application logic.
In Flux there are domain-specific Stores encapsulating data and domain logic. These could be possibly reused in another application for the same domain.
I assume there should also be application-specific Store(s) holding app state and logic. This is the glue.
Now, I try to apply this to imaginary "GPS Tracker" app:
...
When a user clicks [Stop Tracking] button, corresponding ViewController raises STOP_CLICK.
AppState.on(STOP_CLICK):
dispatch(STOP_GEOLOCATION)
dispatch(STOP_TRACKING)
GeolocationService.on(STOP_GEOLOCATION):
stopGPS(); this.on = false; emit('change')
TrackStore.on(STOP_TRACKING):
saveTrack(); calcStatistics(); this.tracking = false; emit('change')
dispatch(START_UPLOAD)
So, I've got an event snowball.
It is said that in Flux one Action should not raise another.
But I do not understand how this could be done.
I think user actions can't go directly to domain Stores as these should be UI-agnostic.
Rather, AppState (or wherever the app logic lives) should translate user actions into domain actions.
How to redesign this the Flux way?
Where should application logic go?
Is that correct to try to keep domain Stores independent of the app logic?
Where is the place for "services"?
Thank you.
All of the application logic should live in the stores. They decide how they should respond to a particular action, if at all.
Stores have no setters. The only way into the stores is via a dispatched action, through the callback the store registered with the dispatcher.
Actions are not setters. Try not to think of them as such. Actions should simply report on something that happened in the real world: the user interacted with the UI in a certain way, the server responded in a certain way, etc.
This looks a lot like setter-thinking to me:
dispatch(STOP_GEOLOCATION)
dispatch(STOP_TRACKING)
Instead, dispatch the thing that actually happened: STOP_TRACKING_BUTTON_CLICKED (or TRACKING_STOPPED, if you want to be UI-agnostic). And then let the stores figure out what to do about it. All the stores will receive that action, and they can all respond to it, if needed. The code you have responding to two different actions should be responding to the same action.
Often, when we find that we want dispatch within a dispatch, we simply need to back up to the original thing that happened and make the entire application respond to that.
Does the ZF2 forward() controller plugin fire off a new request cycle? Or part thereof?
I am writing a ZF2 MVC application with widgetized content. The widgetized content is exposed via its own controller action because sometimes I need to hit it with ajax.
When I need to incorporate the widgetized content as a sub-view of another action (i.e. on a full page load), that action is using the forward() plugin to get the widgetized content. If it's going to introduce a significant overhead though I will go straight to the service layer instead (even though that approach is less DRY).
I realise that a performance test will answer this question for me, but I'm a few weeks away from being able to run such a test.
EDIT: when I say 'new request cycle', I mean the ZF2 MVC request cycle, i.e. route, dispatch, etc. Intuitively I would doubt it fires route a second time, but it could start the cycle from dispatch. I'm asking the question because I know that in ZF1 it triggered a who second cycle, which was a real performance drain.
There are two options to "forward". Understand php is as server side language a processor to grab an incoming request and return a response.
That said, the first "forward" uses in-framework forwarding. This means there is only one request and one response. Internally the framework calls one controller action and then another one. Zend Framework calls this method forward.
The second "forward" is a real redirect, where the first response contains a Location header and the 302 http status code. This results in a second request and consecutively in a second response. Zend Framework calls this method redirect.
So with above, the forward you talk about in your question does not involve any sessions or route match parameters, since the second call to an action is within the same php process, so all variables are already known.
Is it possible to forward data to another controller/action in Zend 2?
My code
https://gist.github.com/ButuzGOL/707d1605f63eef55e4af
So when I get sign-in success callback I want to make redirect,
redirect works through dispatcher too.
And I am getting Dispatch.dispatch(...): Cannot dispatch in the middle of a dispatch.
Is there any hack to call action in the middle ?
I don't see where in the gist that you posted you are doing the redirect. I only see the AUTH_SIGNIN and AUTH_SIGNIN_SUCCESS actions, and they look pretty straightforward.
But no, there is no hack to create an action in the middle of a dispatch, and this is by design. Actions are not supposed to be things that cause a change. They are supposed to be like a newspaper that informs the application of a change in the outside world, and then the application responds to that news. The stores cause changes in themselves. Actions just inform them.
If you have this error, then you need to back up and look at how you're handling the original action. Most often, you can set up your application to respond to the original action, accomplish everything you need to do, and avoid trying to create a second action.
You can make it work by "scheduling" the next action instead of calling it directly, here is an example code:
// instead of doing this
Dispatcher.dispatch(...);
// go like this
setTimeout(function() {
Dispatcher.dispatch(...);
}, 1);
This will cause your next dispatch to be called later out of the current dispatch process, and no error will happen.
If your dispatch code is on a callback any kind of other async operation that will work as well (for example in a response for an Ajax request).
I'm using this style to make some forms respond to generic data here and I'm facing no issue, at least the way I'm using it.
you can user the "defer" option in the dispatcher.
In your case it would be like:
Dispatcher.dispatch.defer(...);
You can check if the dispatcher is dispatching, such as:
if(!MyDispatcher.isDispatching()) {
MyDispatcher.dispatch({...});
}
I have a fairly complex app, with lots of different components that update frequently. For example, a clock.
Is it possible to call $apply / $digest on only a subsection of the page at once? I don't want to call every watcher on the page for every single clock tick, for example.
I know I can achieve this by bypassing $scope.$apply entirely, and just updating the clock elements manually in a directive. Is there any hope for me?
EDIT: Actually, it looks like MAYBE what I want is to dun $digest, starting on the scope I want to check, rather than $apply, since $apply kicks off the digest on $rootScope. Is this a valid way to do it?
http://plnkr.co/edit/C8aOswf46qx2GoD5uL9Y?p=preview
If your components are really decoupled, you could isolate those that generate frequent updates in their own angular app instance. They will have independent digest cycles.
Your apps can still communicate but there is a bit more overhead involved.
In order to have 2 apps, you have to manually start the applications (use bootstrap instead of ng-app).
See this example: http://plnkr.co/edit/K3bnACFi79g5Kh0kFS66?p=preview
Whenever you call $scope.$apply() it also calls $apply() on all scopes that fall within that scope. If you want to call $apply() on a limited section of a page then that section needs to have it's own scope, which you can do by adding a controller to that section of the page. Then you can use that controller to update the scopes within that section of the page using $scope.apply() on your section controller.
-- Edit --
See comments below for additional details about the differences between $apply and $digest.
Also see:
http://jimhoskins.com/2012/12/17/angularjs-and-apply.html
https://groups.google.com/forum/#!topic/angular/SSj61VOBBSc