I would like to know whether it's possible to have something like this next line but with the exclusion of some actions. Because I would like to have manage, add, delete,... to go to the respective action and not to the display action. I know it's possible by specifying these rules explicitely upfront, but if you have quite some of these it will not look to good in the router file.
Router::connect('/paginas/manage', array('controller' => 'paginas', 'action' => 'manage'));
...
Router::connect('/paginas/*', array('controller' => 'paginas', 'action' => 'display'));
So the aim is to remove the first line...
Thanks.
Do something like this in your PaginasController which is basicly the PagesController I think.:
....
public function display(){
// Assuming default behavior of cakephp here
...
if (!empty($path[0])) {
$page = $path[0];
if(
method_exists($this, $page) &&
!in_array(
$page,
array(
// Methods that never should be executed in this controller are going in here
)
)
){
$this->{$page}();
}
}
}
This would execute a specific method in the controller. You could exit it there to make it stop working afterwards.
This might be a bit dangerous though because it can access parent methods of AppController, too.
The other way in which you also need exactly two of those Router::connect() rules one described here: http://api.cakephp.org/class/router#method-Routerconnect
Router::connect(
'paginas/:action/*',
array(),
array('paginas' => '(manage|add|delete)')
);
This one goes first followed by the other one. Never tested!
Though I don't see why there should be public methods for editing pages. Use these to seperate them from the rest: http://book.cakephp.org/2.0/en/development/routing.html#prefix-routing
I recommend, if you are trying to do this what I am thinking of, that you won't start to write a management for pages using the PagesController. "Pages" is a more or less reserved word in cake and you can get in big trouble with using those words (wrote a "File" plugin once including a "File" model. Waste of time as if since cake1.2 or 1.3 there is actually a "File" class to handle file operations). Create something new like "ContentPage" or whatever for it. You are on a saver side then. This paragraph is maybe useless, because your controller is not even named "Pages", but I hate to delete long ones, so it stays, just in case you need this information once.
Also i recommend not to change programming language, which means, you either use english or spanish or whatever but not both or worst more. You could name your route whatever you want to, but the class names should maybe stay in english because cake is also.
Greetings
func0der
Related
I understand that this may be a duplicate of Any equivalent of Ruby's public_send method?. I'd like to explain what I am doing, and perhaps someone could advice.
I've been porting a ruby app over the last few days to learn Crystal. I've had to cut out a lot of functionality due to lack of send but today I've hit a main artery in my program.
I have a Hash which contains keystroke as key, and method as value. Based on what key is struck, the appropriate method is called. This obviously uses the send to implement the same.
From the linked question, I understand that Crystal is compiled so dynamic method calls are not permitted. However, if you look at the Vim editor, a user can map keys to methods, too. And vi(m) is written in C.
I am wondering if I missed something.
I know I could probably hardcode a switch statement with each key and call the appropriate method, but that still does not allow the user to assign a key to a method. Is there any alternative to this very large switch-case method ?
(I am guessing that rather than check the key in the when part, I would check the binding and call the method.
binding = #bindings[key]
case binding
when :up
up
when :down
down
when .....
else
end
Any better solution ?
I'm not sure that this way most simple and convenient (perhaps more experienced developers will correct me below) but i would use the Proc:
def method1
puts "i'm method1"
end
def method2
puts "i'm method2"
end
def method3
puts "i'm method3"
end
hash = {
"ctrl": -> { method1 },
"shift": -> { method2 },
"alt": -> { method3 }
}
binding = ["ctrl", "shift", "alt"].sample
hash[binding].call #=> i'm method2
See working example
Developing a Drupal 8 example site, I have declared block in a module, and I want to do a few things with this block, like check the route and show this block only on nodes, also check if the user has permissions to see this block, and the content of the block is a form which I had defined in another place of the module.
I don't want to get the classes/services that I need in a static way, I want to use dependency injection to get those classes because it is technically better to decouple code and allow better testing.
Now "create" method and the "constructor" method on the block are like so:
<?php
public static function create(ContainerInterface $container, array $configuration, $plugin_id, $plugin_definition) {
return new static(
$configuration,
$plugin_id,
$plugin_definition,
$container->get('current_user'),
$container->get('form_builder'),
$container->get('current_route_match'),
$container->get('access_check.permission')
);
}
public function __construct(
array $configuration, $plugin_id,
$plugin_definition,
AccountProxyInterface $user,
FormBuilderInterface $formBuilder,
ResettableStackedRouteMatchInterface $route,
AccessInterface $access
) {
parent::__construct($configuration, $plugin_id, $plugin_definition);
$this->user = $user;
$this->formBuilder = $formBuilder;
$this->route = $route;
$this->access = $access;
}
Is this the correct way to do this? Maybe I'm doing too much in the block file? Should I create a service to move the logic to another place? Probably I would need more things, which means using more services, and my "create" and "constructor" methods are growing in parameters. Is this the correct way to do it? Thanks.
When you have to inject many services in one class, be it a controller or a block, it usually tells that the class is not well designed because you are (probably) trying lots of things in just one class.
However, I've seen many controllers which inject multiple services in their constructors, so it doesn't seem an unusual practice anyway. "Every rule has an exception".
In the end, I think it is a matter of balance, build a class that is responsible for doing one logical thing, and its dependencies in the same way.
Let me elaborate on the title:
I want to implement a system that would allow me to enable/disable/modify the general behavior of my program. Here are some examples:
I could switch off and on logging
I could change if my graphing program should use floating or pixel coordinates
I could change if my calculations should be based upon some method or some other method
I could enable/disable certain aspects like maybe a extension api
I could enable/disable some basic integrated profiler (if I had one)
These are some made-up examples.
Now I want to know what the most common solution for this sort of thing is.
I could imagine this working with some sort of singelton class that gets instanced globally or in some other globally available object. Another thing that would be possible would be just constexpr or other variables floating around in a namespace, again globally.
However doing something like that, globally, feels like bad practise.
second part of the question
This might sound like I cant decide what I want, but I want a way to modify all these switches/flags or whatever they are actually called in a single location, without tying any of my classes to it. I don't know if this is possible however.
Why don't I want to do that? Well I like to make my classes somewhat reusable and I don't like tying classes together, unless its required by the DRY principle and or inheritance. I basically couldn't get rid of the flags without modifying the possible hundreds of classes that used them.
What I have tried in the past
Having it all as compiler defines. This worked reasonably well, however I didnt like that I couldnt make it so if the flag file was gone there were some sort of default settings that would make the classes themselves still operational and changeable (through these default values)
Having it as a class and instancing it globally (system class). Worked ok, however I didnt like instancing anything globally. Also same problem as above
Instancing the system class locally and passing it to the classes on construction. This was kinda cool, since I could make multiple instruction sets. However at the same time that kinda ruined the point since it would lead to things that needed to have one flag set the same to have them set differently and therefore failing to properly work together. Also passing it on every construction was a pain.
A static class. This one worked ok for the longest time, however there is still the problem when there are missing dependencies.
Summary
Basically I am looking for a way to have a single "place" where I can mess with some values (bools, floats etc.) and that will change the behaviour of all classes using them for whatever, where said values either overwrite default values or get replaced by default values if said "place" isnt defined.
If a Singleton class does not work for you , maybe using a DI container may fit in your third approach? It may help with the construction and make the code more testable.
There are some DI frameworks for c++, like https://github.com/google/fruit/wiki or https://github.com/boost-experimental/di which you can use.
If you decide to use switch/flags, pay attention for "cyclometric complexity".
If you do not change the skeleton of your algorithm but only his behaviour according to the objets in parameter, have a look at "template design pattern". This method allow you to define a generic algorithm and specify particular step for a particular situation.
Here's an approach I found useful; I don't know if it's what you're looking for, but maybe it will give you some ideas.
First, I created a BehaviorFlags.h file that declares the following function:
// Returns true iff the given feature/behavior flag was specified for us to use
bool IsBehaviorFlagEnabled(const char * flagName);
The idea being that any code in any of your classes could call this function to find out if a particular behavior should be enabled or not. For example, you might put this code at the top of your ExtensionsAPI.cpp file:
#include "BehaviorFlags.h"
static const enableExtensionAPI = IsBehaviorFlagEnabled("enable_extensions_api");
[...]
void DoTheExtensionsAPIStuff()
{
if (enableExtensionsAPI == false) return;
[... otherwise do the extensions API stuff ...]
}
Note that the IsBehaviorFlagEnabled() call is only executed once at program startup, for best run-time efficiency; but you also have the option of calling IsBehaviorFlagEnabled() on every call to DoTheExtensionsAPIStuff(), if run-time efficiency is less important that being able to change your program's behavior without having to restart your program.
As far as how the IsBehaviorFlagEnabled() function itself is implemented, it looks something like this (simplified version for demonstration purposes):
bool IsBehaviorFlagEnabled(const char * fileName)
{
// Note: a real implementation would find the user's home directory
// using the proper API and not just rely on ~ to expand to the home-dir path
std::string filePath = "~/MyProgram_Settings/";
filePath += fileName;
FILE * fpIn = fopen(filePath.c_str(), "r"); // i.e. does the file exist?
bool ret = (fpIn != NULL);
fclose(fpIn);
return ret;
}
The idea being that if you want to change your program's behavior, you can do so by creating a file (or folder) in the ~/MyProgram_Settings directory with the appropriate name. E.g. if you want to enable your Extensions API, you could just do a
touch ~/MyProgram_Settings/enable_extensions_api
... and then re-start your program, and now IsBehaviorFlagEnabled("enable_extensions_api") returns true and so your Extensions API is enabled.
The benefits I see of doing it this way (as opposed to parsing a .ini file at startup or something like that) are:
There's no need to modify any "central header file" or "registry file" every time you add a new behavior-flag.
You don't have to put a ParseINIFile() function at the top of main() in order for your flags-functionality to work correctly.
You don't have to use a text editor or memorize a .ini syntax to change the program's behavior
In a pinch (e.g. no shell access) you can create/remove settings simply using the "New Folder" and "Delete" functionality of the desktop's window manager.
The settings are persistent across runs of the program (i.e. no need to specify the same command line arguments every time)
The settings are persistent across reboots of the computer
The flags can be easily modified by a script (via e.g. touch ~/MyProgram_Settings/blah or rm -f ~/MyProgram_Settings/blah) -- much easier than getting a shell script to correctly modify a .ini file
If you have code in multiple different .cpp files that needs to be controlled by the same flag-file, you can just call IsBehaviorFlagEnabled("that_file") from each of them; no need to have every call site refer to the same global boolean variable if you don't want them to.
Extra credit: If you're using a bug-tracker and therefore have bug/feature ticket numbers assigned to various issues, you can creep the elegance a little bit further by also adding a class like this one:
/** This class encapsulates a feature that can be selectively disabled/enabled by putting an
* "enable_behavior_xxxx" or "disable_behavior_xxxx" file into the ~/MyProgram_Settings folder.
*/
class ConditionalBehavior
{
public:
/** Constructor.
* #param bugNumber Bug-Tracker ID number associated with this bug/feature.
* #param defaultState If true, this beheavior will be enabled by default (i.e. if no corresponding
* file exists in ~/MyProgram_Settings). If false, it will be disabled by default.
* #param switchAtVersion If specified, this feature's default-enabled state will be inverted if
* GetMyProgramVersion() returns any version number greater than this.
*/
ConditionalBehavior(int bugNumber, bool defaultState, int switchAtVersion = -1)
{
if ((switchAtVersion >= 0)&&(GetMyProgramVersion() >= switchAtVersion)) _enabled = !_enabled;
std::string fn = defaultState ? "disable" : "enable";
fn += "_behavior_";
fn += to_string(bugNumber);
if ((IsBehaviorFlagEnabled(fn))
||(IsBehaviorFlagEnabled("enable_everything")))
{
_enabled = !_enabled;
printf("Note: %s Behavior #%i\n", _enabled?"Enabling":"Disabling", bugNumber);
}
}
/** Returns true iff this feature should be enabled. */
bool IsEnabled() const {return _enabled;}
private:
bool _enabled;
};
Then, in your ExtensionsAPI.cpp file, you might have something like this:
// Extensions API feature is tracker #4321; disabled by default for now
// but you can try it out via "touch ~/MyProgram_Settings/enable_feature_4321"
static const ConditionalBehavior _feature4321(4321, false);
// Also tracker #4222 is now enabled-by-default, but you can disable
// it manually via "touch ~/MyProgram_Settings/disable_feature_4222"
static const ConditionalBehavior _feature4222(4222, true);
[...]
void DoTheExtensionsAPIStuff()
{
if (_feature4321.IsEnabled() == false) return;
[... otherwise do the extensions API stuff ...]
}
... or if you know that you are planning to make your Extensions API enabled-by-default starting with version 4500 of your program, you can set it so that Extensions API will be enabled-by-default only if GetMyProgramVersion() returns 4500 or greater:
static ConditionalBehavior _feature4321(4321, false, 4500);
[...]
... also, if you wanted to get more elaborate, the API could be extended so that IsBehaviorFlagEnabled() can optionally return a string to the caller containing the contents of the file it found (if any), so that you could do shell commands like:
echo "opengl" > ~/MyProgram_Settings/graphics_renderer
... to tell your program to use OpenGL for its 3D graphics, or etc:
// In Renderer.cpp
std::string rendererType;
if (IsDebugFlagEnabled("graphics_renderer", &rendererType))
{
printf("The user wants me to use [%s] for rendering 3D graphics!\n", rendererType.c_str());
}
else printf("The user didn't specify what renderer to use.\n");
I am working on a plugin which will have its own plugins to handle various events.
Now I'm thinking of enabling this plugins to add their own "commands". But I wonder how to treat that most efficiently. I have a list of my own commands which I search in the article anyway. Should I then just trigger a DoWhatYouWant($article)-event - or, since I do the searching (and parsing of params) anyway, perhaps I could build a global command-list and then trigger an "ExecuteCommand($article,$cmd,$params)"-event? Sounds nicer, but then (I think) I'd have to build this command-list (so that my program know what to look for), so every plugin would have to somehow 'advertise' what it could do, i.e. the names of commands it could handle - and I have no idea how that could be done.
Or is there a better (more standardized?) approach?
If you import your plugins trough the plugin helper
JPluginHelper::importPlugin('mycmdplugins');
then you can get all available commands which are supported by your sub plugins like
$cmds = JDispatcher::getInstance()->trigger('onMyAwesomeCmds');
With the $cmds variable you know now which commands are supported by the sub plugins and you can parse the article for them. Then you can do
foreach ($cmds as $cmd) {
preg_match_all("{".$cmd."*}", $article->text, $matches, PREG_SET_ORDER);
if (!empty($matches)) {
JDispatcher::getInstance()->trigger('onMyAwesome'.ucfirst($cmd), array($article, $params));
}
}
To eliminate more repeating tasks I suggest that the additional plugins will extend a base class from your plugins folder.
I was trying to answer this question: emberjs: add routes after app initialize()
I started to play with Ember.Object.reopen(), to understand how it works, and perhaps finding a way of answering the previous question.
I feel a bit puzzled, and don't understand the behavior of this code:
jsfiddle: http://jsfiddle.net/Sly7/FpJwT/
<script type="text/x-handlebars">
<div>{{App.myObj.value}}</div>
<div>{{App.myObj2.value}}</div>
<div>{{App.myObj3.value}}</div>
</script>
App = Em.Application.create({});
App.MyObject = Em.Object.extend({value: 'initial'});
App.set('myObj', App.MyObject.create());
Em.run.later(function(){
App.get('myObj').reopen({
value: "reopenOnInstance"
}); // the template is not updated, 'initial' is still diplayed, but
console.log(App.get('myObj').get('value')); // print 'reopenOnInstance'
App.MyObject.reopen({
value: "reopenOnClass"
});
App.set('myObj2',App.MyObject.create()); // the template is updated and
console.log(App.get('myObj2').get('value')); //print 'reopenOnClass'
App.myObj3 = App.MyObject.create(); // the template is not updated but
console.log(App.myObj3.get('value')); // print 'reopenOnClass'
Em.run.later(function(){
App.get('myObj').set('value', "setWithSetter"); // the template is updated and
console.log(App.get('myObj').get('value')); // print 'setWithSetter'
App.get('myObj2').set('value', "setWithSetter"); // the template is updated and
console.log(App.get('myObj2').get('value')); // print 'setWithSetter'
App.myObj3.set('value', "setWithSetter"); // the template is not updated but
console.log(App.myObj3.get('value')); // print 'setWithSetter'
}, 2000);
},2000);
If someone can explain what is going on, particularly why the templates are sometimes not updated, sometimes updated, and also what's the difference between calling reopen on a class, calling it and on a instance.
Not 100% sure, but I will try and answer you questions.
First lets look at "myObj3". The ember getter/setter methods trigger the updates in the templates (they fire internal events which cause every property/observer to know something happened). Just setting a value by hand does update the value but will not fire these events and hence nothing changes in the UI. Kind of like when you use a Mutable list you use pushObject to make sure the UI updates.
Now lets look at your "reopen". When you reopen on the class it works as you would expect and updates the base class. When you reopen an instance it is actually creating a mixin and shims it on top of the object. This means when you do a "get" ember iterates over the mixin & object for the value to return. It finds that mixin and gets the value before the object; you could actually replace the method with a "return 'foo '+this._super()" on the instance you will get 'foo initial' (think of your object has having layers like an onion). If you have a group of mixin on top of your object you will have a hard time finding the correct value if you set something directly (but "get" will work perfectly). This leads to the general rule that you should always use "set" instead of a direct reference.
Side note: You can call "getPath" instead of "get" and you can use the relative or absolute path. Such as App.getPath('myObj2.value') which will make the code a little easier to manage. Goes for "setPath" also.
Lastly: The last value prints because you did change the value (it is in there) but the trigger for ember to update the ui never fired because you never called set on "myObj3" object.
EDIT: In the lastest version of ember it looks like the reopen on an instance does do a merge-down on the object (if that key already exists). The mixin only will wrap if you are adding new content.