Function can't be called from the browser, problem with requestAction? - cakephp

I've asked a question here couple days ago, about how to avoid a function to be called from the browser. Some nice people pointed out that if put an underscore before de name of the function, it'll only accept calls from inside app. But, by doing that, I cannot call the function from an element (by using requestAction). Is there another way to do it? Thanks!

You can't call a private or protected method from outside it's class; (that's the whole point of private and protected methods!)
Your only option, unless I'm mistaken, is to make the method public, or call it from within another method, perhaps with an ambiguous method name if you are worried about a user accidentally calling it.
You can also check to see if the request was made via requestAction using:
if (!empty($this->params['requested'])) {
//requestAction was used, requested is set to 1
}
So you could use this in a public method, and do the appropriate action depending on whether it was requested or not.

Related

cakephp where to write custom functions

i am working on a Cakephp 2.3 ..In my modals i am doing encryption an decryption in these two functions beforeSave and afterFind .. as again and again i have to write this
Security::rijndael($text, Configure::read('constants.crypt_key'), 'encrypt');
so i decided to make a function so i have done this
static public function encrypt($text) {
return Security::rijndael($text, Configure::read('constants.crypt_key'), 'encrypt');
}
static public function decrypt($text) {
return Security::rijndael($text), Configure::read('constants.crypt_key'), 'decrypt');
}
but i want to know where should i write these function.. should it be in app/lib/utility or app/vendors directory and also after suggesting, do tell me how can i access the function in the Model ..how can i import the class in Model..thanks in advance
To use a common function on controller side you have to declare it in 'AppController.php'
While to use function in view files you can mention it in 'AppHelper.php' And for model you can put it in 'Appmodel.php'
It depends where you want to be calling them from. If you're only calling them from your model (which I think makes sense in your case), then you should place them in AppModel.php, which all your models inherit from.
however, having seen your previous question, if you're having to write the encrypt/decrypt function "again and again", then you're probably not designing your app very well.
Really, you should only need to call encrypt once, in your beforeSave, and decrypt once, in your afterFind. If you have to call them in one or two other places... OK. But if you're having to call them all over the place, you're going about things the wrong way.
And also, there should be no need to make it a static function.

How to access current request from bootstrap?

Is it possible to access the current request in Kohana's bootstrap? I tried accessing Request::$current but $current doesn't seem to be defined at that stage. Is there any way around that? Also at what point in the application is Request::$current defined?
It's not possible, because Request object is created in index.php after including bootstrap.php:
// Bootstrap the application
require APPPATH.'bootstrap'.EXT;
/**
* Execute the main request. A source of the URI can be passed, eg: $_SERVER['PATH_INFO'].
* If no source is specified, the URI will be automatically detected.
*/
$request = Request::factory();
If you must access it, do it in the index.php after it has been created, although maybe you could tell us what exactly are you trying to do?
You can use it after Kohana initialization.
Kohana::init(...);
Also, good practice is using interface methods instead of public variable. I'm wondering why the developers keep $current as a public field.
So.. use
Request::current();
Also, It seems that using
Request::initial();
is better idea. But it depends on your realization.

Getting controller's name inside behavior

