How to use THIS in THAT and then some
Some common questions on IRC:
How to use a model in a component
$model = ClassRegistry::init('ModelName');
$result = $model->find('...');
How to extend a core helper
App::import('Helper', 'Text');
class AppTextHelper extends TextHelper {
// ... your code
}
How to extend a core component
App::import('Component', 'Auth');
class AppAuthComponent extends AuthComponent {
// ... your code
}
How to get just the url from a link (href) in a view
$html->url(array('controller' => 'users', 'action' => 'edit'));
How to transform those array formatted urls into a string
Router::url(array('controller' => 'users', 'action' => 'edit'));
How to add a foreign model to a controller
class UsersController extends AppController {
var $uses = array('User', 'Page');
function something() {
$result = $this->Page->find(...);
}
}
How to load data from a foreign model in any controller
class UsersController extends AppController {
function something() {
$result = ClassRegistry::init('Page')->find(...);
}
}
How to use a helper in a component (or controller)
Don’t …
How to use a model in a helper
Don’t …
I recently used a helper in a behavior – I don’t think I was wrong to do so either – here’s the usage:
App::import(’Helper’, ‘Text’);
$TextHelper = new TextHelper();
$model->data[$model->alias]['summary'] = $TextHelper->truncate($content, 130, ‘…’, false, true);
I used the text helper truncate method with consideration for html to auto populate a rich text summary field with the first 130 chars from a rich text content field on beforeSave() when creating the record.
I needed to do it this way, cus the administrator could override the default truncated text with their own at a later date if they wanted to.
There is absolutely no reason to write this method again myself. What do you think?
I agree on the duplicate code issue, but it isn’t exactly the CakePHP-way.
Since you can do alot wrong when breaking the rules it is not advisable to beginners either. That’s why i removed the example from my list.
You can go that route, if you know what you are doing, but don’t expect others to agree and support.
You’re right on it being the official line, but there are always occasions when its right to break the rules – if you know what you are doing. Take the Cake core form helper for example – it accesses model objects for validation errors and schemas. I think the official line should be don’t do it… unless you know what you are doing.
like fahad19 said: “dont try this at home” :)
I don’t agree with your last two assumptions.
Before going any further on this I would like to say that, “break the rules”/”break the mvc”/”isn’t the CakePHP way” are – much probably – always erroneous. What are the rules and where are them, and how can you possibly know that if you haven’t designed or conceptualized the things you are claiming to be breakable with such behavior?
Anyway, helpers and components are not even part of the firsts sketches about mvc and it’s “rules”, so you are most probably writing based on your own ideas.
Well, I do load helpers everywhere I need them, and I do think that they are misconceptioned in an architectural point of view when being used only as elements of the rendering process. Why would a Helper being loaded inside a component break anything? You must have this answer to write such a thing.
Still on helpers loading, why do you think methods like TimeHelper::daysAsSql() are meant for? Also lots of methods used on views could – should – be used on the model side when storing data, for the sake of performance – like HtmlHelper::clean().
About loading models on Helpers, that’s totally usable too: let’s say that this “rules” only say you shouldn’t retrieve, store or update data outside the Model layer, in between the Controller domain; Now, using model’s signature and parameters to deal with the rendering process – just as the form helper does, isn’t by any means a bad thing, although you can say that same parameters could be passed by the controller to the view.
I think people put too much pragmatism when talking about the MVC pattern – having they studied it or no – and about the X-way of doing something, and being it good or no they are oftenly over carried about something that is not that restrict.
Hey.. i am all for it! You may have misunderstood. I said “it is not advisable to beginners” and also “I agree on the duplicate code issue”. I too think they are misconcepted to some extent! I think some calculation methods (not related to views/html) that were introduced in helpers should be put into seperate libs.
… App::import(’Core’, ‘Time’) anyone?
Then, to avoid duplicated code in the view helpers, the lib coulb be reused in the helpers. (think: wrapper)
All peachy.. but why? Simply because this makes it “free to anyone” to just load up the core lib when he needs to calculate something in models, components, controllers.. just like all the other Libs. No hard feelings anymore from there on out :)
Plus, when the “useful-everywhere” methods are in another space, one can’t harm himself by using View related helper stuff he isn’t supposed to be using.
Back to my previous statement: the beginner. – If we promote on blogs that it is okay to load ANY helper somewhere, then some newbies may think that it is “okay” to do $form->input in a controller (for whatever reason), which is absolutely not.
With a BIG BIG disclaimer what methods are helpful inside components/models/controllers this can be advised, but my reason for not doing so in THIS particular post was that i wanted to keep the list “simple”.
I like your thoughts on moving the non-presentational specific logic out of helpers and into core libs so the logic can be used anywhere.
I think we’re all heading in the direction of “don’t do it… unless you know what you are doing” aren’t we?
@Neil: hmm.. worth a ticket, what you think?
I reckon so yeah, would be a nice enhancement in 1.3, but I expect it’ll have to wait til 2.0