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
-~----------~----~----~----~------~----~------~--~---
