I'm trying to find the best way to execute some javascript as part of my view function. In the view function I want to create a canvas object and then execute a native function that inserts some data into it based on my model. The parts individually seem easy enough to write, but I'm not sure how to glue them together.
If I simply insert the native call into my view code, presumably it has to produce some HTML (e.g. an empty div) in order to satisfy the type system; perhaps this is the correct thing to do, but it feels a bit hackish. Is there a better, more idiomatic way? Am I even thinking about this in the correct, Elm-ish way?
The best way I have found is to create a Mailbox for this in the main module:
messageMailbox : Signal.Mailbox String
messageMailbox =
Signal.mailbox ""
Then create a port to listen to the signal from that mailbox:
port messsagePort : Signal String
port messsagePort =
messageMailbox.signal
In Js you subscribe to this port:
app.ports.messsagePort.subscribe(function (args) {
...
})
Then you send a message to this mailbox either from your view or your update function (as an effect in case of update):
Signal.send messageMailbox.address message
Related
The situation is like this:
We have a POWL, where I added a toobar-button.
The click on that button opens a FPM-POWL, which I created
with the help of this link
https://sapcodes.com/2016/03/25/powl-in-fpm/....
(INFO: This POWL takes it's data from a standard FBI View).
The new FPM-POWL is properly(??? I hope so, because it gets shown) maintained inside the LPD_CUST in order to start this popup inside the FPM-framework (flag that it should wait, is also set on caller and callee) .
Ok, let's proceed.--
The calling class (feeder class "A", implementing IF_POWL_FEEDER) calls the POPUP like this
DATA(lt_lpd_content) = lr_lpd_handle->mt_content.
READ TABLE lt_lpd_content
REFERENCE INTO DATA(lr_lpd_content)
WITH KEY application_alias = 'ZSRM_GP/BP_POPUP'.
lr_lpd_handle->launch_application( iv_application_id = lr_lpd_content->application_id ).
The user shall simply be able to pick one business partner....
After the user picks a record, and hits a special toolbar-button of the "popup", its feeder class "B"(also implementing IF_POWL_FEEDER) does, what it needs to do inside handle_action and until now... I try to figure out, HOW to pass the record back to the caller class "A"...
Because, unlike expected (because both LPD_CUST entries have the flag set "Synch/await"), the class "A" proceeds processing any code I place after
lr_lpd_handle->launch_application( iv_application_id = lr_lpd_content->application_id ).
And so I suppose, this is "works as designed" and is asynchroneous .
So, my current experiments assumed synchroneous, and I exported any picked business partner's number to a memory ID and closed the "popup".
But I never returned to the caller, where I wanted to start coding the rest of the requirement.
So, my second try is, that I created an event in feeder class "B" (called popup) and a handler for this inside feederclass "A" ( caller ).
Inside the ctor of class "A" I register via "SET HANDLER FOR ALL INSTANCES".... and the tests are just about to start.
But I really hate this approach,.... is there a best practice regarding this ?
I cannot imagine, that I am the only one with this kind of requirement, which, in simple terms, means:
"Listpopup"... and we all know, how simple this is in sapgui...but inside the FPM-POWL-LPD environment... I cannot get it...
EDIT: Maybe I should do something in here to FORCE a blocking popup call ?
Or can I somehow populate the exporting parameters of handle action of the callee to return to the callers handle_action ? Ala POWL_FORWARD_anything ?
Do I understand correctly that after doing $this->dispatcher->forward() or $this->response->redirect() I need to manually ensure that the rest of the code does't get executed? Like below, or am I missing something?
public function signinAction()
{
if ($this->isUserAuthenticated())
{
$this->response->redirect('/profile');
return;
}
// Stuff if he isn't authenticated…
}
After almost a year of working on a hardcore project that uses Phalcon beyond its capacity, I wanted to clarify a few things and answer my own question. To understand how to properly do redirects and forwards you need to understand a little about how the Dispatcher::dispatch method works.
Take a look at the code here, though it's all C mumbo-jumbo to most of us, its really well written and documented. In the nutshell this is what it does:
The dispatcher enters the while loop until the _finished property becomes true or it discovers a recursion.
Inside the loop, it immediately sets that property to true, so when it starts the next iteration it will automatically break.
It then gets the controller / action information, which are originally supplied by the router in the application, and does various checks. Before and after that it also completes a lot of event-related business.
Finally it calls the action method in the controller and updates the _returnedValue property with (guess what!) the returned value.
If during the action call you call Dispatcher::forward method, it will update the _finished property back to false, which will allow the while loop to continue from the step 2 of this list.
So, after you do redirect or forward, you need to ensure that you code doesn't get executed only if that is part of the expected logic. In other words you don't have to return the result of return $this->response->redirect or return $this->dispatcher->forward.
Doing the last might seem convenient, but not very correct and might lead to problems. In 99.9% cases your controller should not return anything. The exception would be when you actually know what you are doing and want to change the behaviour of the rendering process in your application by returning the response object. On top of that your IDE might complain about inconsistent return statements.
To finalise, the correct way to redirect from within the controller:
// Calling redirect only sets the 30X response status. You also should
// disable the view to prevent the unnecessary rendering.
$this->response->redirect('/profile');
$this->view->disable();
// If you are in the middle of something, you probably don't want
// the rest of the code running.
return;
And to forward:
$this->dispatcher->forward(['action' => 'profile']);
// Again, exit if you don't need the rest of the logic.
return;
You need to use it like this:
return $this->response->redirect('/profile');
or
return $this->dispatcher->forward(array(
'action' => 'profile'
))
Use send() like this
public function signinAction()
{
if ($this->isUserAuthenticated())
{
return $this->response->redirect('profile')->send();
}
}
I have problems and questions about this scheduler. I already tried to build and almost finished it. Although, I receive some errors...
What I do?
I create custom lightbox
mapping all the data in to table dbo.bEvent
I used custom eventbox like this : Scheduler.Templates.event_text = "({position_desc})" + " " + "{newrate}"
position_desc is actually from other table 'dbo.zone'
I create Views in SQL Server to retrieve data from 'newrate'. 'newrate' actually is a new attribute after I do some query to change rate "1000 to 1k" which is new rate save '1k'.
the views that I create by joining table "dbo.zone and dbo.bEvent"
Problem is?
when I save a new data or insert or update new data. my event box just give me '(Undefine)undefine'
all the data that i put in lightbox is save in dbo.bEvent
after I resfresh the page using f5 or navigate to next page or previous page then the data is updated.
Here i attach some screenshot. Thanks in advance
http://s1319.photobucket.com/user/matpyam/library/?sort=3&page=1
If you save the changes as described here http://scheduler-net.com/docs/lightbox.html#define_crud_logic ,
note that the method uses SchedulerFormResponseScript class to render the response.
Constructor takes instance of the event class to be returned to the client. Values of that event will be applied to the related event on the client-side
return (new SchedulerFormResponseScript(action, changedEvent));
make sure object that you send (changedEvent) has all data properties initialized. Basically the event should have the same data as when it is loaded from the Data action.
Alternative solution, which may be more straightforward, would be reload calendar data with the client-side api after saving event:
scheduler.clearAll();
scheduler.load("dataUrl", "json");
http://docs.dhtmlx.com/scheduler/api__scheduler_clearall.html
http://docs.dhtmlx.com/scheduler/api__scheduler_load.html
I'm writing a simple API, and building a simple web application on top of this API.
Because I want to "consume my own API" directly, I first Googled and found this answer on StackOverflow which answers my initial question perfectly: Consuming my own Laravel API
Now, this works great, I'm able to access my API by doing something like:
$request = Request::create('/api/cars/'.$id, 'GET');
$instance = json_decode(Route::dispatch($request)->getContent());
This is great! But, my API also allows you to add an optional fields parameter to the GET query string to specify specific attributes that should be returned, such as this:
http://cars.com/api/cars/1?fields=id,color
Now the way I actually handle this in the API is something along the lines of this:
public function show(Car $car)
{
if(Input::has('fields'))
{
//Here I do some logic and basically return only fields requested
....
...
}
I would assume that I could do something similar as I did with the query string parameter-less approach before, something like this:
$request = Request::create('/api/cars/' . $id . '?fields=id,color', 'GET');
$instance = json_decode(Route::dispatch($request)->getContent());
BUT, it doesn't seem so. Long story short, after stepping through the code it seems that the Request object is correctly created (and it correctly pulls out the fields parameter and assigns id,color to it), and the Route seems to be dispatched OK, but within my API controller itself I do not know how to access the field parameter. Using Input::get('fields') (which is what I use for "normal" requests) returns nothing, and I'm fairly certain that's because the static Input is referencing or scoping to the initial request the came in, NOT the new request I dispatched "manually" from within the app itself.
So, my question is really how should I be doing this? Am I doing something wrong? Ideally I'd like to avoid doing anything ugly or special in my API controller, I'd like to be able to use Input::get for the internally dispatched requests and not have to make a second check , etc.
You are correct in that using Input is actually referencing the current request and not your newly created request. Your input will be available on the request instance itself that you instantiate with Request::create().
If you were using (as you should be) Illuminate\Http\Request to instantiate your request then you can use $request->input('key') or $request->query('key') to get parameters from the query string.
Now, the problem here is that you might not have your Illuminate\Http\Request instance available to you in the route. A solution here (so that you can continue using the Input facade) is to physically replace the input on the current request, then switch it back.
// Store the original input of the request and then replace the input with your request instances input.
$originalInput = Request::input();
Request::replace($request->input());
// Dispatch your request instance with the router.
$response = Route::dispatch($request);
// Replace the input again with the original request input.
Request::replace($originalInput);
This should work (in theory) and you should still be able to use your original request input before and after your internal API request is made.
I was also just facing this issue and thanks to Jason's great answers I was able to make it work.
Just wanted to add that I found out that the Route also needs to be replaced. Otherwise Route::currentRouteName() will return the dispatched route later in the script.
More details to this can be found on my blog post.
I also did some tests for the stacking issue and called internal API methods repeatedly from within each other with this approach. It worked out just fine! All requests and routes have been set correctly.
If you want to invoke an internal API and pass parameters via an array (instead of query string), you can do like this:
$request = Request::create("/api/cars", "GET", array(
"id" => $id,
"fields" => array("id","color")
));
$originalInput = Request::input();//backup original input
Request::replace($request->input());
$car = json_decode(Route::dispatch($request)->getContent());//invoke API
Request::replace($originalInput);//restore orginal input
Ref: Laravel : calling your own API
I'm writing my first app in ZF2, and I want to create pagination system.
Currently, I have something like this in my controllers:
$pagLimit = $this->params()->fromQuery('limit', 1000);
$pagPage = $this->params()->fromQuery('page', 1);
$orderDir = $this->params()->fromQuery('dir', 'ASC');
$orderBy = $this->params()->fromQuery('column', 'id');
$result = $this->getMapper()->getList($orderDir, $orderBy);
$paginator = new Paginator(new ArrayAdapter($result));
$paginator->setItemCountPerPage($pagLimit);
$paginator->setCurrentPageNumber($pagPage);
I think that my solution is not quite good..
If I want to change e.g. default limit of items per page, I have to modify all my controllers. Also, I have to remember to send two arguments for all mapper methods which are getting lists of data.
My first thought was to use inheritance ("MyController" with methods like: setPaginationParams(), and setPaginator($data)).
Then I would have to remember to invoke "my controller" methods in every controller.
But maybe there is a better way to implement the same paginator for every controller in my module? MVC event? Create custom class and use DI?
What is the best way to implement this functionality?
Could you just give me some hints?
I'm new to ZF2 and OOP concepts. :(
You could always extend the paginator with your own, and have default values set.
You could even just pass in the request object or params object and then let the Paginator internally handle some things for you to save setting up default values etc.