Shared Models in Different Modules

[Jean-Marc Fontaine]

> In my opinion, ZF's current naming scheme is not consistent among
> different MVC components.
>
> For Controllers:
> {MyModule}_{MyController}Controller @
> modules/mymodule/controllers/mycontrollercontroller.php
>
> And it makes sense to apply the same principle to models.
> Module_Model_MyModel.
I totally agree with that.

Regards,

Jean-Marc

--------------------------------------------
Kanopée - Développement Informatique Durable
56 rue de Saint André
59800 Lille

Tél      : [phone]
Portable : 06 88 56 50 79
Fax      : [phone]
Web      : http://www.kanopee.net/

[Xavier Vidal]

The only reason to make that model classes named that way is to avoid namespace collisions, but you can name that classes as you like. The problem will appear if someday a class named Story appears (from another package or external lib), any attempt to use two classes with the same name will throw an error.

On Dec 3, 2007 4:51 PM, Whitcraft, Jon <jwhitcraft@...> wrote:

Xavier,

 

I ran into that problem too.  I just refactored the class name to be new_Models_Story which makes no sense but it works for right now and going back later to refactor once it gets all figured out wont be too hard as the Zend Neon Beta does a good job of finding all the occurrences of that class.

 

Cheers

 

	Jon Whitcraft Indianapolis Motor Speedway jwhitcraft@...
Phone: [phone] :: Fax: [phone]

---

From: Xavier Vidal Piera [mailto:xavividal@...]
Sent: Monday, December 03, 2007 10:17 AM
To: Whitcraft, Jon
Cc: Marko Korhonen; fw-mvc@...

Subject: Re: [fw-mvc] Shared Models in Different Modules

 

Yes

But i remember to do that in lowercase (module names are in lowercase), so i have all the folder structure in lower case.

At this moment, any way to organize better the model classes will be apreciated.

On Dec 3, 2007 2:09 PM, Whitcraft, Jon <jwhitcraft@...> wrote:

So if I understand you correctly, I should be able to do this

 

$story = new News_Models_Story();

 

Where this is my directory structure:

 

  ./modules/

       ./news/

            ./models/

                  Story.php

 

Correct?

 

 

	Jon Whitcraft Indianapolis Motor Speedway jwhitcraft@...
Phone: [phone] :: Fax: [phone]

---

From: Xavier Vidal Piera [mailto: xavividal@...]
Sent: Monday, December 03, 2007 7:54 AM
To: Marko Korhonen
Cc: fw-mvc@...
Subject: Re: [fw-mvc] Shared Models in Different Modules

 

I'm treating model classes as framework classes using the conventional naming to avoid namespace collisions, so all the model classes common to all the application are stored in default/models/ and are named Default_Models_* so they can be easily be localized. Of course, inside the model class the "real name" is set with protected $_name.

You can have model classes in another modules and be namespaced accordingly.

The autoload function will find this classes the same way it finds the Zend Libs and other classes.

On Dec 3, 2007 6:35 AM, Marko Korhonen <marko.korhonen@...> wrote:

Hi to all!

I made one folder to all my models, and I appended the include_path with the
path to this folder.

$models_path = APPLICATION_PATH ."My_Application/Model/";

// include $models_path to include_path somewhere

Then where ever in actions I might need some model I just make:
$model = new Page();

or something like that...

So these models are shared by all controllers & actions but not by all my
different applications.

br,
Marko
--
View this message in context: http://www.nabble.com/Shared-Models-in-Different-Modules-tf4932443s16154.html#a14124197
Sent from the Zend MVC mailing list archive at Nabble.com.

--
Xavier Vidal Piera
Enginyer Tècnic Informàtic de Gestió
Tècnic Especialista Informàtic d'equips
xavividal@...
xvidal@...
http://web.xaviervidal.net
610.68.41.78

********************

********************

This E-mail (and attachments) may contain confidential/privileged information intended only for the named addressee(s). If you are not an intended recipient, do not read, copy, disseminate or take any action based on the content of this E-mail. Please notify the sender by reply E-mail and erase this E-mail from your system. Your assistance is appreciated. E-mail transmission may not be secure or error-free. The company is not responsible for any loss/damage arising from any virus transmitted.

********************

********************

--
Xavier Vidal Piera
Enginyer Tècnic Informàtic de Gestió
Tècnic Especialista Informàtic d'equips
xavividal@...
xvidal@...
http://web.xaviervidal.net
610.68.41.78

--
Xavier Vidal Piera
Enginyer Tècnic Informàtic de Gestió
Tècnic Especialista Informàtic d'equips
xavividal@...
xvidal@...
http://web.xaviervidal.net
610.68.41.78

[Behzad-3]

In my opinion, there is a problem with ZF's naming scheme for MVC components, regardless
of our current discussion.

Zend_Loader defines a scheme to load classes. You're encouraged to follow this scheme
within your ZF-based application: Zend_Loader('X_Y_Z') loads X\Y\Z.php.

Why ZF itself doesn't follow this scheme to "name and store" controllers and models?
Inconsistent naming schemes leads to confusion; something which happens all the time
to me when I want to name classes in ZF. "It makes me and you to Think!".

There is an upcoming component "Zend_Controller_Action_Helper_ModelLoader" to solve
models loading problem. I think that's a patch to solve the problem.
If ZF-ians follow a standard naming scheme through their framework,
these problems won't arise at all and we won't need these patches.

Regards,

On Dec 3, 2007 8:03 PM, Xavier Vidal Piera < xavividal@...> wrote:

The only reason to make that model classes named that way is to avoid namespace collisions, but you can name that classes as you like. The problem will appear if someday a class named Story appears (from another package or external lib), any attempt to use two classes with the same name will throw an error.

On Dec 3, 2007 4:51 PM, Whitcraft, Jon <jwhitcraft@...> wrote:

Xavier,

 

I ran into that problem too.  I just refactored the class name to be new_Models_Story which makes no sense but it works for right now and going back later to refactor once it gets all figured out wont be too hard as the Zend Neon Beta does a good job of finding all the occurrences of that class.

 

Cheers

 

	Jon Whitcraft Indianapolis Motor Speedway jwhitcraft@...
Phone: [phone] :: Fax: [phone]

---

From: Xavier Vidal Piera [mailto:xavividal@...]
Sent: Monday, December 03, 2007 10:17 AM
To: Whitcraft, Jon
Cc: Marko Korhonen; fw-mvc@...

