Over 10 years of community discussion and knowledge are maintained here as a read-only archive.
This was clearly a lot of work, and I can see how it is a tempting thing to do if you use Dojo. But the problem with writing ports that are dependent upon some other framework/toolkit, is that when the library you're basing your port upon changes, you have to play keep up. This happened when ExtJS 4 completely broke the old ExtJS 3 port. It left everyone dead in the water, unable to upgrade until someone had fixed the port. Over the years it's become clear that people don't always want to continue maintaining ports after they've completed them. This is why we decided to drop the dependent ports from official inclusion in the project.
define( "org/puremvc/js/multicore/core/Controller" //<-- I mean adding this line [ "dojo/_base/declare", "org/puremvc/js/multicore/core/View", "org/puremvc/js/multicore/patterns/observer/Observer" ], function(declare, View, Observer) {
I'm a little confused about where the barrier between puremvc.define() ends and where dojo.define begins. I would only want to use puremvc.define() for puremvc classes and then I would want to reference those within dojo-defined objects. Any tips on the ideal way to integrate the two?
And is there any desire to go native with Pipes?
define( [ "dojo/_base/declare", "org/puremvc/js/multicore/core/View", "org/puremvc/js/multicore/patterns/observer/Observer" ], function(declare, View, Observer) { var Controller =declare("org.puremvc.js.multicore.core.Controller",[ControllerSuperClass], { // <-- notice FQ name }); return Controller;});
define( [ "dojo/_base/declare", "custom/BaseClass" // <-- parent class which TestClass inherits from ], function(declare, BaseClass) { var TestClass = declare("custom.TestClass", BaseClass, { // <-- FQ name and parent class (null if no parent) membervar1: null, constructor: function(key) { console.log("custom.TestClass()"); membervar1 = ""; } }); TestClass.STATIC_CONST = "static_value_is_declared here"; return TestClass; });
define( [ "dojo/_base/declare", "custom/TestClass" <-- /* by specifying the TestClass (complete with path) here, it is certain to be loaded when the function below is run */ ], function(declare, TestClass) { var SomeOtherClass = declare("custom.SomeOtherClass", null, { constructor: function(key) { console.log("custom.SomeOtherClass()"); var myTestClass = new TestClass(); // here I use the param of 'TestClass' to ref the } }); return SomeOtherClass; });
define( [ "dojo/_base/declare", "custom/TestClass" ], function(declare) { <-- /*notice this time, I did not put TestClass in the args the creation function */ var SomeOtherClass = declare("custom.SomeOtherClass", null, { constructor: function(key) { console.log("custom.SomeOtherClass()"); var myTestClass = new custom.TestClass(); // since I declared its fully qualified name when I defined it, I can still reference it } }); return SomeOtherClass; });
I saw that you use a main.js file to define classpaths. Doesn't Dojo allows to declare classpath independently in each JavaScript file like Require.js does?Like this(example given with the Controller class):: define( "org/puremvc/js/multicore/core/Controller" //<-- I mean adding this line [ "dojo/_base/declare", "org/puremvc/js/multicore/core/View", "org/puremvc/js/multicore/patterns/observer/Observer" ], function(declare, View, Observer) { I found this way of doing things really neat, as it allows to use a simple concatenation/compression tool to create a single file for the whole PureMVC framework without having to be dependent on a specific tool. Are you using any compression tool (provided by the Dojo framework I suppose) that understands your syntax, or is this recommended by CommonJS?I will probably use your work in my current project to speed up the way I will integrate PureMVC into Backbone+Require with full AMD support.
Writing your PureMVC classes in the PureMVC define style and the view and service components in the Dojo style would certainly decouple the two and make the PureMVC parts reusable and self-consistent. Consider the possibility of using more than one toolkit, each with different ways of building view components. Do you decide to write the whole app in one or the other of those styles, or do you let the MVC part of the app be in a common style, and the view components and service components in their own styles. The latter approach will let someone familiar with Toolkit A or B easily write view components in those styles (and be aided by online examples in those styles), while the MVC part allows PureMVC developers not familiar with Toolkit A or B still be able to apply their skills immediately to the application. It's a good way to distribute responsibility around a team and make the codebase flexible to change at the boundaries.I'm not yet 100% certain what their concept of modules encompasses, but I'll look at it more. : TripleToe October 09, 2012, 09:28:47 And is there any desire to go native with Pipes? I was actually thinking about porting it recently, I just had a ton of other things going on. It would definitely be a good utility to have for the native port.