What is the difference between using AuthComponent::allowedActions and AuthComponent::allow?
When I Google, I see the majority of examples and documents using or talking about allow(), but only a few using allowedActions. But they both seem similar in usage.
allowedActions is a property that contains a list of allowed actions.
allow() is a method that adds actions to the allowedActions property.
When you call the allow() method, it will merge the actions you specify with the actions already kept in allowedActions.
You can bypass the allow() method and assign an array of allowed actions to the allowedActions property directly, but I would only do that if I absolutely had to override any actions previously added (for example, by a parent class) to this property. The official documentation makes no reference to the allowedActions property.
In 2.x use:
$this->Components->disable('Security');
Related
In OWL API, there method getObjectPropertiesInSignature() can be used to obtain the set of object properties in an ontology. I have two questions with respect to this:
By using this method, will it return also the object properties in imported ontology ?
Also, this method is deprecated in the latest version of OWL API, is there another method with the same behaviour ?
getObjectPropertiesInSignature() has an overloaded version with a boolean flag, its purpose is to allow you to choose to look in the signature of the ontology or in the signature of the imports closure. Use it to get the object properties for the whole imports closure.
The method is deprecated and the javadoc suggests using the stream based method. For all such scenarios in OWLAPI 5, methods named getXxx() have an alternative version named xxx() that returns a stream. It is preferable to use them if you need only one iteration through the underlying collection (it saves having to make defensive copies). If you need multiple iterations or lookups, you can keep using the deprecated methods or collect the data from the stream in a set.
For example, To access time and name of Calendar events, we can write:
$startTime = $event->Start;
$endTime = $event->End;
$subject = $event->Subject;
But an event's body is not accessible by doing:
$body = $event -> Body
Instead we have to create a separate response and look in the event's extended properties.
Good question. I just did some research on this a week or so ago. Basically, EWS has a concept of First Class Properties and Elements. This means that some properties aren't returned by FindItem and some are, most likely to save space. Items can contain over a hundred properties and their children can contain properties and so on and so forth, so to help keep things simple there are some properties that aren't returned in FindItem and some that are. Here's the quote from the documentation
The set of first-class properties and elements that are returned by the EWS Managed API EmailMessage.Bind method and the EWS GetItem operation is slightly different than the set of first-class properties and elements that is returned by the EWS Managed API ExchangeService.FindItems method and the EWS FindItem operation.
Note that you cannot extend the FindItems method or the FindItem operation to retrieve additional properties and elements such as ToRecipients, CcRecipients, and BccRecipients. If you need to retrieve those values, use the FindItems method or the FindItem operation to get the item IDs of the emails, and then use the Bind method or the GetItem operation, to retrieve the required properties
So basically the answer boils down to "Because you EWS won't let you". If you want to know what properties are First Class and what aren't, there's a good page in the documentation with a table to help determine that, located here.
Finally, might I suggest upgrading the library you're using for your EWS operations? I assume you're using jamesiarmes/php-ews which is the most popular from what I've seen, but I'm maintaining my own fork located at garethp/php-ews which is autoloadable, has a simple access API for some operations and is still under development.
New to backbone/marionette, but I believe that I understand how to use backbone when dealing with CRUD/REST; however, consider something like results from a search query. How should one model this? Of course the results likely relate to some model(s), but they are not meant to be tied to said model(s).
Part of me thinks that I should use a collection using a model that doesn't actually sync with a data store through the server, but instead just exists as a means of a modeling a search result object.
Another solution could be to have a collection with no models and just override parse.
I assume that the former is preferred, but again I have no experience with the framework. If there's an alternative/better solution than those listed above, please advise.
I prefer having one object which is responsible for both request and response parsing. It can parse the response to appropriate models and nothing more. I mean - if some of those parsed models are required somewhere in your page, there is something that keeps reference to this wrapper object and takes models from response it requires via wrapper methods.
Another option is to have Radio (https://github.com/marionettejs/backbone.radio) in this wrapper - you will not have to keep wrapper object in different places but call for data via Radio.
I've been trying to find some info on difference between instantiating form fields through static method and the new keyword. Can somebody tell me what are the practical implications, limitations, between new MyFormField and MyFormField::create() esp. with regards to SilverStripe
Using the create factory method would check for overloads (set via Object::useCustomClass()) and return an instance of the custom class in that case.
This method first for strong class overloads (singletons & DB
interaction), then custom class overloads. If an overload is found, an
instance of this is returned rather than the original class. To
overload a class, use Object::useCustomClass()
So using the create method rather than instantiating the Object yourself would provide a possibility to overload the used Class without altering the code.
see
http://api.silverstripe.org/3.1/class-Object.html#_useCustomClass
http://api.silverstripe.org/3.1/class-Object.html#_create
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;
}