PureMVC Architects Lounge

Hi Cliff,

You mentioned a possible Native Javascript PureMVC port on LinkedIn -- just wanted to leave a bread-crumb here too (hope I'm not spilling any beans!).

I think a non-lib (mootools, prototype, et al) bound PureMVC would be perfect for us developers looking to avoid large, all encompassing MVC frameworks (for ex: JavascriptMVC).

I'm finding Agility.js (with jQuery and Less css) to be rather a slick way to handle the View part of the equation. I'm thinking that a Native Javascript PureMVC port might be a perfect fit with Agility for medium to larger sized apps. Can't wait!  ;)

Cheers,
-Chris

Hi Chris,

We actually had three Native Ports all submitted around the same time. We decided to combine them and take the best implementation of each method and try to put out a 'best possible' port. Much of that work has been done, I believe only documentation is outstanding at the moment. I've pinged the person who is in charge of bringing it all together. Hopefully this will be out very soon.

-=Cliff>

Thanks very much for the infos Cliff. Greatly looking forward to playing with it :)

Would be fantastic if there were three people (to start off with) involved in the core development. I did some googling and found two implementations, so curious as to who the third might be.

Cheers,
-Chris

I too am interested in a native port and was about to dig into the source in the svn link you provided in another post (http://svn.puremvc.org/PureMVC_JS/branches/native-multicore/ (http://svn.puremvc.org/PureMVC_JS/branches/native-multicore/)).  Mainly documentation left?  FWIW, I would be happy to help however I can in that area while I am digging.

Should be mainly documentation, but over the weekend, I heard from David about some changes that may need to happen yet. So close. The big problem is figuring out the idioms that should be used with it when using various other frameworks/toolkits like jQuery, mootools, etc.

-=Cliff>

Does David work on a way to remove code from constructors? I do not know that the Native JS repository was made public.

Cliff, the initialize (call it init or constructs or whatever we want) code convention I talk you about by e-mail and I used in my own Native framework I made last year and that I explained on my blog http://www.tekool.net/blog/2011/01/30/puremvc-native-javascript-port/ works well in conjunction with any UI/Class Framework. I used this Native PureMVC implementation successfully to build the EmployeeAdmin jQueryMobile demo I'm currently working on. It worked pretty well and could be considered as a good (not necessarily the right) solution. I can confirm that it would have also worked with any ExtJS/Prototype/Mootools frameworks. This said, I personally find any of those code convention painful to use.

Another solution I thought about to make this port a little more agnostic, would be not to use inheritance at all in the framework itself and let the developer implements its own inheritance system.

Extremely excited about the native javascript port. Looking forward to getting my hands on it.

Would also love to get my hands on it - happy to try and help with docs, testing, etc.  :)
-Chris

We are so close - RSADN ( Real Soon Any Day Now ). I'm checking out the release candidate tonight. We're sure it works because Tony DeFusco has already ported over the EmployeeAdmin and BoxSplash demos to use it (although we've shortened the namespace since then, so we'll have to revisit that briefly).

Hang in there, we're on our way!

Sounds great thanks for the update!

Have a look at http://trac.puremvc.org/PureMVC_JS/ now. You can download the native port and view the docs. We'll be trying to get the demos ported as soon as possible, and David did a first pass at the StateMachine utility tonight.

-=Cliff>

David did a first pass at the StateMachine utility tonight

Important for me to know, I also started a project on the State Machine : https://github.com/tekool/puremvc-javascript-objs-statemachine and recently have announced to make it my next work for PureMVC JS. Can David let us know which status his project has in the next weeks? My project would have been convertible in less than an hour from Objs to Native

Don't we preferrably need some human readable documentation for the PureMVC JS Native port?

I also started a project on the State Machine : https://github.com/tekool/puremvc-javascript-objs-statemachine and recently have announced to make it my next work for PureMVC JS.

Sorry, Frederic, David asked if anyone was working on it, but I did not realize that you were. I don't think it took him much longer than an hour or two for a first draft. I notice your port appears to use XML like the AS3 reference. I know David used JSON for describing the FSM, since only FireFox currently supports native XML via E4X.

Don't we preferrably need some human readable documentation for the PureMVC JS Native port

Absolutely. http://puremvc.org/pages/docs/JS/native-multicore/

Again, sorry for the crossed wires. I am hoping David may port the Pipes utility soon as well unless you have a port that could be converted to work with the native port.

-=Cliff>

Hi Cliff, no problem. I always try to let my ego beside my workspace. ;) But it will not benefits the PureMVC project if developers submit same things at the same time.

My thoughts were also to work with JSON instead of XML on the State Machine utility. I explained it by mail, forum or LinkedIN group recently I don't remember exactly. I wanted to make that and create the StopWatch demo before the end of the month.

To be honest I sincerely think there's plenty of things to do first before State Machine or Pipes in JavaScript. This is not so needed in JavaScript. I won't say we don't need it because I personally need them at work. This is why I started both jobs on my Github space. But I think it would be better to first have an human readable documentation for the Native port explaining "willing", "how to" and at least an "Hello World example".