Subject: Re: [fw-mvc] Shared Models in Different Modules

 

Yes

But i remember to do that in lowercase (module names are in lowercase), so i have all the folder structure in lower case.

At this moment, any way to organize better the model classes will be apreciated.

On Dec 3, 2007 2:09 PM, Whitcraft, Jon <jwhitcraft@...> wrote:

So if I understand you correctly, I should be able to do this

 

$story = new News_Models_Story();

 

Where this is my directory structure:

 

  ./modules/

       ./news/

            ./models/

                  Story.php

 

Correct?

 

 

	Jon Whitcraft Indianapolis Motor Speedway jwhitcraft@...
Phone: [phone] :: Fax: [phone]

---

From: Xavier Vidal Piera [mailto: xavividal@...]
Sent: Monday, December 03, 2007 7:54 AM
To: Marko Korhonen
Cc: fw-mvc@...
Subject: Re: [fw-mvc] Shared Models in Different Modules

 

I'm treating model classes as framework classes using the conventional naming to avoid namespace collisions, so all the model classes common to all the application are stored in default/models/ and are named Default_Models_* so they can be easily be localized. Of course, inside the model class the "real name" is set with protected $_name.

You can have model classes in another modules and be namespaced accordingly.

The autoload function will find this classes the same way it finds the Zend Libs and other classes.

On Dec 3, 2007 6:35 AM, Marko Korhonen <marko.korhonen@...> wrote:

Hi to all!

I made one folder to all my models, and I appended the include_path with the
path to this folder.

$models_path = APPLICATION_PATH ."My_Application/Model/";

// include $models_path to include_path somewhere

Then where ever in actions I might need some model I just make:
$model = new Page();

or something like that...

So these models are shared by all controllers & actions but not by all my
different applications.

br,
Marko
--
View this message in context: http://www.nabble.com/Shared-Models-in-Different-Modules-tf4932443s16154.html#a14124197
Sent from the Zend MVC mailing list archive at Nabble.com.

--
Xavier Vidal Piera
Enginyer Tècnic Informàtic de Gestió
Tècnic Especialista Informàtic d'equips
xavividal@...
xvidal@...
http://web.xaviervidal.net
610.68.41.78

********************

********************

This E-mail (and attachments) may contain confidential/privileged information intended only for the named addressee(s). If you are not an intended recipient, do not read, copy, disseminate or take any action based on the content of this E-mail. Please notify the sender by reply E-mail and erase this E-mail from your system. Your assistance is appreciated. E-mail transmission may not be secure or error-free. The company is not responsible for any loss/damage arising from any virus transmitted.

********************

********************

--
Xavier Vidal Piera
Enginyer Tècnic Informàtic de Gestió
Tècnic Especialista Informàtic d'equips
xavividal@...
xvidal@...
http://web.xaviervidal.net
610.68.41.78

--
Xavier Vidal Piera
Enginyer Tècnic Informàtic de Gestió
Tècnic Especialista Informàtic d'equips
xavividal@...
xvidal@...
http://web.xaviervidal.net
610.68.41.78

[jwhitcraft]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Yes that does look like it would help some but then you are calling more code that what I believe is needed.

 

Why can’t the Zend_Loader take into account modules so then you don’t have to have a helper and such.

 

I want it to be autoloaded and not have to call $this->_helper->ModuleLoader(‘News_Story’) when ever I need the news story object.

 

Does that make sense?

 

	Jon Whitcraft Indianapolis Motor Speedway jwhitcraft@...
Phone: [phone] :: Fax: [phone]

---

From: AmirBehzad Eslami [mailto:behzad.eslami@...]
Sent: Monday, December 03, 2007 12:33 PM
To: Xavier Vidal Piera
Cc: Whitcraft, Jon; Marko Korhonen; fw-mvc@...
Subject: Re: [fw-mvc] Shared Models in Different Modules

 

In my opinion, there is a problem with ZF's naming scheme for MVC components, regardless
of our current discussion.

Zend_Loader defines a scheme to load classes. You're encouraged to follow this scheme
within your ZF-based application: Zend_Loader('X_Y_Z') loads X\Y\Z.php.

Why ZF itself doesn't follow this scheme to "name and store" controllers and models?
Inconsistent naming schemes leads to confusion; something which happens all the time
to me when I want to name classes in ZF. "It makes me and you to Think!".

There is an upcoming component "Zend_Controller_Action_Helper_ModelLoader" to solve
models loading problem. I think that's a patch to solve the problem.
If ZF-ians follow a standard naming scheme through their framework,
these problems won't arise at all and we won't need these patches.

Regards,

On Dec 3, 2007 8:03 PM, Xavier Vidal Piera < xavividal@...> wrote:

The only reason to make that model classes named that way is to avoid namespace collisions, but you can name that classes as you like. The problem will appear if someday a class named Story appears (from another package or external lib), any attempt to use two classes with the same name will throw an error.

 

On Dec 3, 2007 4:51 PM, Whitcraft, Jon <jwhitcraft@...> wrote:

Xavier,

 

I ran into that problem too.  I just refactored the class name to be new_Models_Story which makes no sense but it works for right now and going back later to refactor once it gets all figured out wont be too hard as the Zend Neon Beta does a good job of finding all the occurrences of that class.

 

Cheers

 

	Jon Whitcraft Indianapolis Motor Speedway jwhitcraft@...
Phone: [phone] :: Fax: [phone]

---

From: Xavier Vidal Piera [mailto:xavividal@...]
Sent: Monday, December 03, 2007 10:17 AM
To: Whitcraft, Jon
Cc: Marko Korhonen; fw-mvc@...

Subject: Re: [fw-mvc] Shared Models in Different Modules

 

Yes

But i remember to do that in lowercase (module names are in lowercase), so i have all the folder structure in lower case.

At this moment, any way to organize better the model classes will be apreciated.

On Dec 3, 2007 2:09 PM, Whitcraft, Jon <jwhitcraft@...> wrote:

So if I understand you correctly, I should be able to do this

 

$story = new News_Models_Story();

 

Where this is my directory structure:

 

  ./modules/

       ./news/

            ./models/

                  Story.php

 

Correct?

 

 

	Jon Whitcraft Indianapolis Motor Speedway jwhitcraft@...
Phone: [phone] :: Fax: [phone]

---

From: Xavier Vidal Piera [mailto: xavividal@...]
Sent: Monday, December 03, 2007 7:54 AM
To: Marko Korhonen
Cc: fw-mvc@...
Subject: Re: [fw-mvc] Shared Models in Different Modules

 

