Comments on: How to use THIS in THAT and then some

By: Neil Crookes

Neil Crookes — Sun, 04 Jan 2009 19:22:30 +0000

I reckon so yeah, would be a nice enhancement in 1.3, but I expect it’ll have to wait til 2.0

By: Kjell

Kjell — Sun, 04 Jan 2009 19:18:51 +0000

@Neil: hmm.. worth a ticket, what you think?

By: Neil Crookes

Neil Crookes — Sun, 04 Jan 2009 10:36:42 +0000

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?

By: Kjell

Kjell — Sun, 04 Jan 2009 09:16:24 +0000

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”.

By: Rafael Bandeira

Rafael Bandeira — Sun, 04 Jan 2009 01:09:02 +0000

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.

By: Kjell

Kjell — Sat, 03 Jan 2009 12:38:00 +0000

like fahad19 said: “dont try this at home” :)

By: Neil Crookes

Neil Crookes — Sat, 03 Jan 2009 09:35:10 +0000

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.

By: Kjell

Kjell — Fri, 02 Jan 2009 23:52:43 +0000

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.

By: Neil Crookes

Neil Crookes — Fri, 02 Jan 2009 21:02:43 +0000

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?