Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Welcome, Guest. Please login or register.
March 26, 2017, 12:13:28 AM
Home Help Search Login Register
News: ATTENTION: Spambots must die! Humans must visit http://contact.futurescale.com to request forum access.
  Show Posts
Pages: [1] 2 3 ... 12
1  PureMVC Manifold / Standard Version / Re: ICommand not applicable for arguments in registerCommand on: November 19, 2012, 03:32:34 PM
I believe that the standard version (which has had quite a tumultuous history, to say the least) was last re-implemented by a team who was focused on GWT, and one problem (as I understand it) was that you couldn't pass a class reference. Perhaps GWT doesn't (or didn't) have reflection support, I'm not sure.

You're right! I remember the whole history now. I was quite surprised of this.

could you look at whether GWT can pass class references around?

I don't think I will have time before a while for that. I already have too many things on the grill to finish before. I even tried to recruit someone interested in PureMVC Java recently:https://github.com/ndeverge. Nicolas kindly made a pull request to add Maven support to the Java standard port I was hosting on my own Github for the work on converting it from multicore. Now that even PureMVC is on Github I will push it back to PureMVC Github. I may ask him again if he is interested in this problem.
2  PureMVC Manifold / Standard Version / Re: ICommand not applicable for arguments in registerCommand on: November 19, 2012, 12:31:52 PM
The update from «Class commandClassRef» to «ICommand command» has been made when upgrading the PureMVC standard Java framework from PuremVC Java multicore framework.

I'm not too much on Java development, but I did the upgrade myself to help the community because we had many silmutaneous problems with the standard framework. I near have copied the multicore framework and converted it back to standard. To be honnest I don't remember that it required to use an ICommand instead of a class reference. It would be better to use a class reference here if we really can without unknown side effect.

For your exact problem, this is normal that the compiler throw an error here as the type on the object you pass as an argument is not an ICommand but really a Class object.
3  PureMVC Manifold / Multicore Version / Re: Give us feedback on the native port's simple 'class inheritance' facility on: November 10, 2012, 03:47:47 PM
Quote
And another issue is that the current documentation tool (jsduck) can't follow the PureMVC define() hierarchy

I can't help you on this, I worked with JSDoc by the past, I also had many problem with it too and I've never worked with jsDuck. Tomorrow I've planned to start the work on PureMVC JavaScript standard framework. I also has to create help using jsDuck I hope I won't have any problem with it either.

Next to this work, I'll have a look into the full super implementation with PureMVC define().
4  Announcements and General Discussion / Public Demos, Tools and Applications / PureMVC framework for TypeScript on: November 08, 2012, 04:17:55 PM
I just published a blog post announcing the brand new PureMVC for TypeScript framework http://www.tekool.net/blog/2012/11/07/puremvc-for-typescript/

I hope soon on PureMVC as new supported language. Wink
5  PureMVC Manifold / Multicore Version / Re: Give us feedback on the native port's simple 'class inheritance' facility on: November 04, 2012, 03:02:01 PM
Quote
Also, there is a PureMVC Dart port. Dart has proper inheritance and typing.

Yep but tell me if I'm wrong, Dart's compiling to JavaScript is not really intended to be executed on the web. What is the status of Dart to JavaScript compiling? It seems to have been critized a lot by the past.

Quote
I checked out John Resig's solution, which seems proper. I don't know what it would take to adapt it to the oop.js class, but its worth looking into.

I can have a look into porting the John Resig solution into PureMVC. I have studied those kind of solution when working on Objs. Objs uses a system pretty near than the one from the John Resig solution (my solution is quite older than his, I'm kind of proud of it). In 2008 and before, it has one main caveat, it absolutely needs JavaScript to support the constructor keyword. Some old browsers doesn't support it (it even can cause serious issues with some Safari versions). But to be honnest today no one care, even TypeScript output an extend method that make use of constructor (I checked and PureMVC define even already use it).

From what I remember the idea of John Resig also can cause some issue with an inheritance chain where :

1) The SuperClass define a method.
2) The first subclass doesn't define this method.
3) The third subclass define this method and makes use of the super method.

From what I remember the call to super will not work where it has to, it has to be verified.

You may say...no one care, but the first implementation of this solution may break within PureMVC with the Notifier sendNotification method in any Mediator/Proxy/Command subclass.

If this is really something that may interest people I could work on it, I like those problematic a lot. Wink

As I told you recently I will work on the JavaScript port to transform the Employee Admin demo from Objs to define(). This could be a good occasion to try it so.

It may be a good idea to also port the standard version? What it is the status of this too?