I'm treating model classes as framework classes using the conventional naming to avoid namespace collisions, so all the model classes common to all the application are stored in default/models/ and are named Default_Models_* so they can be easily be localized. Of course, inside the model class the "real name" is set with protected $_name.

You can have model classes in another modules and be namespaced accordingly.

The autoload function will find this classes the same way it finds the Zend Libs and other classes.

On Dec 3, 2007 6:35 AM, Marko Korhonen <marko.korhonen@...> wrote:

Hi to all!

I made one folder to all my models, and I appended the include_path with the
path to this folder.

$models_path = APPLICATION_PATH ."My_Application/Model/";

// include $models_path to include_path somewhere

Then where ever in actions I might need some model I just make:
$model = new Page();

or something like that...

So these models are shared by all controllers & actions but not by all my
different applications.

br,
Marko
--
View this message in context: http://www.nabble.com/Shared-Models-in-Different-Modules-tf4932443s16154.html#a14124197
Sent from the Zend MVC mailing list archive at Nabble.com.

--
Xavier Vidal Piera
Enginyer Tècnic Informàtic de Gestió
Tècnic Especialista Informàtic d'equips
xavividal@...
xvidal@...
http://web.xaviervidal.net
610.68.41.78

********************

********************

This E-mail (and attachments) may contain confidential/privileged information intended only for the named addressee(s). If you are not an intended recipient, do not read, copy, disseminate or take any action based on the content of this E-mail. Please notify the sender by reply E-mail and erase this E-mail from your system. Your assistance is appreciated. E-mail transmission may not be secure or error-free. The company is not responsible for any loss/damage arising from any virus transmitted.

********************

********************

--
Xavier Vidal Piera
Enginyer Tècnic Informàtic de Gestió
Tècnic Especialista Informàtic d'equips
xavividal@...
xvidal@...
http://web.xaviervidal.net
610.68.41.78

--
Xavier Vidal Piera
Enginyer Tècnic Informàtic de Gestió
Tècnic Especialista Informàtic d'equips
xavividal@...
xvidal@...
http://web.xaviervidal.net
610.68.41.78

 

[Behzad-3]

That's exactly what i am talking about it, and, yes, it requires a massive shift.

Why should we use:
$this->_helper->ModuleLoader('News_Story');
instead of:
Zend_Loader::loadClass('News_Story');
?

To achieve this, we should follow a consistent naming scheme
among controllers and models, and that scheme should be compatible
with Zend_Loader.

Forget the models for a moment, but the inconsistency still remains:
Currently, we name our controllers X_Y_Z,
but we store them in X/controllers/ZY.php !

What's wrong with: X/Y/Z.php ? It's compatible with Zend_Loader.

Zend_Loader and its scheme is created to facilitate loading classes in a
Modular-MVC architecute, whereas it is currently unable to achieve this,
because of inconsistent naming schemes.

Zend_Loader::loadClass('Foo_Controller_Bar');
// loads: foo/controllers/bar.php

Zend_Loader::loadClass('Foo_Model_Bar');
// loads: foo/models/bar.php

Not only this naming scheme keeps the directory structure which is
recommend in the manual, but also it allows the Zend_Loader to load
every class in the MVC-architecture, and no patches is required.

[wllm]

Some parts of this message have been removed. Learn more about Nabble's security policy.

I have to begin by saying that I don’t have as much context as you guys  do with the MVC components. That said, I firmly believe that we do not have to establish rigid conventions for the location of any resources. I have am currently writing up the proposal for Zend_Build which includes the capturing of project metadata that would make such auto-loading feasible. I haven’t thought about changing the loader to use this MD, but if you feel this would be useful, please leave comments here to explain how this might fit in to the whole system with MD: http://framework.zend.com/wiki/display/ZFPROP/Zend_Build+-+Wil+Sinclair

 

Thanks.

,Wil

 

From: Whitcraft, Jon [mailto:jwhitcraft@...]
Sent: Monday, December 03, 2007 9:38 AM
To: AmirBehzad Eslami; Xavier Vidal Piera
Cc: Marko Korhonen; fw-mvc@...
Subject: RE: [fw-mvc] Shared Models in Different Modules

 

Yes that does look like it would help some but then you are calling more code that what I believe is needed.

 

Why can’t the Zend_Loader take into account modules so then you don’t have to have a helper and such.

 

I want it to be autoloaded and not have to call $this->_helper->ModuleLoader(‘News_Story’) when ever I need the news story object.

 

Does that make sense?

 

	Jon Whitcraft Indianapolis Motor Speedway jwhitcraft@...
Phone: [phone] :: Fax: [phone]

---

From: AmirBehzad Eslami [mailto:behzad.eslami@...]
Sent: Monday, December 03, 2007 12:33 PM
To: Xavier Vidal Piera
Cc: Whitcraft, Jon; Marko Korhonen; fw-mvc@...
Subject: Re: [fw-mvc] Shared Models in Different Modules

 

In my opinion, there is a problem with ZF's naming scheme for MVC components, regardless
of our current discussion.

Zend_Loader defines a scheme to load classes. You're encouraged to follow this scheme
within your ZF-based application: Zend_Loader('X_Y_Z') loads X\Y\Z.php.

Why ZF itself doesn't follow this scheme to "name and store" controllers and models?
Inconsistent naming schemes leads to confusion; something which happens all the time
to me when I want to name classes in ZF. "It makes me and you to Think!".

There is an upcoming component "Zend_Controller_Action_Helper_ModelLoader" to solve
models loading problem. I think that's a patch to solve the problem.
If ZF-ians follow a standard naming scheme through their framework,
these problems won't arise at all and we won't need these patches.

Regards,

On Dec 3, 2007 8:03 PM, Xavier Vidal Piera < xavividal@...> wrote:

The only reason to make that model classes named that way is to avoid namespace collisions, but you can name that classes as you like. The problem will appear if someday a class named Story appears (from another package or external lib), any attempt to use two classes with the same name will throw an error.

 

On Dec 3, 2007 4:51 PM, Whitcraft, Jon <jwhitcraft@...> wrote:

Xavier,

 

I ran into that problem too.  I just refactored the class name to be new_Models_Story which makes no sense but it works for right now and going back later to refactor once it gets all figured out wont be too hard as the Zend Neon Beta does a good job of finding all the occurrences of that class.

 

Cheers

 

	Jon Whitcraft Indianapolis Motor Speedway jwhitcraft@...