Im writing ClearCache behavior.
It's purpose is to delete some of custom cache files on every afterSave and afterDelete event of the model.
In order to delete right files i need to know name of controller and the name of action that called ModelWithClearCacheBehavior->save() or ModelWithClearCacheBehavior->delete()
My question is:
How to get those names inside behavior?
There is no an elegant solution about this (at least I don't know it).
You can do it with a Configure::write class for example:
in your AppController's beforeFilter() you can add the following code:
Configure::write('current_controller', $this->name);
Configure::write('current_action', $this->action);
later on in your behavior you can access them with
Configure::read('current_controller');
Configure::read('current_action');
You can access it because you set them before any model iterations.
For sure it's not elegant but it's working.
Not something I've really done anything with, but a brief reading of the book seems to indicate that the model is (or should be) available inside the behaviour -
When creating behavior methods you automatically get passed a reference of the calling model as the first parameter. All other supplied parameters are shifted one place to the right.
You should then be able to access the model via $Model
this is a bit late but for future reference, in cakephp 2.0 can be done this way in a behavior (using CakeRequest)
beforeFind(&$model, $query){
global $Dispatcher;
$request = new CakeRequest();
$request = $Dispatcher->parseParams($request, $additionalParams = array());
pr($request->params->controller);
return $query;
}

Event Aggregation...What exactly is going on?

I have often times wondered about it but now that I have encountered a piece of logic that incorporates it, I thought I should go ahead and get some help on deciphering the fundamentals. The problem is as follows, I am looking at a WPF application that is utilizing the Composite Application Library. Within the source of the application I came across the following line of code in the Presentation of a view. For the sake of convinience I will call it Presentation A:
private void OnSomethingChanged(SomeArgumentType arguement)
{
UnityImplementation.EventAggregator.GetEvent<EventA>().Publish(null);
}
When I saw the method Publish in the above given method, my gut told me there must be a Subscribe somewhere and in another class, I will call it Presentation B there was the following:
UnityImplementation.EventAggregator.GetEvent(Of EventA).Subscribe(AddressOf OnSomeEventA)
There was a private function in the same class called OnSomeEventA that had some logic in it.
My question here is that how is everything wired over here? What exactly is achieved by the 'Publish' 'Subscribe' here? When 'something' changes, how does the compiler know it has to follow the logic in OnSomethingChanged that will 'Publish' an event that is 'Subscribed' by another class where the logic of the event handler has been described? It will be great to understand the underlying wiring of this process.
Thanks
The first time GetEvent<T> is called for each event (identified by the type parameter T) the EventAggregator creates an empty list of methods to call when that event is published. Typically, this will happen immediately before the first call to Publish or Subscribe (as in your examples).
Then:
Whenever Subscribe is called a method is added to the list.
Whenever Publish is called it walks through the list and makes those calls.
So, the call to Publish() in Presentation A results in all of the methods that have been registered by calling Subscribe being called, which in your example would include Presentation B's OnSomeEventA method.
Try setting a breakpoint in the OnSomeEventA method and take a look at the stack, and don't forget the source is available, too!

Command Pattern & parameter design

My understanding of the Command Pattern is that you simply have 1 virtual method 'execute()', and all dependencies that an implementation might have are put in the constructor or through setter injection in the implementation (like discussed here).
However, in the WPF implementation of the pattern, I noticed they are passing a generic argument to the execute() function (explained here).
This seems like a pollution of the interface to me, what would have been the motivation to add a generic parameter to the execute() function?
The canonical command pattern is usually illustrated with nice self-contained commands. In that any information needed by the command is stashed away within the Command object instance (typically via a parameterized constructor).
However in some cases, the parameters needed for Execute may not be available at command-creation time (are known only at runtime). e.g. Imagine a SignOutCommand( username ). The username is determined when the user clicks on the SignOut button after signing in first.
So username is passed in as a generic parameter to Command.Execute(); Each command is free to define its input and cast accordingly e.g. an arbitrary command can require 5 parameters as an object[].
It's for databinding. When you bind the command to every object in a list, for example, the current instance is sent to the execute method so that you don't have to keep track of the current instance yourself.
That said, I don't think that the WPF command notion is an implementation of the command pattern, they just share terminology.
The reason behind that parameter is the isolation between the creator of the command - who know what command needs to be executed, and the caller - who knows when a command need to be executed.
In certain commands some of the information that needed for the execution is not available to the creator. The caller the fills in the blank by passing a parameter to execute. An example: The creator creates a command that filters a list of records according to some criteria. The list is not available at the creation site, as there are many kinds of lists in the application.
The caller will specify which list needs to be filtered by passing at as a parameter.
We use a bit changed command pattern, so that in addition to Execute method we have two properties Request and Response and we parametrize them using polymorphism.
What's wrong with:
public class DeleteCommand : BaseCommand
{
private Dictionary<string, object> parameters;
public DeleteCommand(Dictionary<string, object> parameters)
{
this.parameters = parameters;
}
public void Execute()
{
var person = (Person)parameters["Person"];
var salary = System.Convert.ToDouble(parameters["Salary"]);
// etc.
}
}
Now if you have a controller that collects parameters you can pass those through to your commands.

Resources