Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Show Posts

* | |

  Show Posts
Pages: [1]
1  Announcements and General Discussion / General Discussion / Re: Pipeworks Rewritten Using LICS instead of Pipes - 23% Less Code on: February 08, 2010, 11:42:03
I have now fixed the demo to deal with slow asynchronous loading of modules - silly errors. What is iteresting is how long the delay between and INIT event and the actual dispay of the module is - wierd, is that to do with the 2 frame nature of flex?
2  Announcements and General Discussion / General Discussion / Re: Pipeworks Rewritten Using LICS instead of Pipes - 23% Less Code on: February 07, 2010, 11:48:27
Thanks for your comments Cliff,

my site runs on a small server in my house - and earlier on I was playing online so maybe that interfered with you upload speed :-( I shall have to bear that in mind in the future.

WRT coupling I think the ideal is only to couple the message DTO's, message names and service interfaces. Anything else is too much.

The problems I had with Pipeworks is that the shell knows which modules will be loaded - the shall has a logger module mediator and a prattler logger mediator , and I found this strange. Maybe it is strange to me because I am aiming for a system where it is entirely unnecessary for the shell to know anything about the systems it loads up and how they wire themselves together, likewise for the modules, they should not be aware of their environment or other modules that are loaded.

I am about to start using LICS with an asynchronous server connection and I don't think I would provide that as a service. Instead it would be its own module with messages in and messages out. It would then be able to deal with its own state. You are right -services should not really be stateful or fragile to who is using them and in what order - luckily AVM2 is single threaded, but I can see in other implementations this would be a real issue.

I will try and fix my demo (if things load slowly) and look forward to imajn, do you have any ETA for when it could be appraised?

Conrad

3  Announcements and General Discussion / General Discussion / Pipeworks Rewritten Using LICS instead of Pipes - 23% Less Code on: February 07, 2010, 08:08:18
I want to start the topic with a very important statement.

I think PureMVC is excellent. In particular the multicore version has enabled me to do some really cool things, and do them quickly. The source code is clean and I think Cliff Hall is verging on the genius - so I want to be sure I don't want to offend anybody by what I am about to say:

IMHO Pipes and the Pipeworks demo are a bit of an overcomplicated mess. I have just spent the whole day converting the demo to use my LICS Framework, and have managed to get rid of 298 lines of code without even trying (mainly from junction mediators and all the code associated with them). Thats a full 23% reduction without losing functionality. I was also very surprised by the amount of coupling between the modules in the demo, something Cliff isn't normally guilty of :-) Int the LICSWorks demo I have reduced the coupling quite a lot.

The LICS framework is an implementation of an Enterprise System Bus (http://en.wikipedia.org/wiki/Enterprise_service_bus) using PureMVC. I think it works very well and is a far simpler approach to Multi Module applications than Pipes. It is outlined here.

http://www.dz015.com/?p=1

The main changes for the demo are

1) The junction mediators are sort of represented by the module Workers - but workers are much simpler.
2) LICS provides a service locator (http://en.wikipedia.org/wiki/Service_locator_pattern) for global service - I used this to provide a screen service for the components to attach to instead of them 'messaging' themselves to the shell. This is one of the strangest bits of the Pipeworks demo - I don't normally write apps like that, and so am not sure this was a good approach. The Service Locator in LICS is outlined here

http://www.dz015.com/?p=37

I have zipped up the project and attached it to this post.

I will hopefully have time at some point to improve it even more in the future.

Let me know what you think



4  Announcements and General Discussion / General Discussion / PureMVC Pipes Alternative - LICS on: January 28, 2010, 06:31:57
Hi all,

First off, sorry for the cross post, but based on the talk here this might actually be a better place to have posted it.

Based on the thread here

http://forums.puremvc.org/index.php?topic=1611.0

I have now released version 1.0.0 of my Lightweight Inter Core System extension for PureMVC. In my opinion it is a more lightweight and simpler alternative to Pipes.

Read all about it here

http://www.dz015.com/?p=1

Early next week I will be releasing version 1.1 that has a service framework included. Then it will probably be complete :D

Please let me have your comments, and I hope somebodyfinds it useful


Conrad
5  PureMVC Manifold / MultiCore Version / Introducing the LICS PureMVC exetension on: January 24, 2010, 10:43:21
Hi,

based on the thread here

http://forums.puremvc.org/index.php?topic=1611.0

I have now released version 1.0.0 of my Lightweight Inter Core System extension for PureMVC. In my opinion it is a more lightweight and simpler alternative to Pipes.

Read all about it here

http://www.dz015.com/?p=1

I hope somebodyfinds it useful


Conrad
6  PureMVC Manifold / MultiCore Version / Re: A New Approach to Inter-Core communication on: January 19, 2010, 02:43:22
OK,

I have update the system, and made it even more PureMVC like. There are no longer two types of facade - instead there is just a base SystemFacade. This does not have responsibilities for observer-notifier work, but instead delegates it to a Supervisor. The Supervisor is a bit like View, but it deals with IWorker's instead of IMediator's. IWorker's are registered with the supervisor by any facade/module that extends SystemFacade that wants to listen to system wide notifications.

The first facade to be created that extends SystemFacade creates the single static Supervisor - this would normally be the Shell.

The IWorker's are just like IMediator's - they have names and get registered with a notification system (the Supervisor). However their job is to listen to system wide notifications and translate them into notifications that mean something to the loaded module/core.

Reworking it this way has also made it easy to create a removeWorker method, however as I cannot override removeCore, I can not make this happen automatically when the core is unloaded - the call will have to be in the code of the core itself - however this is not too bad.

Please see the latest attached Shell.zip and let me know your thoughts on this new one :-)
7  PureMVC Manifold / MultiCore Version / Re: A New Approach to Inter-Core communication on: January 18, 2010, 11:54:40
Hi Cliff,