Phone: [phone] :: Fax: [phone]

---

From: Xavier Vidal Piera [mailto:xavividal@...]
Sent: Monday, December 03, 2007 10:17 AM
To: Whitcraft, Jon
Cc: Marko Korhonen; fw-mvc@...

Subject: Re: [fw-mvc] Shared Models in Different Modules

 

Yes

But i remember to do that in lowercase (module names are in lowercase), so i have all the folder structure in lower case.

At this moment, any way to organize better the model classes will be apreciated.

On Dec 3, 2007 2:09 PM, Whitcraft, Jon <jwhitcraft@...> wrote:

So if I understand you correctly, I should be able to do this

 

$story = new News_Models_Story();

 

Where this is my directory structure:

 

  ./modules/

       ./news/

            ./models/

                  Story.php

 

Correct?

 

 

	Jon Whitcraft Indianapolis Motor Speedway jwhitcraft@...
Phone: [phone] :: Fax: [phone]

---

From: Xavier Vidal Piera [mailto: xavividal@...]
Sent: Monday, December 03, 2007 7:54 AM
To: Marko Korhonen
Cc: fw-mvc@...
Subject: Re: [fw-mvc] Shared Models in Different Modules

 

I'm treating model classes as framework classes using the conventional naming to avoid namespace collisions, so all the model classes common to all the application are stored in default/models/ and are named Default_Models_* so they can be easily be localized. Of course, inside the model class the "real name" is set with protected $_name.

You can have model classes in another modules and be namespaced accordingly.

The autoload function will find this classes the same way it finds the Zend Libs and other classes.

On Dec 3, 2007 6:35 AM, Marko Korhonen <marko.korhonen@...> wrote:

Hi to all!

I made one folder to all my models, and I appended the include_path with the
path to this folder.

$models_path = APPLICATION_PATH ."My_Application/Model/";

// include $models_path to include_path somewhere

Then where ever in actions I might need some model I just make:
$model = new Page();

or something like that...

So these models are shared by all controllers & actions but not by all my
different applications.

br,
Marko
--
View this message in context: http://www.nabble.com/Shared-Models-in-Different-Modules-tf4932443s16154.html#a14124197
Sent from the Zend MVC mailing list archive at Nabble.com.

--
Xavier Vidal Piera
Enginyer Tècnic Informàtic de Gestió
Tècnic Especialista Informàtic d'equips
xavividal@...
xvidal@...
http://web.xaviervidal.net
610.68.41.78

********************

********************

This E-mail (and attachments) may contain confidential/privileged information intended only for the named addressee(s). If you are not an intended recipient, do not read, copy, disseminate or take any action based on the content of this E-mail. Please notify the sender by reply E-mail and erase this E-mail from your system. Your assistance is appreciated. E-mail transmission may not be secure or error-free. The company is not responsible for any loss/damage arising from any virus transmitted.

********************

********************

--
Xavier Vidal Piera
Enginyer Tècnic Informàtic de Gestió
Tècnic Especialista Informàtic d'equips
xavividal@...
xvidal@...
http://web.xaviervidal.net
610.68.41.78

--
Xavier Vidal Piera
Enginyer Tècnic Informàtic de Gestió
Tècnic Especialista Informàtic d'equips
xavividal@...
xvidal@...
http://web.xaviervidal.net
610.68.41.78

 

[Behzad-3]

correcting a typo:

Currently, we name our controllers X_YZ,
but we store them in X/controlles/YZ.php !

How about X_Y_Z @ X/Y/Z.php ?

[Ralph Schindler]

I'll chime in here with some contextual background, perhaps that might
help you understand the ideas at play.

One important notion to keep in mind is the difference between library
layer code and application layer code.  Essentially, all Zend Framework
components are considered "library" code.  They are unit testable, live
in a very well defined pseudo-namespace and as such are named according
to the pseudo-namespace rule.  IE: Zend_Loader is Zend/Loader.php.  The
reason this works so well is b/c there is a requirement that ZF exists
inside PHP's include_path.

On the other side of the coin is the application layer code.  This
includes (But is not limited to current) View Scripts, Controller
Scripts and Models.  Typically, in ZF's MVC file structure, they can be
found in ./moduleName/views/, ./moduleName/controllers/, and
./moduleName/models/ respectively.  Bear in mind, these paths ARE NOT i
your php-inclue path.

Moving along, (this is a matter of personal taste), I prefer model
purism in my model classes and objects.  This means that I typcially
name my models (for example): Blog_User.  This means that the model
class User exists within the realm of the Blog module.  This naming
convention keeps the class names away from collisions as well as
provides the simplest cleanest name for my application to reference.

Another note (from my personal perspective), is that is A GOOD THING (r)
that the word controller is in the controller file name as that removes
itself from potential confusion between model file names and controller
files (its serves as a visual cue).  But that can be argued either way.

ALL OF THAT SAID: there is a solution for loading classes and files at
runtime that do not exist inside PHP's include_path.  If you look in the
incubator, you will see Zend/Loader/PluginLoader.php.  It will be
documented over the next week and half, and I think you will find it
immensely useful when it comes to loading application-layer code with
arbitrary (developer friendly) namings in arbitrary (again read:
developer friendly) file locations.

The future of ModelLoader btw, will be revisited once PluginLoader is
fully documented.

Hope that helps,
Ralph

AmirBehzad Eslami wrote:

> That's exactly what i am talking about it, and, yes, it requires a
> massive shift.
>
> Why should we use:
> $this->_helper->ModuleLoader('News_Story');
> instead of:
> Zend_Loader::loadClass('News_Story');
> ?
>
> To achieve this, we should follow a consistent naming scheme
> among controllers and models, and that scheme should be compatible
> with Zend_Loader.
>
> Forget the models for a moment, but the inconsistency still remains:
> *Currently, we name our controllers X_Y_Z,
> but we store them in X/controllers/ZY.php !*
>
> What's wrong with: X/Y/Z.php ? It's compatible with Zend_Loader.
>
> Zend_Loader and its scheme is created to facilitate loading classes in a
> Modular-MVC architecute, whereas it is currently unable to achieve this,
> because of inconsistent naming schemes.
>
> Zend_Loader::loadClass('Foo_Controller_Bar');
> // loads: foo/controllers/bar.php
>
> Zend_Loader::loadClass('Foo_Model_Bar');
> // loads: foo/models/bar.php
>
> Not only this naming scheme keeps the directory structure which is
> recommend in the manual, but also it allows the Zend_Loader to load
> every class in the MVC-architecture, and no patches is required.

