|
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
|
|
Pages: 1 ... 8 9 [10] 11
|
|
142
|
PureMVC Manifold / Port Authority / Command Registration questions
|
on: December 13, 2007, 10:04:20
|
Thomas asked: - What should happen when the same command is registered for the same notification string multiple times?
- What should happen when a new command is registered for an already used notifcation string?
When we do something like this:
Facade f = Facade.getInstance();
Facade.getInstance().registerCommand("init", InitCommand.class);
Facade.getInstance().registerCommand("init", InitCommand.class);
Facade.getInstance().registerCommand("init", InitCommand.class);
Facade.getInstance().registerCommand("init", DataCommand.class);
INotification n = new Notification("init", "whatever", null);
f.notifyObservers(n);
the execute method of DataCommand (and not InitCommand) is called four(!) times. Is this the behavior you want?
Currently, in the AS3 version, when the same Command is registered for the same notification string multiple times, in the Controller we store only one reference to the registration, the previous commandMap key is overwritten. However, we do register a new observer regardless of whether there was already a Command registered by that name: public function registerCommand( notificationName : String, commandClassRef : Class ) : void
{
commandMap[ notificationName ] = commandClassRef;
view.registerObserver( notificationName, new Observer( executeCommand, this ) );
}
This was based on the assumption that registration of commands will happen in one place and its easy to see if you've duplicated yourself. It hasn't been a problem, but it should be handled more like this: public function registerCommand( notificationName : String, commandClassRef : Class ) : void
{
if ( commandMap[ notificationName ] != null ) return;
commandMap[ notificationName ] = commandClassRef;
view.registerObserver( notificationName, new Observer( executeCommand, this ) );
}
Once a key is registered for a given notification, subsequent attempts to register a Command to that notification should be disregarded. -=Cliff> |
|
|
|
|
143
|
PureMVC Manifold / Port Authority / Mediator constructor
|
on: December 12, 2007, 02:04:54
|
Hey folks. First, have a look at this post: http://forums.puremvc.org/index.php?action=post;topic=147.0;num_replies=0You've probably noticed the asymmetry between the constructors of the Mediator and the Proxy. It's annoying, yes. Has it come up before? Yes. Have I dragged my feet on it? Yes. It's lamentable I didn't just change it early on. But now that we're about to present this framework to the rest of the world, lets polish it. The AS3 folks will get over having to do a refactor, but they'll privately rejoice that it'll be far better going forward. As I mention in the post, I'm going to get this 1.7 removeMediator fix out the door first, it requires no refactoring. Then, when I check the AS3 version into the public repository, it'll be refactored to org.puremvc.as3.*, and its Mediator constructor will take name followed by view component. Please go ahead and refactor your own code to do this. I expect the AS3 code to look like this: public static const NAME:String = 'Mediator';
/**
* Constructor.
*/
public function Mediator( mediatorName:String=null, viewComponent:Object=null ) {
this.mediatorName = (mediatorName != null)?mediatorName:NAME;
this.viewComponent = viewComponent;
}
...
// the proxy name
protected var mediatorName:String;
-=Cliff> |
|
|
|
|
144
|
PureMVC Manifold / Standard Version / Enums for Notification names?
|
on: December 12, 2007, 09:26:05
|
-----Original Message-----
From: Thomas Schuessler [mailto:Thomas.Schuessler@bwservices.de]
Sent: Tuesday, December 11, 2007 12:06 PM
To: cliff@puremvc.org
Subject: One more question...
Hi Cliff,
It is probably too late to make such a change and maybe I am a little paranoid, but what about using Enum-classes instead of strings to identify notifications? This would avoid the need to have naming conventions in larger projects.
br...tgs Thomas, I'm not completely against enums, as you can see in the Arch101 demo, I find a variation on it very useful for dealing with combo box population where we have an enumeration of possible settings: http://puremvc.org/pages/demos/arch101demo/srcview/source/org/puremvc/arch_101/unit_03/lab_02/model/enum/DeptEnum.as.htmlBut it seems to me that Enums are still a little involved for a core activity like notification constant naming. I think a lot of people would be put off by it. Of course middleware would help, but... However, this really falls into the area of idiom. You could do it either way. I would suggest doing demos that use both approaches. One that will be more understandable to people using other versions of PureMVC where constants are used, and another that shows using enums for those who prefer it. The advantage of enums over constants are that you get all the possible values in one spot, even ordered. But we don't really ever have a need for that in PureMVC. Nothing is ever passing over all possible Notification names. At least not now. If there were utilities for analyzing and interacting with arbitrary PureMVC apps, then it might be nice to expose the notificaiton names supported by the app to such a tool... -=Cliff> |
|
|
|
|
145
|
PureMVC Manifold / Port Authority / Remove Mediator Bug
|
on: December 08, 2007, 04:41:41
|
Hi Folks, View.removeMediator() is now responsible for what will be 3 Maintenance releases. Be very careful with your implementation. The current issue is that when removing the observers that hold references to a given mediator, each observer list is traversed and when a reference is found it the observer is removed from the list with Array.splice(). This causes all the observers from that point on to move back one in the array. Since we are in an iterator driven loop, the next time the iterator is advanced, it actually skips over the one its supposed to be examining, because it moved back by one during the last iteration. This will cause a release 1.7 of the AS3 reference implementation sometime within the next week. If you haven't seen it yet, have a look at this bug report: http://forums.puremvc.org/index.php?topic=145.0I'll be implementing the fix described as 'Copy the survivors' in my response there. You might want to have a look at implementing this in your ports. -=Cliff> |
|
|
|
|
146
|
PureMVC Manifold / Contributor Central / Contributing to the PureMVC Project
|
on: December 02, 2007, 03:23:02
|
|
Ports, Demos and Utilities
Initially implemented in ActionScript 3 (AS3), PureMVC is now being ported to a number of other languages that in turn will soon bring the framework to all the major client- and server-side platforms.
Each port is a realm unto itself. There are associated demo and utility projects, and each of those may rely on some related client and server technologies. For each project, be it a port, demo or utility, there is an associated Subversion (SVN) repository, and a Trac bug tracker/project Wiki.
Become A Project Owner!
If you have a PureMVC project idea or would like to begin work on a Port that does not yet have an owner, please speak up here! The public gets read access to all repositories, Project Owners get read/write to their project.
With ownership of a project comes the responsibility of documenting and maintaining it. Responding to the bugs and forum questions people will post. Evaluating patches that people submit that improve the project. In the end of course, it's all worthwhile when you realize how many people will be using your code to solve problems, that's why open source is so successful. But the key for that to actually happen is not only for you to write the code, but to document it as well. Internally and in the Project Wiki. We're not talking about a Steven King novel here, but enough so that people can easily take what you've done and make good stuff happen with it.
In addition to write access to SVN and Trac for their project, Project Owners get a puremvc.org email address. It can be forwarded to any email address you wish, but within the source code and files on the system, Project Owners should use their puremvc.org email address. There is a good reason for this. Email addresses come and go. But PureMVC.org will continue to be the source for PureMVC framework, demos and utilities. If a Project Owner changes his or her email address, no big deal, we can forward it elsewere. But people who have downloaded code and are sitting around at 2:30 in the morning trying to figure out how something works will always be able to mail to that email address and get through to you. Even if you hand the project off to someone else, we can redirect it within PureMVC.org to the new owner, as well as amending code with that owner's address going forward.
Be A Regular Contributor!
If you just want to contribute to an existing project, making some improvement or fixing a bug, but don't want to 'own' a project per se, you'll want to see a separate post (to be made) in this forum about creating a subversion patch.
Essentially, You check the code out, make your changes, create a patch, and mail it to the Project Owner, who may or may not choose to commit it to the project.
Source Code Packaging
To maintain order in the global package namespace, please package your demo and utility code like this:
org.puremvc.XXX.[demos|utilities].YYY.ZZZ.mydemospurpose.*
where
XXX = the PureMVC port. One of: (as2, as3, as3.multicore, cf, csharp, haxe, haxe.multicore, java, perl, php, python, ruby)
YYY (only optional if not applicable) = any related client technology being used (flex, flash, air, etc...)
ZZZ (only optional if not applicable) = any related server technology being used (cf, weborb, lcds, etc...)
Examples
An AIR application using the AS3 port of PureMVC to talk to WebORB to do a messaging example would be built in a package structure that starts with something like:
org.puremvc.as3.demos.air.weborb.messaging.*
A simple flash example that shows how to do drag and drop might look like:
org.puremvc.as3.demos.flash.dragdrop.*
A FlashLite cellphone game using the AS2 port might look like:
org.puremvc.as2.demos.flashlite.mycoolgame.*
A set of Java Aspect oriented-programing (AOP) utilities for the J2EE platform might look like:
org.puremvc.java.j2ee.utilities.aop.*
Source Code License and Attribution
We want everyone to get credit for their hard work. We also want users of the framework and demos to be able quickly identify, the project purpose, the author and how to contact them, and the license governing their use. This is an open source project, and so the key is that the source code be reusable by others for their own purposes. However a person writing a demo or utility might want to reserve the right to publish a book or article including all or part of the work.
In order that this be made clear within the context of every source code file, please place a header at the top each in one of the following formats:
For XML based source files:
<!--
PureMVC Flex/CF Demo File Uploader
Copyright (c) 2007 Simon Bailey <simon.bailey@puremvc.org>
Your reuse is governed by the Creative Commons Attribution 3.0 License
-->
Inside class files:[/b]
/*
PureMVC Flex/CF Demo File Uploader
Copyright (c) 2007 Simon Bailey <simon.bailey@puremvc.org>
Your reuse is governed by the Creative Commons Attribution 3.0 License
*/
There's much more to come, this is only the start. I hope everyone can get an idea of the direction this thing is going. We want a very orderly expansion of the codebase to cover many languages and adjacent technologies.
Currently, I am contacting various community members who have contributed in the forums and whose work could most benefit others understanding and use of PureMVC.
In the meantime, if you would like to create a project please speak up in this forum!
-=Cliff>
|
|
|
|
|
|
|