in my beta application I stated that

"In this time I have written one large modular application using it"

and I just wanted to be clear that what I meant was

"In this time I have written one large modular application using it, AND a whole host of non-modular and smaller ones"

:-)

Thanks

Conrad


8  PureMVC Manifold / MultiCore Version / Re: A New Approach to Inter-Core communication on: January 18, 2010, 11:49:23
Thanks Cliff,

I see your concern about adding the Observer notification system to objects registered with the supervising facade. I also particularly don't like the way in which a supervised facade finds the supervisor (and I wrote the thing :-))

However we have tried it in a small application and it was extremely easy to use, so being a pragmatist we are going with it for the moment.

I have signed up for the Imajn beta, and it sounds very interesting. Hope I get accepted.

Anyway I shall try to sort out the issues you mention and see if I can't make it a little neater.


Conrad
9  PureMVC Manifold / MultiCore Version / Re: Pipes, Fabrication - Excessive? on: January 18, 2010, 11:26:43
I've come up with a new appraoach that I would like if people had a look at - It's decoupled but doesn't need pipes etc...

Have a a look at

http://forums.puremvc.org/index.php?topic=1611.0

and see what you think.
10  PureMVC Manifold / MultiCore Version / A New Approach to Inter-Core communication on: January 18, 2010, 09:37:23
***** 19/01/2010: I have updated the shell, based on comments from Cliff, new shell is now attached, please read my new post for details of the changes - I think it is even cleaner and lighter now - original post is inaccurate now, but idea remains the same *****

Hi all,

I haven't posted here before, but I have been using PureMVC for well over a year now. I have delivered a lot of apps using the multicore version (large and small), and have used Pipes and Junctions on one big project.

My thoughts on Pipes and Junctions was that it was too complicated and not very PureMVC (sorry Cliff).

I tried to think of another way of doing decoupled module communication and have come up with a system that works at the facade level.

It uses the idea of 'Supervisor' and 'Supervised' facades (although a facade can be both).

A supervisor facade (of which there should be only one) is the router and uses exactly the same Observer pattern as the mediators in order to pass information.

Supervised facades have a 'listSystemNotificationInterests' and a 'handleSystemNotification' method analogous to the mediator methods with similar names.

Facade instances can then call the 'sendSystemNotification' method to send fire and forget inter module messages. There is also a SystemCommand that extends SimpleCommand and has a sendSystemNotification method.

To me this is more intuitive and PureMVC like.

I have attached to attached a project that explains this better (I hope).

The Shell app is the main one and at startup it load a logger swf (which is a puremvc core). The shell is a supervisor facade and the logger is a supervised facade. It is listening for SystemNotification.LOG messages from any other cores that load.

If you press the 'Load Module A' button, then a second module loads up that has a supervised facade. When it starts up it uses a SystemCommand to send a log notification out to the system. The logger catches this and displays the message.

What do people think of this - are there better ways to do what I have done? Is this a valid way to implement inter core communication?


Conrad
Pages: [1]