[Behzad-3]

Dear Ralph,
Thanks a lot for the contextual background. I really appreciate it.

Perhaps I was in the wrong path. My conclusion is:
The Zend_Loader should be used to load "library layer code".
Therefore, using the Zend_Loader to load models is technically wrong,
since the models are part of the application layer code.
Please correct me if I'm still wrong.

BTW, what is the current stable method to load application layer code?
Plugins?

On Dec 3, 2007 9:48 PM, Ralph Schindler <ralph@...> wrote:

I'll chime in here with some contextual background, perhaps that might
help you understand the ideas at play.

One important notion to keep in mind is the difference between library
layer code and application layer code.  Essentially, all Zend Framework
components are considered "library" code.  They are unit testable, live
in a very well defined pseudo-namespace and as such are named according
to the pseudo-namespace rule.  IE: Zend_Loader is Zend/Loader.php.  The
reason this works so well is b/c there is a requirement that ZF exists
inside PHP's include_path.

On the other side of the coin is the application layer code.  This
includes (But is not limited to current) View Scripts, Controller
Scripts and Models.  Typically, in ZF's MVC file structure, they can be
found in ./moduleName/views/, ./moduleName/controllers/, and
./moduleName/models/ respectively.  Bear in mind, these paths ARE NOT i
your php-inclue path.

Moving along, (this is a matter of personal taste), I prefer model
purism in my model classes and objects.  This means that I typcially
name my models (for example): Blog_User.  This means that the model
class User exists within the realm of the Blog module.  This naming
convention keeps the class names away from collisions as well as
provides the simplest cleanest name for my application to reference.

Another note (from my personal perspective), is that is A GOOD THING (r)
that the word controller is in the controller file name as that removes
itself from potential confusion between model file names and controller
files (its serves as a visual cue).  But that can be argued either way.

ALL OF THAT SAID: there is a solution for loading classes and files at
runtime that do not exist inside PHP's include_path.  If you look in the
incubator, you will see Zend/Loader/PluginLoader.php.  It will be
documented over the next week and half, and I think you will find it
immensely useful when it comes to loading application-layer code with
arbitrary (developer friendly) namings in arbitrary (again read:
developer friendly) file locations.

The future of ModelLoader btw, will be revisited once PluginLoader is
fully documented.

Hope that helps,
Ralph

AmirBehzad Eslami wrote:

> That's exactly what i am talking about it, and, yes, it requires a
> massive shift.
>
> Why should we use:
> $this->_helper->ModuleLoader('News_Story');
> instead of:
> Zend_Loader::loadClass('News_Story');
> ?
>
> To achieve this, we should follow a consistent naming scheme
> among controllers and models, and that scheme should be compatible
> with Zend_Loader.
>
> Forget the models for a moment, but the inconsistency still remains:
> *Currently, we name our controllers X_Y_Z,
> but we store them in X/controllers/ZY.php !*
>
> What's wrong with: X/Y/Z.php ? It's compatible with Zend_Loader.
>
> Zend_Loader and its scheme is created to facilitate loading classes in a
> Modular-MVC architecute, whereas it is currently unable to achieve this,
> because of inconsistent naming schemes.

>
> Zend_Loader::loadClass('Foo_Controller_Bar');
> // loads: foo/controllers/bar.php
>
> Zend_Loader::loadClass('Foo_Model_Bar');
> // loads: foo/models/bar.php
>
> Not only this naming scheme keeps the directory structure which is
> recommend in the manual, but also it allows the Zend_Loader to load
> every class in the MVC-architecture, and no patches is required.

[lcrouch]

Isn't it better to name the class
as Module_Controller_Index which is located at module/controllers/index.php ?

And it makes sense to apply the same principle to models.
Module_Model_MyModel.

 

I like this idea very much, I think. though honestly, I've not worked on multi-module ZF projects yet.

-L

[Ralph Schindler]

> BTW, what is the current stable method to load application layer code?
> Plugins?

Currently, without a stable ModelLoader action helper, I simply require
the needed model files at the top of my Action Controller file.  If you
want dynamic (runtime) loading of your models, you can include_once them
inside your actual Action methods.  The reason this is being developed
later rather than sooner is b/c if you look at the php community as a
whole, developers have some pretty strong feelings on the methods and
best practices that surround "Modeling in PHP".  Ultimately, whatever
Modeling best practice emerges, it needs to work well with the
Controller&View infrastructure that exists/will exist.

Other application code, like controllers and view scripts, are already
loaded and executed by the Zend_Controller and Zend_View stack.  For
autorendering of view scripts (at the end of an actions execution) you
should look at the ViewRenderer
(Zend_Controller_Action_Helper_ViewRenderer).  As far as actual Action
Controllers being loaded and executed, you should take a look at
Zend_Controller_Action and Zend_Controller_Front (specifically the
dispatch method).

While you are learning about all the "configurable-conventions" within
the Zend Framework, keep in mind that these paradigms the result of
researching existing systems, other languages, and determining what
best-practice would suit the community better.

[mmaru]

Let say we have a user table in the database used by the website that has different modules - blog, news, forums, etc. Where will you put the user class module in the application that is going to be used by all the modules?

Regards,

Maru

Ralph Schindler wrote:

I'll chime in here with some contextual background, perhaps that might
help you understand the ideas at play.

One important notion to keep in mind is the difference between library
layer code and application layer code.  Essentially, all Zend Framework
components are considered "library" code.  They are unit testable, live
in a very well defined pseudo-namespace and as such are named according
to the pseudo-namespace rule.  IE: Zend_Loader is Zend/Loader.php.  The
reason this works so well is b/c there is a requirement that ZF exists
inside PHP's include_path.

On the other side of the coin is the application layer code.  This
includes (But is not limited to current) View Scripts, Controller
Scripts and Models.  Typically, in ZF's MVC file structure, they can be
found in ./moduleName/views/, ./moduleName/controllers/, and
./moduleName/models/ respectively.  Bear in mind, these paths ARE NOT i
your php-inclue path.

Moving along, (this is a matter of personal taste), I prefer model
purism in my model classes and objects.  This means that I typcially
name my models (for example): Blog_User.  This means that the model
class User exists within the realm of the Blog module.  This naming
convention keeps the class names away from collisions as well as
provides the simplest cleanest name for my application to reference.

