It doesn’t look like that is the signature. This is a widget inside of the module. The widget is called directly within the main part of the app (or should I have it some other way?). The reason I have it in a module is because it also has a spacial controller and module for doing ajax stuff with the widget.
Edit: Yeah I updated my SVN, still same error
I see. I thought it's init() of the module class.
So you are using the widget outside of the module? If there is no active module (the current controller belongs to the application, not the module), you won't have the 'module' alias.
Actually, this is an interesting problem. That is, how should we reference files inside a module when the module is not running? I don't have a good solution ATM. Maybe we can think together about this.
Of course this works in the widget:
<?php
Yii::import('application.modules.TextEdit.models.*');
As you said though, we don't necessarily know where modules are installed. So how I am calling the widget doesn't really make sense either:
<?php
<?php $this->widget('application.modules.TextEdit.components.TextEditor', array('id'=>'home1')); ?>
Perhaps a new alias should be generated for every module, with this signature:
module_moduleId
ex: module_forum
Not clean though…
or perhaps if you did something like this:
application.modules.moduleId
it would automatically know that moduleId is a module id, because it was preceded by modules
That's a good idea. Perhaps use the module class name as the root alias.
For example, a ForumModule would result in 'ForumModule' alias referring to the base path of the ForumModule.
Such alias can be created on-the-fly when it is referenced for the first time.
A drawback of my proposal is when a module is used as sub-module in several module, it would have trouble.
Good idea.
[SIZE=1][FONT=arial]__________________
devices exercises patches pills weightloss reviews webhost reviews casinos computer dating education
Ok, here's what I plan to do. Please help me check if there is any loophole in it.
For every module directly or indirectly under an application, we will define its module ID as a root alias. Such definition does not occur until you call Yii::getPathOfAlias() or until the module is being activated.
In case when a module A is a sub-module of module B, the alias A will not be defined unless B is already defined (that means, you can't bypass B to access A in the application).
It is possible that A is a sub-module of module B and at the same time A is a direct module of application. In this case, we have a conflict in alias. However, if reality, we rarely use A in this way. And even if we do so, it is not very likely we need to access both A modules at the same time.
I tried doing a very simple test by accessing a module controller action and it did not work. I got a Unable to resolve the request "module1/test" message.
http://www.yii.local…?r=module1/test
where test is my DefaultController actionTest method.
But this worked and showed the indexAction as expected:
You need to use r=module1/default/test
Quote
Thanks for the quick reply! That worked.
Okay, but to me it feels more intuitive and natural if it worked like this.
For example, my module is called 'blog' and I have actionIndex and actionView
If my controller is also called 'BlogController', then I should be able to access it like this:
r=blog/view/id/100 for example instead of r=blog/blog/view/id/100
In other words, We should be able to access the DefaultController actions without having to specifically type in 'module1/default/action' and just 'module1/action'.
In order for this to work, there must exist a controller that is same name is the module as the default controller to distinguish from other controllers that might be in the module.
What do you think?
How do we configure custom routing for a module? In other words, is there support for settings in /module1/config/main.php ?
What if you also have a ViewController?
What should r=blog/view be resolved into?
If you rename your BlogController to PostController, you will see that r=blog/post/view is actually very meaningful.
You need to configure routes at application level.
I can see how the blog/post example would fit in current style b/c a post is part of a blog (even if blog is just a conceptual thing). But is it common to build a whole separate controller for just for a view? In my experience its not. Nor will every module follow the blog/post concept.
If had a Photo module and wanted to do photo/view, does that mean I need to build a ViewController also? Why can't I just put the actionView, actionUpdate, actionCreate in my Photo Controller and access it like r=photo/view along with r=photo/update, r=photo/create. Under the current convention I would need to build a EditController and UpdateController respectively also?
Or I would have to come up with some creating naming for the 'photo' module and the 'DefaultController' so I don't end up doing /photo/default/view.
Same goes for a Video module. r=video/play, r=video/edit
In fact, one would always have to rename the DefaultController to avoid the 'module_name/default/action' format.
It could be a matter of preference, I've been used to the way I explained but am certainly open to adapting to what's available =)
To answer your scenario:
What if you also have a ViewController?
What should r=blog/view be resolved into?
As I mentioned earlier, this should only apply if you have a controller the same name as your module folder, so module=blog and have a BlogController.
Then r=blog/view should resolve to the BlogController's actionView. In this case, it wouldn't make sense to have a ViewController. But I see how this could clash.
Would it make sense to support config file for modules, especially for custom routing? That way you can just drop in a module and it would work out of the box, without having to dilute the application config with module specific settings…
I'm just using the name 'view' as an example to show that your proposed route may have trouble in certain cases. In general, a module usually contains several controllers (if it only has a single controller, you don't really need a module).
Regarding module config files, it's more complex than you thought. Let's say the application uses 5 modules. In order to support custom module routing as you suggested, every config file of the modules needs to be loaded by the main application, even if none of the modules is being requested. This is a big performance hit.
Hi
Same Ideas importing from life…
Each module have their own config file, template/theme/, functions, class,libs, etc
full cell subsystem;
this work as an independent system, extending the framework libs
for example module messages:
modules/messages
--------/messages/Admin/ [this a sub-module with admin features]
--------/messages/lang/
--------/messages/block/ [code for display in specific layout]
--------/messages/views/
--------/messages/functions/
--------/messages/models/
--------/messages/index.php
--------/messages/SameController.php
--------/messages/postController.php
--------/messages/ReadController.php
--------/messages/version.php
<?
//version.php
same code:
$module[version]='1.2';
$module[autor]='Max Megabr';
$module[module_name]='Messages';
$module[module_dir]='messages';
$module[suported_actions]=array('list','add','delete','view','listarchive');
$module[has_admin]='1';
$module[block][1]='messages_last';
$module[block][2]='messages_top';
$module[menu][main]='/modules/index.php';
$module[menu][main]='/modules/index.php';
$module[menu][sub][1]='/modules/index.php?m=messages/list';
$module[menu][sub][2]='/modules/index.php?m=messages/listarchive';
//or another way
$module= new module extend mainYiiModule();
$module->version='1.2';
$module->autor='Max Megabr';
$module->module_name='Messages';
$module->module_dir='messages';
$module->has_admin='1';
$module->suporte_actions=array('list','add','delete','view');
?>
the index.php here is the sub-router; receiving params from urls coming from main index.php router
before anyone acess this aplication on
modules/messages/index.php
the main framework verify the global user permissions to the routed module/action
the module name is unique identifier in the framework
URL solutions
http://localhost/index.php?r=here STANDART aplication
http://localhost/index.php?r=user/list
http://localhost/index.php?m=here MODULE BASED aplication
http://localhost/index.php?m=messages/show
r= normal route
m= module route
also the framework can be an module system container of specific classes for modules… support:
/modules/system/
well…
What about module dependencies and DB installation scripts support?