Probably next what is the most requested is an AsyncCommand utility, it is so needed in JavaScript. Quite logical next the AsyncStub utility.

A lot of utility used to manage flash loading witll not be necessary with JavaScript (Loadup, Loadup as ordered) because CSS/HTML already have their loading paradigm and that we now have Require.js in JavaScript which seems to become near a standard for that.

If David want to do the PureMVC Pipes utility why not, just let me know I do not have started it officially. I just have explained why I need them and how I will conceived them. The only real need of this in JavaScript (as we don't have real modules support we have in Flash) would be to let communicate to different window context one to the other. This is a real pain to script (one could be loaded/unloaded before the other,etc) and here using Pipes would help a lot. Why not also studying a way to reuse BackBone modules. Those were my thoughts and my need at work.

Probably next what is the most requested is an AsyncCommand utility, it is so needed in JavaScript. Quite logical next the AsyncStub utility.

I created a working implementation of the native multi-core AsyncCommand Utility library for PureMVC JS -- I used it in the ExtJS v3 & v4 implementations of the EmployeeAdmin demo (to prep the Controller before the Model and View).  The maintainers of the native JS multi-core should rework my source to meet the standards/conventions used by the native multi-core PureMVC JS library (i.e. modify to use the preferred testing framework, JSDuck documentation, and any preferred JS coding styles and techniques).

You can download an archive of the source and sample library from here (http://www.mediafire.com/?gflm8hqrm8fan3g).

Excellent! Thank you Tony.

Just a remark, I saw that you are you using "Object.prototype.toString.call(this.onComplete)" instead of typeof this.onComplete == "function" ? Is this something related to ExtJS?

Hi Frederic:

Thanks for the code review.  I had originally ported this utility using ExtJS which had a function I was using called Ext.isFunction().  When I ported the utility to native JS multi-core and removed the ExtJS dependencies, I had to come up with a reliable cross-browser alternative to Ext.isFunction().  That bit of code

(myFnVar && Object.prototype.toString.call(myFnVar) === '[object Function]')

is what I came up with.  I found that Object's toString() function identified an object variable to be a function in the form of the string "[object Function]" consistently across browsers.

If the approach to determine if an object variable is a function using JavaScript's typeof operator works reliably & consistently across browsers, then I am all for going with that approach instead.

Cheers.
Tony

From what I know and have tested across browsers: typeof this.onComplete == "function" is safe. This said, with JavaScript who knows, there could be a better solution for this or someone to tell that something else is best to do. ;)

But I think it would be better to first have an human readable documentation for the Native port explaining "willing", "how to" and at least an "Hello World example".

Definitely more docs are in order (beyond the API docs).

The Hello World example is a thorny problem, because, as I understand it, everyone uses some UI framework or other.

For the Native port, I imagine that to be PureMVC, JavaScript, the DOM and nothing else. Something simple like taking user input from a field, then reversing it in a command, and displaying it in a label. Or maybe a calculator that uses transient Proxys to store values as you enter expressions. Basically something that gets all the major actors working at a task.

For illustrative purposes, that demo should be written both with pure JS for creating the classes, and also using the puremvc.define() method. That should show with little distraction the difference between rolling your own JS classes or using the PureMVC built ins.

Ideally, the next level would be to do that demo using Ext, and JQuery, but for components only. The PureMVC classes would be written with puremvc.define(). If this could be a single demo could be done with both JQuery and Ext components, it would be even better. We'd see a mediator for a JQuery component and one for a Ext component, in the same PureMVC app but not governing how the app itself is written, only the components and how the mediators communicate with the components.

Then the next level is the demo done with JQuery and all PureMVC classes are done in one demo with JQuery style, another with Objs, another with Ext, etc. This would show us how we can use PureMVC native without imposing any style on how you write your classes, but the actors and their roles are all the same.

-=Cliff>

Sounds like a great plan of attack Cliff.

Hey guys, apologies for my absence of late, I'll be more involved day to day moving forward. Just a quick note in relation to type checking with typeof and Object.prototype.toString.

Object.prototype.toString called on an instance of any Native class will return the name of that class in the form [object ClassName] where ClassName can be an instance of any Native JavaScript class (String, Boolean, Number, Function, Array, Object, Date, RegExp, Error(s)). In all other cases, it will return [object Object] (except for the case of host object in MSIE, which return [object]). One useful benefit is that while instanceof will fail for native instances referenced from another global scope (such as an iFrames global scope), calling the native Object.prototype.toString method on an instance of a Native object from another scope is consistent across all browsers.

All that said, generally, its preferable (and fully supported by all JavaScript interpreters) to use the 'function' === typeof object idiom that Frederic suggested, unless of course, like Ext's authors, you want to support the edge case of using a Function instance that was created in another global context. I'm not sure here is the right place to discuss the fine detail of JavaScript, but its naturally going to crop up... I'm wondering if we compile and point to a list of articles that we can defer these kind of questions to.

Any suggestions as to where we could house that or what we should link to? I just want to keep some kind of separation of concerns between JavaScript in the large and how to use PureMvc- maybe a dedicated thread focused on a few pertinent JavaScript gotchas that people may encounter when using the library?

Anyhow, here's an article comparing Object.prototype.toString to typeof : http://perfectionkills.com/instanceof-considered-harmful-or-how-to-write-a-robust-isarray/

David, can you confirm that I can continue my job on the PureMVC StateMachine?

Hey Frederic, let's coordinate offline. The forums shouldn't be used for project planning if you're ok with that? Ping you tomorrow, thanks.

I'm currently (I mean now) working on it. I need to know if I'm losing my time.

Em, you do know I ported two days ago, right? How about we work together? This isn't a one man show! Entirely up to you - what would really help out would be the devisement of some unit tests if your interested? But I will ask you once more to direct project planning related questions away from the forum of you don't mind? I would really appreciate keeping the topics focused on helping end users and discussing use cases and their resolution. Thanks a million.

I don't think project planning related questions must be get out the forums. Let's open a thread for this specific utility or kind of subjects if you want, but we can't e-mail the whole PureMVC community every time we want to talk about a project. Forums are specifically made for this in my opinion.

This said, I don't understand exactly what you mean, you already have finished to port the FSM? I just started with Unit Tests on my project. My plan was also to make a StopWatch demo when publishing the JavaScript utility. There also the multicore port of the utility to do.

What I don't understand is that I started 4 projects on my Github (http://my Github) that are planned for long :

• JQuery and Employee Admin (done)
• JQuery Mobile and Employee Admin (done)
• State Machine (current work)
• Pipes (even not started)

I told about it to Cliff and LinkedIN group last month, Cliff just told me yesterday that you are exactly planning State Machine and Pipes. I'm working with and for PureMVC community for five years now and we never had this problem before. I'm kind of sceptic on what happens there.

I told Cliff that I even not have started with Pipes utility so anybody willing to work on it is welcome. But I really don't want to work for nothing on the StateMachine. I participate for my own fun and the community benefit I don't want to have problems because of this.

David, Frederic,

I'm sorry, I must be at the source of these problems. David said he had a few hours to kill and was thinking of doing the StateMachine. I honestly do not remember Frederic saying he was planning to port the StateMachine and Pipes to work the Native port. I knew Frederic was working on things for the Objs port, but I did not know he had anything planned so far for Native.

So it was my bad. Please don't either of you take offense, I think everyone wants the same thing here, which is a proven set of useful tools for doing things.

I don't think it would be a bad idea for someone to post in the PureMVC JS / Demos and Utils board when they're thinking about porting something or doing a demo. That's where most people in the world who'll pitch in to help should logically look. And a public record of how and why things get done has thus far proven to be a good thing for the project.

Again, a complete failure to coordinate on my part, and I hope you'll both forgive me. I'd hate to have two very talented folks who really understand this stuff to have bad feelings because I dropped the ball.

-=Cliff>

Hi Frederic,

you're obviously very passionate about this, and there is an obvious lack of communication happening.

we can't e-mail the whole PureMVC community every time we want to talk about a project

That is precisely what I am trying to avoid by asking you to coordinate with me offline, not in the sense that you have to report to me, but in the sense that you are an active contributor to the project as am I, and at the very least we should be on the same page, and if not, take the time. I appreciate you are making plans, but if you make them in isolation, or simply assert them, surely you can understand that there are going to be crossed wires. Neither I, nor you, nor any other contributor, can put their interests on hold simply because another contributor has asserted that they are doing a certain thing. The spirit of open source software is combining effort to solve a particular problem for mutual benefit, and I'm sure you feel the same.

I have a lot of respect for any programmer taking the initiative, and especially you considering your contributions. I can genuinely understand your frustration, but please don't be skeptical. All I am asking, from a pragmatic perspective, is that we, and not just you and I, but any contributor, feel free to undertake anything they want to do, but just check in to make sure there is no redundant effort going on in terms of assembling a quality stack, and I say this against the bigger picture of open source software development, not just PureMvc.

Just to be clear, just because I completed the port (as in, I had a few hours spare the other evening and wanted to see how puremvc.define feels when used to implement a utility, but have yet to devise any comprehensive tests due to time constraints), doesn't mean I have an entitlement to 'own' the port space. None of us do! These are derivative works- the original authors deserve the kudos. Porting them is simply a pragmatic step, nothing else, at least as far as I see it. Thats my outlook, c'est fin. I hope you take the best from it, rather than the worst, and that we all can work together to get this stack right, to help us help ourselves get to the real fun stuff, which is using it to make killer apps.

Best

Dave

Guys, if that isn't irony, I don't know what is- posted that not realising Cliff had posted! Ai ai ai! :)