Another note (from my personal perspective), is that is A GOOD THING (r)
that the word controller is in the controller file name as that removes
itself from potential confusion between model file names and controller
files (its serves as a visual cue).  But that can be argued either way.

ALL OF THAT SAID: there is a solution for loading classes and files at
runtime that do not exist inside PHP's include_path.  If you look in the
incubator, you will see Zend/Loader/PluginLoader.php.  It will be
documented over the next week and half, and I think you will find it
immensely useful when it comes to loading application-layer code with
arbitrary (developer friendly) namings in arbitrary (again read:
developer friendly) file locations.

The future of ModelLoader btw, will be revisited once PluginLoader is
fully documented.

Hope that helps,
Ralph

AmirBehzad Eslami wrote:
> That's exactly what i am talking about it, and, yes, it requires a
> massive shift.
>
> Why should we use:
> $this->_helper->ModuleLoader('News_Story');
> instead of:
> Zend_Loader::loadClass('News_Story');
> ?
>
> To achieve this, we should follow a consistent naming scheme
> among controllers and models, and that scheme should be compatible
> with Zend_Loader.
>
> Forget the models for a moment, but the inconsistency still remains:
> *Currently, we name our controllers X_Y_Z,
> but we store them in X/controllers/ZY.php !*
>
> What's wrong with: X/Y/Z.php ? It's compatible with Zend_Loader.
>
> Zend_Loader and its scheme is created to facilitate loading classes in a
> Modular-MVC architecute, whereas it is currently unable to achieve this,
> because of inconsistent naming schemes.
>
> Zend_Loader::loadClass('Foo_Controller_Bar');
> // loads: foo/controllers/bar.php
>
> Zend_Loader::loadClass('Foo_Model_Bar');
> // loads: foo/models/bar.php
>
> Not only this naming scheme keeps the directory structure which is
> recommend in the manual, but also it allows the Zend_Loader to load
> every class in the MVC-architecture, and no patches is required.

[lcrouch]

maru,

I think in that case you might have a users module then? it may be a module that has only model classes, but it still might be reasonable to make a users module.

-L

On Dec 3, 2007 5:26 PM, mmaru < mulugetamaru@...> wrote:

Let say we have a user table in the database used by the website that has
different modules - blog, news, forums, etc. Where will you put the user
class module in the application that is going to be used by all the modules?

Regards,

Maru

Ralph Schindler wrote:

>
> I'll chime in here with some contextual background, perhaps that might
> help you understand the ideas at play.
>
> One important notion to keep in mind is the difference between library
> layer code and application layer code.  Essentially, all Zend Framework
> components are considered "library" code.  They are unit testable, live
> in a very well defined pseudo-namespace and as such are named according
> to the pseudo-namespace rule.  IE: Zend_Loader is Zend/Loader.php.  The
> reason this works so well is b/c there is a requirement that ZF exists
> inside PHP's include_path.
>
> On the other side of the coin is the application layer code.  This
> includes (But is not limited to current) View Scripts, Controller
> Scripts and Models.  Typically, in ZF's MVC file structure, they can be
> found in ./moduleName/views/, ./moduleName/controllers/, and
> ./moduleName/models/ respectively.  Bear in mind, these paths ARE NOT i
> your php-inclue path.
>
> Moving along, (this is a matter of personal taste), I prefer model
> purism in my model classes and objects.  This means that I typcially
> name my models (for example): Blog_User.  This means that the model
> class User exists within the realm of the Blog module.  This naming
> convention keeps the class names away from collisions as well as
> provides the simplest cleanest name for my application to reference.
>
> Another note (from my personal perspective), is that is A GOOD THING (r)
> that the word controller is in the controller file name as that removes
> itself from potential confusion between model file names and controller
> files (its serves as a visual cue).  But that can be argued either way.
>
> ALL OF THAT SAID: there is a solution for loading classes and files at
> runtime that do not exist inside PHP's include_path.  If you look in the
> incubator, you will see Zend/Loader/PluginLoader.php.  It will be
> documented over the next week and half, and I think you will find it
> immensely useful when it comes to loading application-layer code with
> arbitrary (developer friendly) namings in arbitrary (again read:
> developer friendly) file locations.
>
> The future of ModelLoader btw, will be revisited once PluginLoader is
> fully documented.
>
> Hope that helps,
> Ralph
>
> AmirBehzad Eslami wrote:
>> That's exactly what i am talking about it, and, yes, it requires a
>> massive shift.
>>
>> Why should we use:
>> $this->_helper->ModuleLoader('News_Story');
>> instead of:
>> Zend_Loader::loadClass('News_Story');
>> ?
>>
>> To achieve this, we should follow a consistent naming scheme
>> among controllers and models, and that scheme should be compatible
>> with Zend_Loader.
>>
>> Forget the models for a moment, but the inconsistency still remains:
>> *Currently, we name our controllers X_Y_Z,
>> but we store them in X/controllers/ZY.php !*
>>
>> What's wrong with: X/Y/Z.php ? It's compatible with Zend_Loader.
>>
>> Zend_Loader and its scheme is created to facilitate loading classes in a
>> Modular-MVC architecute, whereas it is currently unable to achieve this,
>> because of inconsistent naming schemes.
>>
>> Zend_Loader::loadClass('Foo_Controller_Bar');
>> // loads: foo/controllers/bar.php
>>
>> Zend_Loader::loadClass('Foo_Model_Bar');
>> // loads: foo/models/bar.php
>>
>> Not only this naming scheme keeps the directory structure which is
>> recommend in the manual, but also it allows the Zend_Loader to load
>> every class in the MVC-architecture, and no patches is required.
>
>
>

--
View this message in context: http://www.nabble.com/Shared-Models-in-Different-Modules-tf4932443s16154.html#a14141361

Sent from the Zend MVC mailing list archive at Nabble.com.

[Simon Mundy]

Let say we have a user table in the database used by the website that has
different modules - blog, news, forums, etc. Where will you put the user

class module in the application that is going to be used by all the modules?

I do things the lazy way :)

Let's assume I have 3 modules - 'default', 'module1' and 'module2'.

All my models and library-specific classes sit in the 'MyApp' namespace and are named according to the existing strategy (e.g. 'MyApp_Class').

A simple setup in the bootstrap allows Zend_Loader to do the heavy lifting:-

