I have a function in one of my views that formats data coming from the DB before displaying it. Since I use this function in many views, I'd like to make a global function that would be accessible from every view. How would I do that ?
As mentioned in the other answers, creating a helper is probably what you are looking for. See the cookbook entry for more information.
To make your helper available in all your views, add the helper to the $helpers array of your AppController (app/Controller/AppController.php).
Creating a helper (as Headshota and preinheimer explained) is the best idea if the function is complex..
But if your function is simple,
you can open the file app/config/bootstrap.php
write your function in this file and that's it..
the function will be accessible anywhere (models, controllers, views, etc)
hope that helps...
I think you want to create a view helper, here's an example one: Minify Helper
Yes you have to create your owns View Helpers.
You will find the documentation in the Section "View > Helpers" of the cook book : here
But the section "Core Libraries > Helpers" just explains how to use the ready-to-use cakephp Helpers like HtmlHelper or FormHelper: here
Likewise you can note that this is the same logic with firstly controllers and components, and secondly model and behaviours.
Then the cook book presents the core components in core-libraries/toc-components
How to create your own is explained in controllers/components
The core behaviours are presented in core-libraries/toc-behaviors
The how to create your own is in models/behaviours
This system is really efficient and makes cakePHP a handy framework (thank you the great documentation) that implement efficiently the Model-View-Controller design pattern.
If you understand that question correctly, you never ask yourself this kind of issue about cakePHP and by the same time, about the MVC pattern.
Related
I'm trying to cache the db calls for Yii2 exists validation, but can't work out where to initiate it.
Because I'm using a multi-model form with a lot of relations, the overhead is getting a little too much.
Any ideas?
You'd better not. Actually, there is an issue on Yii2 official Github project where one of the framework's core developers, Alexander Makarov aka #samdark, explains why caching ExistValidator is a bad idea:
Exist validation isn't the kind of validation to be cached. Each second database may change its state so it should be validated just before it's saved.
This is not supported by Yii, you either have to :
Extend the ExistValidator and implement your caching logic there
Add a custom ActiveQuery class to your model in question and override
the exists() and count() methods
I'm totally newbie at using AngularJs and although I've been through the tutorials, I still have loads of unanswered questions in my mind. My main concern right now is how should I divide my application into modules ?
Basically I need to build an app which will act as a portal to various apps, each representing a business functionality (sometimes with little to no relationship with each others).
In the tutorial, they show how to create one app with multiple views. What I need, is one app with multiple modules, each module having its own views (and I'll probably have shared views too).
Has anyone worked on an app with that kind of structure ? Could you share your experience and how you've organised things ?
The AngularJS Seed project (https://github.com/angular/angular-seed) is good but it does not really show how to build a complex application.
[EDIT]
I wrote an article on my blog to explain things in more details:
read it on sam-dev.net and you can now read part II, with code sample.
I'll answer my own question. Not because I think it's the best approach, but just because it's the one I've decided to go with.
This is how I've divided my business modules into folders
app
businessModule
controllers
index.js
firstCtrl.js
secondCtrl.js
directives
services
views
filters
anotherBusinessModule
shared
app.js
index.html
Each module has its own folder structure for controllers, directives, etc...
Each folder has an index.js file and then other files to separates each controller, each directive, etc...
The index.js file contains the definition of the module. For instance for the controllers of the businessModule above:
angular.module('myCompany.businessModule.controllers', []);
There's no dependencies here, but there could be any.
Then in firstCtrl.js, I can reuse that module and add the controller to it:
angular.module('myCompany.businessModule.controllers').controller('firstCtrl',
function(){
});
Then the app.js aggregates all the module that I want for my application by adding them to the dependencies array.
angular.module('myApp', ['myCompany.businessModule', 'myCompany.anotherBusinessModule']);
The shared folder contains directives and other things that are not specific to a business module and that can be reused anywhere.
Again, I don't know if it's the best approach, but it definitely works for me. Maybe it can inspire other people.
EDIT
As the index.js files contain modules declarations, they must be referenced in the html page before any other application scripts. To do so, I've used the IBundleOrderer of ASP.NET MVC 4:
var bundle = new ScriptBundle("~/bundles/app") { Orderer = new AsIsBundleOrderer() };
bundles.Add(bundle.IncludeDirectory("~/app", "*.js", true));
public class AsIsBundleOrderer : IBundleOrderer
{
public IEnumerable<FileInfo> OrderFiles(BundleContext context, IEnumerable<FileInfo> files)
{
files = files.OrderBy(x => x.Name == "index.js" ? 0 : 1);
return files;
}
}
Sam's method seems to be the way to go in most cases. The current Angular documentation has it setup as a module for each controller, service, etc, but this has been contradicted by Miško himself from google.
In a recent Angularjs Best Practices video by Miško, he shows how the structure of modules could be laid out for ease of testing as well as easy scaling. Keep in mind how you structure the modules is not supposed to affect performance within an angular app.
From developing angular apps, I would suggest using the best practices method for the aforementioned reasons. You may wish to make your own node script to generate your controllers, etc for the time being which could include say the module you wish to create the controller in and the name, which would then auto generate your controller and proper test spec creation.
If you want a great read on the setup there is an excellent post here regarding setting up the project based on where you think it will be heading.
you should go to the yeoman https://github.com/yeoman/yeoman and yeoman generator structure: https://github.com/yeoman/generator-angular, it becomes a better solution to setup application than angular-seed. For different business modules, you should create different app and share services and directives
For those who are interested, I made a "modularized" version of Angular Seed that fits better with Misko's best practices: https://github.com/sanfordredlich/angular-brunch-seed-modularized
It's set up with Brunch so you very quickly get page reloading, test running and much more. You can be developing quickly and if you follow the patterns in the code, your application should scale reasonably well. Enjoy!
The draw back I have found to the approach the yeoman generator takes is that it doesn't really lineup with the angular modules so it doesn't feel very cohesive to me. So as the project gets larger and you are working on a particular component I found myself flipping around a lot in the source tree.
I have recently come across a different approach here. This approach groups the files by angular modules and feels more cohesive to me. One possible drawback to this is the fact you are required to build the site you can't just run it in place. The grunt watch task in that project helps with this though.
Are there any resources on how to design frameworks, i.e. tips and tricks, best practices, etc..
For .NET there's
Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries
http://www.amazon.com/Framework-Design-Guidelines-Conventions-Libraries/dp/0321545613
You can also study frameworks like Spring.
The google tech talk lecture How To Design A Good API and Why it Matters provides many insights on how to design a good API.
In regards to PHP ehre are some Tips from me:
Use MVC as your framework type.
MVC (Model-View-Controller) is the best way to create a framework, keeping your Logic and Models separate to your Views etc is the best way to accomplish a fresh clean application.
I believe thatStack Overflow uses a MVC pattern, Not sure if its PHP / ASP tho.
Make your code as open as possible.
Meaning that practically any object is accessible throughout the application.
A way i achive this is by creating a static class that as a global scope to overcome the problem, for example:
class Registry{....}
Registry::add('Database',New Database);
Registry::add('Input',New Input);
Registry::add('Output',New Output);
then anywhere throughout the application you can easily get objects like so:
Regsitry::get('Database')->query('Select .... LIMI 10')->fetchObject();
Do not use template engines
In my eyes template engines are not the best as PHP is itself a template engine, there's no need to create a lot of code to parse your templates and then have PHP parse it again, its logical.
Instead create an system where the user will tell the View what template file to output and check the catch for that, if its not in the cache then that object will transfer it to another object called lets say ViewLoader, Witch within the __Construct it includes the php template file, but also has other methods like url() and escape() etc so in tempalte fiels you can then use
$this->url('controller','method',$this->params);
Hope this helps you!
I am creating a website and using Linq to SQl as a data access layer, and i am willing to make the website can work on both linq to sql and ado entity framework, without changing many things in the other layers: business logic layer or UI layer,
Whats the recommended pattern to achieve this goal? can you explain in brief how to do that?
UPDATE
As answered below that repository pattern will help me a lot,
i checked nerd dinner website and understood it, but i found this code inside:
public class DinnersController : Controller {
IDinnerRepository dinnerRepository;
//
// Dependency Injection enabled constructors
public DinnersController()
: this(new DinnerRepository()) {
}
public DinnersController(IDinnerRepository repository) {
dinnerRepository = repository;
}
Which means as i understood that it declare a dinnerRepository using the interface IDinnerRepository , and in the constructor gave it the DinnerRepository, which will be in my case for example the linq to sql implementation,
My question is if i need to switch to ado.net entity framework, i will need to edit this constructor line or there is a better solution for this?
Update 2
Where should i put this Respository Interface and the classes which implement it in my solution, in the data access layer or in the business layer?
The Repository pattern is a good choice. If you implement it as an interface; then you can change out the concrete classes and not have to change anything else.
The Nerd Dinner walkthrough has an excellent example of the Repository pattern (with interface).
The code you listed there would go in your controller (if you were doing an MVC Application); and you create any class you wanted so long as it implemented the IDinnerRepository interface (or you could have something like an IRepository interface if you wanted to design an interface that everyone had to implement that did the basic CRUD actions, and then implement specific interfaces if you needed more (but let's not go interface crazy).
If you're 'tiering' your application, then that part would go in the "Business Logic" layer, and the Repository would be in the "Data Access Layer". That constructor contract would be the 'loosely' coupled part.
I wound up using a minor variation on the "Repository" pattern. I picked it up from the excellent Nerd Dinner tutorial. You can find the whole tutorial here and the code is on Codeplex.
Don't let all the MVC put you off if your not in an MVC situation, the underlying encapsulation of Linq2SQL is a good one. In a recent update of a codebase I went from Linq2SQL to Linkq2EF and all the changes were nicely dealt with in the repository, no outside code had to be touched.
It is also worth noting that the RIA Services stuff comes with a similar pattern. You point it at Linq2Sql or Linq2EF and it build you a basic layer over it complete with CRUD. That layer is in source code so you could just rip it out and use it in a non RIA project but I just leave it as is and link to it in other projects so I use the layer even if I ignore the over-the-wire abilities.
I just started creating my data-access layer using LinqToSql. Everybody is talking about the cool syntax and I really like Linq in general.
But when I saw how your classes get generated if you drag some tables on the LinqContext I was amazed: So much code which nobody would need?!
So I looked how other people used LinqToSql, for example Rob Connery at his StoreFront Demo.
As I don't like the way that all this code is generated I created my domain layer by hand and used the generated classes as reference. With that solution I'm fine, as I can use the features provided by Linq (dereferred execution, lazy loading, ...) and my domain layer is quite easy to understand.
How are you using LinqToSql?
The created classes are not as heavy as it seems. Of course it takes quite a few lines of code, but all in all it is as lightweight as it can be for the features it's providing.
I used to create my own tables, too, but now instead I just use the LINQtoSQL DataContext. Why? Creating is simpler, the features are better, interoperability works, it is probably even faster than my own stuff (not in every aspect. Usually my own stuff was extremely fast in one thing, but the generic stuff was faster in everything else).
But the most important part: it is easier to bring new developers into the LINQ stuff than into my own. There are tutorials, example codes, documentation, everything, which I'd have to create for my code by myself. Same with using my stuff with other technology, like WCF or data binding. There are a lot of pitfalls to be taken care of.
I learned not to develop myself into a corner the hard way, it looks fast and easy at the start, is a lot more fun than learning how to use the libs, but is a real pain in the a after a few months down the road, usually even for myself.
After some time the novelty of creating my own data containers wears off, and I noticed the pain connected to adding a feature. A feature I would have had for free, if I had used the provided classes.
Next thing I had to explain my code to some other programmer. Had I used the provided classes, I could have pointed him to some web site to learn about the stuff. But for my classes, I had to train him himself, which took a long time and made it hard to get new people on a project.
LinqToSql generates a set of partial classes for your tables. You can add interface definitions to the 'other half' of these partial classes that implement your domain model.
Then, if you use the repository pattern to wrap access to the Linq queries, so that they return interface implementations of your objects (the underlying Linq objects), LinqToSql becomes quite flexible.
You can hand-write your own classes and either use the LINQ to SQL attributes to declare the mappings or an external XML file.
If you would like to stick with the existing designer and just modify the code generation process pick up my templates that let you tailor the generated code.
Use compiled queries. Linq to SQL is dog slow otherwise. Really.
We use our hand crafted domain model, along with the generated classes, plus a simple utility which utilizes reflection to convert between them when needed. We've contemplated writing a converter generator if we reach a point where reflection creates a performance bottleneck.