6  PureMVC Manifold / Multicore Version / Re: Give us feedback on the native port's simple 'class inheritance' facility on: November 03, 2012, 04:51:57 PM
If you really can't refrain you to use Prototype.js $super(),  better to rewrite the PureMVC JavaScript code itself, I've made a PureMVC port to Prototype.js (with 1.6.1 syntax but it has to work with 1.7.1 or make me a pull request) : http://www.tekool.net/blog/2011/01/19/puremvc-port-to-prototype-javascript-framework/

Another solution is to use TypeScript/Haxe to write JavaScript. I'm working on the TypeScript port of PureMVC, it finally allows us to write JavaScript code using simple and static typed syntax like super(). It still need some polish but it works like a charm.

I don't know for David who is responsible of the project, but in my opinion we better have to keep the prototype chain syntax to stay easily portable with more frameworks and languages.
7  Announcements and General Discussion / Architecture / Re: JavaScript HTML5 Game on: November 03, 2012, 03:56:56 PM
Glad you're close to get your project working.

One solution I came up with was providing a way for each module to define the proxies it wants a reference to from the shell. When the shell creates the module, it can pass these proxies to the module. I could then treat these proxies almost as an external API that I could access from each module, perhaps having a proxy to abstract them from the module. I kinda feel like this type of a solution causes to much interdependence between a module and the shell. Any thoughts?

You're right, sharing a proxy reference between modules is not the good approach. But sharing data as you thought in the second part of your paragraph may be the right.

Your idea of asking via a notification a Proxy to send some data is the perfect one. To be sure to think modules and pipes communication the right way, just think modules as threads. If you share some data, this can be blocking, if you retrieve data synchronously it can be blocking, etc… If we where in a multi-threaded environment this would be the solution of choice. It's really natural to think this way…but as you supposed, requiring data of a Proxy, wait for it to send it to another one (even if it's hidden synchronous process in your game for the moment) can be quite long to write and somewhat quite long to process in a game environment that need speed.

A good intermediary solution to have something neat and at minimum cost is simply to use a common proxy class that each module will instantiate in its own environment (not the same instance shared). What you will share will be the reference to your data resource. Here in HTML 5 SQLite would be perfect, as it is thread safe (if I remember well). Then when some data is updated, the data module sends a notification to interested modules, interested modules so read the data. You can also use LocalStorage or even a simple reference to the same object in memory but you have to be careful with this solution, only the data module should have right to write to it. There's some smart things to do be sure to give write access only to the module that instantiate data first.

8  Announcements and General Discussion / Architecture / Re: Does anyone use a LayoutManager ? on: November 03, 2012, 05:17:34 AM
You don't want mediators and commands full of code that micromanage the view because that makes it harder to change the view without changing tons of application code.

View logic must stay in the view at it maximum indeed, I wasn't clear enough on that point. I like this idea to talk about «micro-management» this well explain where the responsibility of a Mediator should stop regarding view components.

Quote
1. A stageView or applicationView class (might not even need to extend sprite) which instantiates all the main screen components.
2. stageView is passed the stage in its constructor and adds all components to the stage.
3. stageView maintains references to all the components and takes full responsibility for adding/removing them from the stage and managing their layout.
4. stageView exposes references to some or all of the components so that mediators can be added to lower-level parts of the view.
5. stageView can respond directly to stage events (eg stage resize event) but also has a stageMediator which provides the connection to model and controller tiers.
6. PrepareViewCommand instantiates the stageView component (passing the stage to its constructor) and the stageMediator, and all the other mediators (passing the exposed child objects of the stageView to their constructors).

Steps 1 to 3 will depend a lot on the design of your application, but what you expose here looks like what a lot of other AS3 PureMVC apps do. Steps 4 to 6 seems perfect to me too except the «instantiates the stageView component». In most designs the stageview is already instantiated there because we talk about the main view component of the application which also host the responsibility to initiate PureMVC itself.



9  Announcements and General Discussion / Architecture / Re: Does anyone use a LayoutManager ? on: November 01, 2012, 08:51:33 AM
All of your choices seems the right ones to me! Wink

Quote
I imagine creating a Command for each layout configuration which performs similar to above but using different size/position calculations.

Here starts the real application work, outside any architecture considerations. Just try to make your command reusable and maximize the use of Mediators methods for every operations that make view components specific operations like moves etc. that have no sense to make reusable in commands.

And sorry if I seem a little harsh in my answers, it's just that I'm really direct because English is not my native language.
10  Announcements and General Discussion / Architecture / Re: Does anyone use a LayoutManager ? on: November 01, 2012, 07:01:29 AM
Quote
this approach still has a problem that there is no central "manager" that holds any references to these components.

Quote
which is difficult when the command needs to refer to a list of view components that spans the entire stage, and it is born with no immediate access to any of them.