set_include_path(join(PATH_SEPARATOR, array(realpath('../application/default/models'),

                                            realpath('../library'),

                                            get_include_path()));

require_once('Zend/Loader.php');

Zend_Loader::registerAutoload();

This assumes an application structure of:-

/application/default/controllers/...

                    /modules/... (Global models)

                    /views/...

                    /layouts/...

/application/module1/controllers/...

                    /modules/... (Module-specific models)

                    /views/...

                    /layouts/...

/application/module2/controllers/...

                    /modules/... (Module-specific models)

                    /views/...

                    /layouts/...

/document_root/index.php (Bootstrap)

/library/Zend (Framework)

/library/MyApp (My library-specific classes)

Finally, inside my module-specific controllers I add the following:-

class Module1_IndexController extends Zend_Controller_Action

{

    public function init()

    {

        set_include_path(join(PATH_SEPARATOR, array(realpath('../application/module1/models'),

                                              get_include_path()));

    }

}

The advantages of this are:-

- No plugins or 'requires' are needed before I load my classes

- I can organise my models according to the modules they belong to - global models are accessible from any controller (or indeed model).

The disadvantages of this are:-

- I can't control the priority of include paths unless I do this manually using Zend_Loader or require statements

- This strategy must be completely adhered to across my whole application to function correctly.

This works well for me but only because I have a controlled environment - the real fun will come when I start to use plug'n'play modules from other developers.

So... in answer to your question, I'd determine the namespace for your application and then place your class file under a directory structure similar to above:-

/application/module1/module/MyApp/User.php = MyApp_User

--

Simon Mundy | Director | PEPTOLAB

""" " "" """""" "" "" """"""" " "" """"" " """"" "  """""" "" "

PeptoLab will be closed:

Saturday 15th  December through until Monday 17th December 

Saturday 22nd December through until Wednesday 2nd January

For urgent requests, please call 0438 046 061

202/258 Flinders Lane | Melbourne | Victoria | Australia | 3000

Voice [phone] | Mobile [phone] | Fax [phone]

http://www.peptolab.com

[mmaru]

Thank you for taking the time to answer my question in detail. Would you elaborate on the purpose of (Global models) and /library/MyApp (My library-specific classes). Where would you include models that are used by all modules?

Regards,

Maru

Simon Mundy wrote:

> Let say we have a user table in the database used by the website  
> that has
> different modules - blog, news, forums, etc. Where will you put the  
> user
> class module in the application that is going to be used by all the  
> modules?

I do things the lazy way :)

Let's assume I have 3 modules - 'default', 'module1' and 'module2'.

All my models and library-specific classes sit in the 'MyApp'  
namespace and are named according to the existing strategy (e.g.  
'MyApp_Class').

A simple setup in the bootstrap allows Zend_Loader to do the heavy  
lifting:-

set_include_path(join(PATH_SEPARATOR, array(realpath('../application/
default/models'),
                                             realpath('../library'),
                                             get_include_path()));
require_once('Zend/Loader.php');
Zend_Loader::registerAutoload();

This assumes an application structure of:-

/application/default/controllers/...
                     /modules/... (Global models)
                     /views/...
                     /layouts/...
/application/module1/controllers/...
                     /modules/... (Module-specific models)
                     /views/...
                     /layouts/...
/application/module2/controllers/...
                     /modules/... (Module-specific models)
                     /views/...
                     /layouts/...
/document_root/index.php (Bootstrap)
/library/Zend (Framework)
/library/MyApp (My library-specific classes)

Finally, inside my module-specific controllers I add the following:-

class Module1_IndexController extends Zend_Controller_Action
{
     public function init()
     {
         set_include_path(join(PATH_SEPARATOR, array(realpath('../
application/module1/models'),
                                               get_include_path()));
     }
}

The advantages of this are:-
- No plugins or 'requires' are needed before I load my classes
- I can organise my models according to the modules they belong to -  
global models are accessible from any controller (or indeed model).

The disadvantages of this are:-
- I can't control the priority of include paths unless I do this  
manually using Zend_Loader or require statements
- This strategy must be completely adhered to across my whole  
application to function correctly.

This works well for me but only because I have a controlled  
environment - the real fun will come when I start to use plug'n'play  
modules from other developers.

So... in answer to your question, I'd determine the namespace for your  
application and then place your class file under a directory structure  
similar to above:-

/application/module1/module/MyApp/User.php = MyApp_User

--

Simon Mundy | Director | PEPTOLAB

""" " "" """""" "" "" """"""" " "" """"" " """"" "  """""" "" "

PeptoLab will be closed:
Saturday 15th  December through until Monday 17th December
Saturday 22nd December through until Wednesday 2nd January
For urgent requests, please call 0438 046 061

202/258 Flinders Lane | Melbourne | Victoria | Australia | 3000
Voice [phone] | Mobile [phone] | Fax [phone]  
4124
http://www.peptolab.com

[Simon Mundy]

'Global' models are, for my purpose, those can be accessed anywhere in my application, be they from the bootstrap, a controller, another model or a view. So if I had a class called 'MyApp_User_Row' it would sit in /application/default/MyApp/User/Row.php and able to be found automatically by the __autoload function.

Technically (given the include paths I've given) there's no difference in putting this class in /library/MyApp or /application/default/models - it's more of an organisational strategy I have. All the 'scaffolding' and base library components that I use to augment the MVC process sit in /library/MyApp but all the application-specific business logic models sit within the application folder.

So anything related to my application-specific logic sits in /application/default/models and anything more related to library components sit in /library/MyApp

Hope that helps clear that up

Cheers

Thank you for taking the time to answer my question in detail. Would you
elaborate on the purpose of (Global models) and /library/MyApp (My
library-specific classes). Where would you include models that are used by
all modules? 

Regards,

Maru

--

Simon Mundy | Director | PEPTOLAB

""" " "" """""" "" "" """"""" " "" """"" " """"" "  """""" "" "

PeptoLab will be closed:

Saturday 15th  December through until Monday 17th December 

Saturday 22nd December through until Wednesday 2nd January

For urgent requests, please call 0438 046 061

202/258 Flinders Lane | Melbourne | Victoria | Australia | 3000

Voice [phone] | Mobile [phone] | Fax [phone]

http://www.peptolab.com

[mmaru]

Thank you Simon. It does indeed help.

Simon Mundy wrote:

'Global' models are, for my purpose, those can be accessed anywhere in  
my application, be they from the bootstrap, a controller, another  
model or a view. So if I had a class called 'MyApp_User_Row' it would  
sit in /application/default/MyApp/User/Row.php and able to be found  
automatically by the __autoload function.

Technically (given the include paths I've given) there's no difference  
in putting this class in /library/MyApp or /application/default/models  
- it's more of an organisational strategy I have. All the  
'scaffolding' and base library components that I use to augment the  
MVC process sit in /library/MyApp but all the application-specific  
business logic models sit within the application folder.

So anything related to my application-specific logic sits in /
application/default/models and anything more related to library  
components sit in /library/MyApp

Hope that helps clear that up

Cheers

>
> Thank you for taking the time to answer my question in detail. Would  
> you
> elaborate on the purpose of (Global models) and /library/MyApp (My
> library-specific classes). Where would you include models that are  
> used by
> all modules?
>
> Regards,
>
> Maru

--

Simon Mundy | Director | PEPTOLAB

""" " "" """""" "" "" """"""" " "" """"" " """"" "  """""" "" "

PeptoLab will be closed:
Saturday 15th  December through until Monday 17th December
Saturday 22nd December through until Wednesday 2nd January
For urgent requests, please call 0438 046 061

202/258 Flinders Lane | Melbourne | Victoria | Australia | 3000
Voice [phone] | Mobile [phone] | Fax [phone]  
4124
http://www.peptolab.com

[Rob Allen-3]

On 4 Dec 2007, at 00:03, Luke Crouch wrote:

> maru,
>
> I think in that case you might have a users module then? it may be a  
> module that has only model classes, but it still might be reasonable  
> to make a users module.
>

This is what I do too.

Regards,

Rob...

[Xavier Vidal]

I'll put that table in the default module

On Dec 4, 2007 12:26 AM, mmaru <mulugetamaru@...> wrote:

Let say we have a user table in the database used by the website that has
different modules - blog, news, forums, etc. Where will you put the user
class module in the application that is going to be used by all the modules?

Regards,

Maru

Ralph Schindler wrote:

>
> I'll chime in here with some contextual background, perhaps that might
> help you understand the ideas at play.
>
> One important notion to keep in mind is the difference between library
> layer code and application layer code.  Essentially, all Zend Framework
> components are considered "library" code.  They are unit testable, live
> in a very well defined pseudo-namespace and as such are named according
> to the pseudo-namespace rule.  IE: Zend_Loader is Zend/Loader.php.  The
> reason this works so well is b/c there is a requirement that ZF exists
> inside PHP's include_path.
>
> On the other side of the coin is the application layer code.  This
> includes (But is not limited to current) View Scripts, Controller
> Scripts and Models.  Typically, in ZF's MVC file structure, they can be
> found in ./moduleName/views/, ./moduleName/controllers/, and
> ./moduleName/models/ respectively.  Bear in mind, these paths ARE NOT i
> your php-inclue path.
>
> Moving along, (this is a matter of personal taste), I prefer model
> purism in my model classes and objects.  This means that I typcially
> name my models (for example): Blog_User.  This means that the model
> class User exists within the realm of the Blog module.  This naming
> convention keeps the class names away from collisions as well as
> provides the simplest cleanest name for my application to reference.
>
> Another note (from my personal perspective), is that is A GOOD THING (r)
> that the word controller is in the controller file name as that removes
> itself from potential confusion between model file names and controller
> files (its serves as a visual cue).  But that can be argued either way.
>
> ALL OF THAT SAID: there is a solution for loading classes and files at
> runtime that do not exist inside PHP's include_path.  If you look in the
> incubator, you will see Zend/Loader/PluginLoader.php.  It will be
> documented over the next week and half, and I think you will find it
> immensely useful when it comes to loading application-layer code with
> arbitrary (developer friendly) namings in arbitrary (again read:
> developer friendly) file locations.
>
> The future of ModelLoader btw, will be revisited once PluginLoader is
> fully documented.
>
> Hope that helps,
> Ralph
>
> AmirBehzad Eslami wrote:
>> That's exactly what i am talking about it, and, yes, it requires a
>> massive shift.
>>
>> Why should we use:
>> $this->_helper->ModuleLoader('News_Story');
>> instead of:
>> Zend_Loader::loadClass('News_Story');
>> ?
>>
>> To achieve this, we should follow a consistent naming scheme
>> among controllers and models, and that scheme should be compatible
>> with Zend_Loader.
>>
>> Forget the models for a moment, but the inconsistency still remains:
>> *Currently, we name our controllers X_Y_Z,
>> but we store them in X/controllers/ZY.php !*
>>
>> What's wrong with: X/Y/Z.php ? It's compatible with Zend_Loader.
>>
>> Zend_Loader and its scheme is created to facilitate loading classes in a
>> Modular-MVC architecute, whereas it is currently unable to achieve this,
>> because of inconsistent naming schemes.
>>
>> Zend_Loader::loadClass('Foo_Controller_Bar');
>> // loads: foo/controllers/bar.php
>>
>> Zend_Loader::loadClass('Foo_Model_Bar');
>> // loads: foo/models/bar.php
>>
>> Not only this naming scheme keeps the directory structure which is
>> recommend in the manual, but also it allows the Zend_Loader to load
>> every class in the MVC-architecture, and no patches is required.
>
>
>

--
View this message in context: http://www.nabble.com/Shared-Models-in-Different-Modules-tf4932443s16154.html#a14141361
Sent from the Zend MVC mailing list archive at Nabble.com.

--
Xavier Vidal Piera
Enginyer Tècnic Informàtic de Gestió
Tècnic Especialista Informàtic d'equips
xavividal@...
xvidal@...
http://web.xaviervidal.net
610.68.41.78

[Federico Cargnelutti]

It would be nice if ZF could do something like this:

$blogModel = $this->getModel('Blog_UsersModel');
$blogModel->getUsersByName();

And same for the modules:

// Returns an instance of BlogController
$blogModule = $this->getModule('Blog');
$blogModule->editAction();

That's how I'm basically doing it. I wrote some documentation about this in my site: http://trex.phpimpact.com/documentation/getting-started/models/

Regards,

Federico

AmirBehzad Eslami-3 wrote:

Hi List,

I asked a question about Shared View Scripts some days ago
and you recommend me to use Zend_Layout. I have a similiar
question about Models in a modular-dir-structure.

A website always has a homepage, which usually consists
of links to other sections (modules). Thus, the default modules
should have access to other modules' models.

Isn't this an architectural disease? It sounds that these shared
models are destroying the Modular-based building.

How can I have access to different models in different modules.
It is critical for default module (homepage) to have access to
whole website's content.

What is the best place to put centralized code (including
bootstraper, shared views, shared models?)