I feel like I need to change a couple methods in style.js in order to integrate it into my app. What is a "best practice" for adding methods or even overriding methods in core objects? I plan on doing upgrades in the future, so I don't want to edit the style.js file itself.
The way to extend CKEditor is to create plugins for it.
If you have to modify something inside a closure then a plugin won't work for you and you'll have to get the source code and modify it and from then on keep using that patch.
Related
Where should the authorization code in Laravel? We have a lot of options and a lot of plugins to manage this situation but and I'm not really sure where I should put all logic. Let's see:
I know that there are a lot of possibilities with a correct result but I want to know which is the optimal solution for you or know your techniques in this situations.
Imagine we have a help desk application done in vuejs and Laravel as API, so we have users, groups, roles, permissions. And maybe a user will only able to see its tickets.
Should we do a TicketPolicy with view, update, create methods? Maybe should we use repositories? Maybe a is_user_allowed method in Ticket's model?
Should we use middleware in routes files and do something like Route::get('tickets/{ticket}', 'TicketsController#show')->middleware('can:show')? Or should we call $this->authorize($ticket) in show, edit, update and store methods of the controller?
Or maybe should we use FormRequest#authorize method and then use something like $user->authorize('show', $ticket)?
What if we want groups or roles? Should we use some plugin like Entrust and/or policies?
What do you think, what do you do?
Best place I found to put classes that group specific logic that do not fit in standard MVC pattern is completely new folder for Laravel. I name mine Services, probably because I read it somewhere. One of the great things in Laravel (and probably other modern frameworks) is flexibility, you can just pop a folder, add a new namespace and have it contain whatever you need.
As for your example, I would implement a class App\Services\Permissions that would contain all necessary logic for accessing different resources in your application. Then call it's methods wherever you need them, be it Requests, Middlewares or Eloquent Models.
I Searched a lot to find the answer to this question, here on stackoverflow and over on google. But was not able to find anything...
So, my question is: It is a good practice to extend a controller (in my case BaseUserController from zfcuser) once in a module, and once more in another module?
Thanks for all your replies!
It's fine, I would not go as far as "good practice".
Excessive use of inheritance can cause you issues in any language and there are numerous of post around explaining the issues and possible solutions.
From a ZF2 perspective in doing so you will have the issue where Module B depends on Module A which may be a problem - However this really depends your application/module design.
There are other alternatives:
Aggregation -
create new functionality by taking other classes and combining them into a new class. Attach an common interface to this new class for interoperability with other code.
Use PHP traits - If you lucky enough to use the more recent versions of (PHP 5.4+) the you can simply reuse these within each controller class that requires it.
A Custom Controller Plugin - ZF2 has a "pluggable" API within the controller, meaning you can write self contained helper classes that can then be used in any controller - No need to extend. You are almost certainly using these already with $this->redirect() or $this->params() so they might be good places to start to see how they are built.
I am trying to implement a OrientDB HTTP connection in Code Igniter, but I can't quite decide how to go about it. Basically, I am using the php code found here, and I cannot decide whether to make that file collection into a library or a helper.
Right now, I am leaning towards a helper, because $this->load->library() automatically instantiates the class, where I will need the ability to call static methods as well (as can be seen in the use of BindingParameters::create('http://admin:admin#127.0.0.1:2480/demo');) in the example code.
So, if I make these files into helpers, which should not instantiate the classes, is there a way to load them without adding a "_helper" suffix to the files themselves? I would like to avoid using require/include, but if there is no other way to accomplish this then I have no choice.
Does anyone have any tips or ideas that may help me with this? Thanks beforehand.
Hey! I'm trying out Backbone.js and have followed the annotated source of the TODO's app.
I fail (don't know how this should be done) when trying to implement projects, which has tasks as "children". So that i can change project and view different lists of tasks.
How should i do this? Some tips for beginner tutorials would also be great :)
The backbone docs mention a pattern for doing something like this:
http://documentcloud.github.com/backbone/#FAQ-nested
So, I would create a new model called a project that has a property called 'tasks' which is an instance of a TodoList collection.
I can't speak to storing the data, as I've never looked at the localStorage used in the TODO app.
I've started a CI project and I'm going to use it with Doctrine, there is benchmarking system for the latter and I'd like to remove the ability to use native CodeIgniter DB class, since it won't be benchmarked. I though about simply removing the corresponding files, but I'm afraid it could cause CI errors in other places. How can I remove the ability to use native CI DB class?
I personally would not do it. I just want to force the future developers with random level of qualification not to load it as well
I also use Doctrine in connection with CodeIgniter and there is no need to do anything with the CI DB class. Just ignore it and use Doctrine as you would do normally. If you don't use the DB classes or don't load it, they won't get benchmarked.
If you haven't already found it, look at the wiki, ot gives a good idea what to do with Doctrine
edit to your 1st comment: If you really want to disable the DB class, I see one way: either delete the core file(s)/folder(s) or rename it so that a loading just fails. Alternatively, change their code so they cannot be loaded. If you do so, it should be really well documented somewhere so that the error will be obvious to someone after you.
Don't load it in your controller.
Theoretically, you could create a hook and disable CI's DB functionality. In the hook, you would extend the CI_DB class and the display an error message if the class gets loaded. I'm sorry I can't give specifics, but you'd probably have to inspect the system's database classes to see what would need to be altered.
At least that way, you wouldn't need to make changes to the CI core.