[OriginalCopy]

Hi

I have created a new project on top of Yii (needless to say, a great framework).

You can find it at http://code.google.com/p/yii-modules/

I think the start page describes it pretty well
"A methodology of organizing self-contained modules and a collection of such modules on top of the Yii Framework"

For more details, keep an eye on the wiki.

However I want to make my point:
1. I think it has a great potential, but it cannot reach it without you
2. You are not allowed to think of it as being even in the alpha stage. It's merely a pilot project for now, a prototype
3. There is much room for improvement
4. I know many of you had already tried to create modular applications on top of yii. The "yii modules" project tries to unify the needs of such modular applications
5. At its core lies a very lightweight messaging system (LMS) for use across modules. I doubt it can get any lighter than that
6. Ever wondered how to create navigation menus from independent, stand-alone, completely individual modules? It uses LMS to do just that
7. It's worth taking a look at it. The LMS is much more powerful and multi-purpose than "building navigation menus from modules".
8. Did I say there's much room for improvements? VERY much! But please look at the general ideas behind the code and try figuring out if its worth contributing with patches, ideas, bug reports. Patches are highly appreciated.
9. I would be glad if some people would join me. However I won't simply call out for new members, because very often in the OSS world it happens people come by, submit a patch, and then you never hear from them. I've done that myself with other people's projects and I know the ones who do that are not malevolent. Neither was I. If you'd like to contribute because you consider you can benefit from it too, submit patches. "Excessively" active patch submitters will be granted commit access.
10. I don't "feel the yii way of doing things" yet, thus there may be some inflection points which are poorly designed. Feel free to point them out

Comments and constructive critique are welcome

[Y!!]

The hook system looks interesting. I will take a depper look soon. Thanks.

[OriginalCopy]

I thank you, you gave me advices when I didn't know how to go on while working on this.

I've updated the "design principles" wiki page with more details on hooks: http://code.google.c...esignPrinciples

[Y!!]

Hey just want to say I didn't found the time yet to really test this. May I ask what's your future plans for this?

[OriginalCopy]

My future plan is to improve it just as I need it, not at either a faster, nor at a slower pace, thus it's open source. For now, the TODO list is there. I'd like to see it growing [1], because I think it deserves it [2]. However I'm not going to push for creating interest into it artificially, which would only poison it, as an open-source project.

So if you'd like to join, you're welcome

--
[1] I will be working on it, as my time allows. But it would be much better if the community would get involved actively. It would be a win-win scenario for everyone
[2] It feels better than the much promoted "backend-frontent" modular approach I saw on the forum on a few occasions.

[Zeph]

Just some thoughts.

1. Each time an event is raised, the directory structure would have to be traversed to see if there are any hooks.
2. A module designer would have to raise a number of events to play well with other modules that would want to hook into it causing a search for a hook each time.
3. For each hook we implement, we would have to be fairly familiar with the module it is hooking into.
4. A module writer might anticipate the needs of other modules and not provide hooks in the right place.


a. Why not use a database? If we are dealing with extensible modules, we can assume that the web application is using a database.
b. Each module would derive from CExtensibleModule and CExtensibleController. These classes would check the database to see if there's a module that wants to hook in. A module could register to have it's action called before the hooked-into module's action (or after or instead of). Similarly the render() group of methods could look for menu items to add or substitute and for hooks (to call before, after or instead of).
c. You could pre-define certain events that modules could register for. E.g. admin menu, login, user profile ...

I haven't really looked into this so I don't really know what merit it has.

[OriginalCopy]

Hi Zeph

Zeph, on 28 March 2010 - 08:15 PM, said:

Just some thoughts.

1. Each time an event is raised, the directory structure would have to be traversed to see if there are any hooks.

Caching is on the TODO list

Zeph, on 28 March 2010 - 08:15 PM, said:

2. A module designer would have to raise a number of events to play well with other modules that would want to hook into it

Sure.

Zeph, on 28 March 2010 - 08:15 PM, said:

causing a search for a hook each time.

See (1).

Zeph, on 28 March 2010 - 08:15 PM, said:

3. For each hook we implement, we would have to be fairly familiar with the module it is hooking into.

Of course. Since you're attempting to hook your code into another place, you must know what you're doing.
The same goes for ordinary function calls in PHP: even if you don't care about how a function accomplishes its task, you still have to know what it does. In that regard, the basic principles of programming are not violated.

Zeph, on 28 March 2010 - 08:15 PM, said:

4. A module writer might anticipate the needs of other modules and not provide hooks in the right place.

4.1. "yii modules" is for programmers. You should be able to modify it at any time.
4.2. what is "the right place"? Only the author of a module can decide it.

Zeph, on 28 March 2010 - 08:15 PM, said:

a. Why not use a database? If we are dealing with extensible modules, we can assume that the web application is using a database.

Some sort of "hook providers" will be added on the TODO list. Thank you for your suggestion

Zeph, on 28 March 2010 - 08:15 PM, said:

b. Each module would derive from CExtensibleModule and CExtensibleController.

The LMS is not and will never be limited to modules and controllers. There will be those "hook providers" for convenient raising of events, similar to CController::actions().

Zeph, on 28 March 2010 - 08:15 PM, said:

These classes would check the database to see if there's a module that wants to hook in. A module could register to have it's action called before the hooked-into module's action (or after or instead of).

As I said, this feature will be on the TODO list (see the wiki page). However it will not be provided as a default. See the point "A hybrid for emerging technologies" in "Design Principles". Beside that, such a move will make "yii modules" be used in a "webmastering" manner, not in a programmatic manner. Yii modules is intended to be used only by programmers.

Zeph, on 28 March 2010 - 08:15 PM, said:

Similarly the render() group of methods could look for menu items to add or substitute and for hooks (to call before, after or instead of).

Sure. I said it on a couple of occasions, right now it is a prototype, many methods don't raise events as they should, etc.

Some of the points raised by you are already addressed by the wiki page of the project "design principles". You may want to have a read.

Thank you for the input.

[Onman]

I've created an application component to handle hooks.

It has some documentation inside the files, but here's a short manual:

in the code at the place where you'd want some code to hook in (called an "entry point"):
- Create a WEnvironment and set the desired variables.
- set the entry point: Yii::app()->hookManager->entryPoint('EntryPointName', $environment)

A hook function can be a php callback of the forms:
- CMyClass::staticMethod($environment);
- callbackFunc($environment);
- WMyHook (= a class which extends WHook);

A hook can be registered with:
- at runtime: Yii::app()->hookManager->registerHook($hook, $save); // set $save to true to save in the config file
// and never need to call this function again.
- in the config file at protected/config/hooks.php

see the code for details about this.
Just copy these to a place where they can be automatically loaded, like protected/components

Enjoy.

Attached File(s)

•  IHook.php (611bytes)
  Number of downloads: 21
•  WEnvironment.php (1.39K)
  Number of downloads: 21
•  WHook.php (1.08K)
  Number of downloads: 21
•  WHookManager.php (6.28K)
  Number of downloads: 19

[Mike]

EDIT: Moved over to the other thread...

This post has been edited by Mike: 30 March 2010 - 01:47 AM

[bettor]

Hi,

I've been monitoring your discussion here and been trying to understand it all. Are you attempting to design hooks like in Drupal to make all models interrelated and easy to integrate just with a download?

cheers,
bettor

[OriginalCopy]

Among others, yes.

[__agus]

Onman, on 29 March 2010 - 05:13 PM, said:

I've created an application component to handle hooks.

It has some documentation inside the files, but here's a short manual:

in the code at the place where you'd want some code to hook in (called an "entry point"):
- Create a WEnvironment and set the desired variables.
- set the entry point: Yii::app()->hookManager->entryPoint('EntryPointName', $environment)

A hook function can be a php callback of the forms:
- CMyClass::staticMethod($environment);
- callbackFunc($environment);
- WMyHook (= a class which extends WHook);

A hook can be registered with:
- at runtime: Yii::app()->hookManager->registerHook($hook, $save); // set $save to true to save in the config file
// and never need to call this function again.
- in the config file at protected/config/hooks.php

see the code for details about this.
Just copy these to a place where they can be automatically loaded, like protected/components

Enjoy.

very interesting. Is there any examples?.
thanks

[RKK]

Onman, on 29 March 2010 - 05:13 PM, said:

I've created an application component to handle hooks.

It has some documentation inside the files, but here's a short manual:

in the code at the place where you'd want some code to hook in (called an "entry point"):
- Create a WEnvironment and set the desired variables.
- set the entry point: Yii::app()->hookManager->entryPoint('EntryPointName', $environment)

A hook function can be a php callback of the forms:
- CMyClass::staticMethod($environment);
- callbackFunc($environment);
- WMyHook (= a class which extends WHook);

A hook can be registered with:
- at runtime: Yii::app()->hookManager->registerHook($hook, $save); // set $save to true to save in the config file
// and never need to call this function again.
- in the config file at protected/config/hooks.php

see the code for details about this.
Just copy these to a place where they can be automatically loaded, like protected/components

Enjoy.

really great idea

I was wondering how this "hook" thing works and now you have found it for me.
although I've spend some time exploring codes to discover it's mechanism but its just what I was looking for

I'll edit your files and if I have any working/easy thing, sure I'll share it with other people with mention of your work.