Both those problems has the same answer : command can decide what one or the other view component must do through mediators. This isn't a problem for a command to directly access the mediator reference and uses mediator methods designed to interact with one or a group of view components. This is always better to use integrated mediator notification support, but when the logic is reusable, complex, it is still better to use external commands that directly drive some important mediator behaviors.

So you have to maintain references into one or several mediator, even if each of those mediator only have reference to one or several MovieClip holding references to many other child MovieClip in it. As you say this is a problem of granularity. This is here only your choice, but having a look at demos on PureMVC Github you will have a good idea of what is acceptable and what isn't.

Quote
I'm not sure I agree with this. A view component can be responsible for its own contents, but it needn't/shouldn't be aware of anything outside of itself, such as where it is positioned on the screen.

You certainly misunderstood me. Re-read what I say. I told that the UI has to dispatch an event telling the Mediator that an element has been clicked or that it has been deployed. The mediator decide what to do here, the UI never know any lower level application component here.
11  Announcements and General Discussion / Architecture / Re: Does anyone use a LayoutManager ? on: October 31, 2012, 04:44:34 PM
Quote
I originally designed my application in this way, but then decided that the entire view creation should be separated out into a PrepareViewCommand.

Keep this design, this is the right one. It is always better to initialize view components and their mediators (even if you initialize only one mediator for several view components) in a command. This the PureMVC way to manage dependency injection, using Mediator constructors.


Quote
It sounds like you are saying that the application needs some kind of StageMediator.

No, a StageMediator to directly manage view components is not the best idea. It would be better to have a dedicated Mediator for your group of MovieClips. One or several Mediator which name indicate what it does. When your app will evolve, a StageMediator can't be reused easily as it lays to the Stage only.

Quote
This seems like a lot of logic to place inside a mediator which is, I thought, only supposed to catch events from the view and pass them back.

When I say that a mediator can manage more than one view component I of course don't mean to place the whole app logic into one mediator. A single mediator only have to manage a group of view components having their own logic. But avoid to manage UI that do not share any logic into the same mediator.


Quote
Decisions along the lines of "user has moved the mouse, so slide on the tools palette

This typically has to be managed by your view component itself, not even the mediator. The mediator will only receive the event saying that the user as clicked on some of the tools of the palette. At least, it can receive an event telling to refresh the layout when deployed for any reason (what can be one of the answer you search for your LayoutManager question) then the mediator sends the appropriate refresh Notification to all other mediators. This sort of things happens often and is the right way of handling UI events to re-dispatch them to others UI component.
12  Announcements and General Discussion / Architecture / Re: Does anyone use a LayoutManager ? on: October 31, 2012, 01:58:35 PM
Hello Benissimo,

You definitely don't need a ViewProxy. What you are looking for is simply the Mediator pattern itself. Have a look at its definition «The mediator pattern defines an object that encapsulates how a set of objects interact.»

I mean, PureMVC already offers the solution to your problem. When you have a set of view that can interact or can be grouped by any selection criteria, you must use a single mediator to manage them. You don't need to create one mediator for each «not so complicated» view component. Just be careful not to use a single mediator for too much view components that make no sense to group or at the contrary use a single mediator for let say, only a simple animated movie clip dispatching no event.

Something I made by the past and must be avoided as much as possible is to use a mediator to manage other mediators. It is best to use only commands and notifications in this case. There is always a solution to refactor the application not to have some kind of mega-octopus-mediator.
13  Announcements and General Discussion / Architecture / Re: JavaScript HTML5 Game on: October 31, 2012, 01:27:57 AM
Bill White made recently a port to JavaScript of a demo for PureMVC Pipes I made for Flex a long time ago : http://www.billdwhite.com/wordpress/?p=450

Thanks to him, you will have a good entry point to start with Pipes in JavaScript compared to Flash.
14  PureMVC Manifold / MultiCore Version / Re: PureMVC-Improvements: Array to Dictonary or Vector ? on: October 30, 2012, 02:10:58 PM
I think we already dicussed that on an another thread.

If I remember well, here, the problem is that we don't use any array methods. In fact it has to be re-typed to Object if Dictionnary isn't possible. I had too, in other ports I made, TypeScript included.
15  PureMVC Manifold / Demos and Utils / Re: Dojo AMD Implementation of PureMVC and Pipes on: October 10, 2012, 11:46:36 AM
Indeed, you are right you're forced to use a main.js to order loading of each file. In fact my builds always use an XML file with Ant that order things for me before concate and compress them. I just forgotten that.

I'm using Backbone but with AMD too. If I need to use another compression solution that the one I use I will probably use near the same as yours, but using Require and its order plugin (I heard it is now included in Require directly).

Thanks for those infos.
Pages: [1] 2 3 ... 12