I'd like helper instances to be capitalized in the view, to avoid this
- i.e. $Html->image(...) instead of $html->image(...)
The reason is the same as Adam's; models and helpers can often be
named the same, and this causes problems.
I've thought about the helper alias thing, I agree it would be cool -
mainly so I could write "MyHtmlHelper" which extends HtmlHelper, but
access it in the view as $html (not $myHtml). This would make certain
things a lot easier (setting default parameters, overriding certain
field types in FormHelper, etc...).
But actually having models have 'Model' as part of the name? No way,
far too much typing :
$this->CategoryModel->ProductModel->find(...);
Although the actual class could be called 'CategoryModel' and the
controller's instance could be accessed through the member variable
'Category' I suppose.
On Dec 20, 1:43 pm, Adam Royle <[EMAIL PROTECTED]> wrote:
> I've also run into a few conflicts when naming models and helpers...
>
> eg. i had a model "image" and an "imagehelper", when baking the view
> page it generate $this->set('image', $image); which would obviously
> conflict with my helper. I ended up naming my helper MagicImage
> instead :) However it would be great if we could avoid this situation.
>
> One solution is to wait until we have namespaces (or "modules", as I
> think they may be referred to) in PHP6. Another idea I had (maybe not
> feasible) is to add an alias for loaded classes
>
> var $uses = array('Image' => 'ImageModel');
> var $helpers = array('Image' => 'ImageHelper');
>
> or
>
> var $uses = array('Image' => array('alias' => 'ImageModel'));
> var $helpers = array('Image' => array('alias' => 'ImageHelper'));
>
> $this->set('image', $this->ImageModel->findAll());
>
> so you can then use them without conflict....
>
> Thoughts anyone? I don't have enough experience with the core to know
> if the above enhancement would have any negative side-effects.
>
> Cheers,
> Adam
>
> On Dec 20, 10:45 pm, AD7six <[EMAIL PROTECTED]> wrote:
>
> > On Dec 20, 10:37 am, lordG <[EMAIL PROTECTED]> wrote:
>
> > > Hi Guys,
>
> > > I've got a question, and hopefully one of the cakephp guys can give an
> > > answer.
>
> > > First, the scenario...
> > > I often will used more than one model file to represent the same data.
> > > A common reason is to separate admin functions from normal ones, so
> > > the normal model is less intensive to load. There may be other reasons
> > > like two different data sources, but the same data model.
>
> > > Now although this does not seem a problem at first, it becomes a
> > > problem when you start creating forms to represent and manage that
> > > data. In all these models, the $name variable is set the same (e.g.
> > > User), so I have transparency between the models (and the models may
> > > be named: UserModel1, UserModel2 etc). However, when we populate a
> > > form with the model data using the FormHelper, it requires the
> > > following name: ModelClass.field (1.2) or ModelClass/field (1.1). Now
> > > naturally this causes a problem when the models have different class
> > > names (This may be so that we can store all the models in the same
> > > directory or even load more than one of them at the same time.)
>
> > The above sounds rather over complex to me. What is the benefit of
> > making several 'models' for one model? (The fact that I ask should
> > imply that I don't percieve any of the above reasons as a benefit).
>
> > > Now my only argument or frustration is why does the FormHelper use the
> > > Classname as part of the naming of the input field rather than the
> > > $name variable of the class?
>
> > Why is the $name not the same as the class name. That´s begging for
> > things not to work IMO. 1.2 uses the alias afaik btw, which defaults
> > to the model name.
>
> > > I have no problem in it needing the class
> > > name to initiate and retrieve the input name value, but I think that
> > > it would be best that the resulting name was: data[ModelNameVariable]
> > > [field].
>
> > > What are your thoughts?
>
> > > Then, the second part of the conventions is why are controller class
> > > files named differently to all the other files like models, helpers,
> > > components etc?
>
> > You are refering to plural or _controller? I can´t remember the
> > specifics but when the _controller was dropped there were naming
> > conflicts.
>
> > > Surely to remain consistent, one should keep the
> > > naming convention the same all across? My personal preference would be
> > > that they are all named according to their class name, so much like
> > > the current controllers are. I understand the impact this would have,
> > > but I think that this would help keep a stronger convention on the
> > > naming of the files.
>
> > If anything were to change I prefer writing less :).
>
> > > A third case to look at is if a component and a model share the same
> > > $name variable value or Similar class names (Component: User
> > > "user_component"; Model: User "user"). This causes a problem. To get
> > > around that I named all my components iClassComponent. However, I
> > > would think that the best way really to solve this would be to name
> > > the objects according to their class names, ie: Models would be
> > > UserModel and Components would be UserComponent. This also allows for
> > > better usability as you thereby know automatically the type of object
> > > it is.
>
> > > What are your thoughts?
>
> > Component & Model name conflicts are indeed a problem. Although I
> > don't think writing "Component" and "Model" after each of them is
> > necessarily that good an idea. For chained model calls that makes them
> > quite long, and writing $this-SessionComponent->write(); would
> > probable get tiring rather quickly.
>
> > only IMO of course,
>
> > AD
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cake
PHP" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/cake-php?hl=en
-~----------~----~----~----~------~----~------~--~---