Communication providers>

This forum is only for questions or discussions about working with the mojoPortal source code in Visual Studio, obtaining the source code from the repository, developing custom features, etc. If your question is not along these lines this is not the right forum. Please try to post your question in the appropriate forum.

Please do not post questions about design, CSS, or skinning here. Use the Help With Skins Forum for those questions.

This forum is for discussing mojoPortal development

This forum is only for questions or discussions about working with the mojoPortal source code in Visual Studio, obtaining the source code from the repository, developing custom features, etc. If your question is not along these lines this is not the right forum. Please try to post your question in the appropriate forum.

You can monitor commits to the repository from this page. We also recommend developers to subscribe to email notifications in the developer forum as occasionally important things are announced.

Before posting questions here you might want to review the developer documentation.

Do not post questions about design, CSS, or skinning here. Use the Help With Skins Forum for those questions.
This thread is closed to new posts. You must sign in to post in the forums.
3/5/2009 3:21:21 PM
Gravatar
Total Posts 17

Communication providers?

IS there some kind of communication provider built into Mojo to handlle custom modules?

For example, if i create a couple new modules and want to put them on the same page, but don't want them to be so tightly coupled, is there some mechanism in Mojo that will facilitate the inter-module communication? I see that you have some providers for PageCreatedEvents and a couple others, but is there some generic provider that we can use? Or do we need to build that into our modules?

thanks!

david

3/6/2009 7:43:13 AM
Gravatar
Total Posts 18439

Re: Communication providers>

Hi David,

In mojoPortal, features aka modules are self contained, completely de-coupled, have no dependencies on other modules and they do not communicate with other feature instances on the page. They may leverage existing functionality in the core of mojoPortal but they do not leverage each other's functionality.

I don't know what you mean by communication providers. Perhaps if you explain in terms of what you are trying to accomplish I could help better.

Best,

Joe

3/6/2009 9:50:14 AM
Gravatar
Total Posts 17

Re: Communication providers>

hey joe,

we are interested in writing modules that may interact with each other, or can act independently.

i guess i was hoping that instead of needing to have moduleA know completely about moduleB, there was some kind of generic event handler (like your PageCreatedEventHandler or UserSignInHandler or UserRegisterdHandler) that we could use to keep our modules less tightly coupled ... though not sure how that would really look.

Scenario might look like this:

Module A publishes event to a generic eventHandler.

ModuleB susbscribes to that generic eventHandler.

When ModuleA fires event, ModuleB is notified of event (and then can choose if the event is something it needs to handle). 

Seems like it would be similar to the existing handlers that you have (like your PageCreatedEventHandler or UserSignInHandler or UserRegisterdHandler), so it was worth asking.

Now, the reason we were hoping you might have included this is because we are not all that sure that that can even happen, without some kind of coupling or reflection. Thought you might have developed a way of allowing inter-module communication.

thanks.

david

 

3/6/2009 11:15:12 AM
Gravatar
Total Posts 18439

Re: Communication providers>

Hi,

You are of course free to do what you like but my advice is make features self contained. Trying to setup communications across features in some loosely coupled way sounds like a complex solution whereas just implement what you need inside the feature is a simple architecture that is completely de-coupled. Its hard enough making sure a feature deals correctly with the page event lifecycle on its own, trying to inject some additional event coupling/handling across features is not something I want to work with and sounds like it would be complex/difficult to implement and prone to bugs and side effects. And I really can't think of any benefit that can be achieved by this that cannot also be achieved with less complexity.

My advice is a keep it simple and don't try to make different features that talk to each other. Again this is just my advice as the architect of mojoPortal and you are free to do what you choose. None of the existing features talk to each other and I don't plan to make them talk to each other.

Again if you were expressing the problem in terms of some functionlity or use case you are trying to accomplish I could offer architecture advice about how I would tackle the problem but you are discussing it so far in terms of architecture suppositions and proposals that you envision but are not the way things are done in mojoPortal. I cannot really think of a way that one feature can handle events from another feature without some coupling and knowledge of the objects and events exposed by the other feature. I mean if the event passes a reference to the object you have to know what kind of object it is in order to do anything useful with it. I mean it could be made generic by passing messages instead of objects but you still have to be able to understand the messages sent by an object so there is still coupling. Reflection is a no good because it can't work in Medium Trust.

Things that handle UserCreated event have to know about the SiteUser object in order to use it, things that handle PageCreated have to know about the PageSettings object and therefore these things are coupled, though it is somewhat loose because handlers can be added or removed by configuration. These are core object though not feature objects so its less ugly to have dependencies on them then to have dependencies across features.

Better to keep things self contained inside a feature and keep it simple in my opinion.

Best,

Joe

 

You must sign in to post in the forums. This thread is closed to new posts.