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] 2
1  PureMVC Manifold / Bug Report / [WILL ADD] Suggestion for next version on: August 27, 2008, 02:24:20
Just a (very small) suggestion for the next big release of PureMVC:
It'd be very handy if the Facade's registerMediator and registerProxy methods would return the instance of the mediator/proxy which gets registered.
That way you can write this:
mediator = facade.registerMediator( new SomeMediator( someView ) )instead of:
mediator = new SomeMediator( someView );
facade.registerMediator( mediator )

I know, it's a silly and small thing, but everything which speeds up coding is welcome ;)
2  Announcements and General Discussion / Public Demos, Tools and Applications / Re: User Manager Demo (Puremvc + weborb + php + mysql) on: August 25, 2008, 01:03:04
Thanks for the excellent demo. There's just one thing though, I think it would be better to handle the loginpanel through a separate mediator instead of the ApplicationMediator...

Great job!!
3  Announcements and General Discussion / General Discussion / Re: normalizing remoteObjects on: July 09, 2008, 12:24:57
I've used two possible solutions for this situation (I have no idea whether these are the best solutions, though...)
1. Create a mediator for each itemrenderer and let the mediator communicate with the authors proxy to look up the author name, using the author id
2. let the item renderer send a dataChange event to the view's mediator, which in turn does the same as in 1.

Whether I choose 1 or 2 depends on the complexity of the itemrenderer. If it needs to get data from various proxies and performs all kinds of difficult logic, I'll choose 1. It's a more convoluted solution since you'll need to create the extra mediator-class and most probably a factory class as well.
4  Announcements and General Discussion / Architecture / Re: Appropriate use of MXML WebService on: July 08, 2008, 08:18:16
Probably I'm overlooking something very basic here, but why not create a proxy (not a pureMVC proxy, in this case) for the webservice that calls CursorManager.setBusyCursor() and CursorManager.removeBusyCursor() when the service is respectively called and finishes its call?
5  Announcements and General Discussion / General Discussion / Re: The confusion about Notfication on: July 07, 2008, 01:30:03
Q1: if you turn it into a singleton, you can only send one notification at a time. Which would be a serious downgrade.

Q2: this.getNotifyMethod().apply(this.getNotifyContext(),[notification]);
apply the result of getNotifyMethod (that result is a function) to the result of the getNotifyContext and pass the retrieved function the value of "notification" (the apply method takes an array of possible arguments, therefore notification is enclosed within [])

It provides a way for a class to define what method should be invoked when a notification is received.

For instance in Controller.registerCommand there's the line (#136)
view.registerObserver( notificationName, new Observer( executeCommand, this ) );

Controller passes it's own "executeCommand" method to the Observer constructor ( that method is stored in the "notify" property of the Observer class) So, whenever the getNotifyMethod of that Observer instance is called it will return the "executeCommand" method of Controller.
As a second parameter it passes "this" (which is the instance of the Controller class) which gets stored inside the Observer instance in the "notifyContext" property. So, whenever the getNotifyContext is called it will return the controller instance.

Whenever the notifyObserver method of an Observer instance (used in the Controller class) is called it will run the "executeCommand" method on the controller instance. (This, obviously, only applies to all Observer instances used in the Controller class, Observer instances in other classes will return other methods and other contexts)
6  Announcements and General Discussion / Architecture / Re: MEDIATOR MADNESS - sale on now!!! do they really have to go? on: July 02, 2008, 07:47:27
When navigating from one page to another clean up the mediators you don't need anymore. Which is best practice BTW.
So yes, in this case, being lazy is bad.
7  Announcements and General Discussion / General Discussion / Re: PureMVC & State Managment (aka Slide) on: June 25, 2008, 07:25:45
Just to let you guys know the swfObject template works like a charm. Very easy-to-use.
8  Announcements and General Discussion / Architecture / Re: Trouble with view components - mad stuck on: June 16, 2008, 04:23:43
Sounds like you have the right reasons to have the image mediators, so I wouldn't drop that. My guess would be that the problem lies in how the mediators are instantiated. What way do you differentiate between the instances? Do you have a factory class, which keeps track of the various instances or ... ?
9  Announcements and General Discussion / Getting Started / Re: deferred mediator registration on: May 21, 2008, 12:19:01
Ah, yes, should've mentioned it can only be used in Flex.
10  Announcements and General Discussion / General Discussion / Re: Command confusion on: May 21, 2008, 12:14:49
Thanks a bundle for the response, it's much more clear now!
11  Announcements and General Discussion / Getting Started / deferred mediator registration on: May 20, 2008, 05:37:59
I don't know if anybody'll have any use for this, but I wrote a small function which defers the registration of the mediator until the view component it mediates is created.
(I hope it doesn't sin against the best practices ??)

Place this in ApplicationFacade:
public function deferMediatorRegistration( mediatorClass : Class, viewComponent : UIComponent ) : void{
var facade : ApplicationFacade = this;
var listener : Function = function( event : FlexEvent ) : void {
facade.registerMediator( new mediatorClass( event.target ) );
viewComponent.addEventListener( FlexEvent.CREATION_COMPLETE, listener );
to use it (in, for instance, ApplicationMediator )
ApplicationFacade.getInstance().deferMediatorCreation( MyCustomMediator, app.myCustomComponent );
12  Announcements and General Discussion / General Discussion / Re: Command confusion on: May 20, 2008, 12:46:29
Thanks for the swift reply and action. Cliff, you really are one of the major advantages of this framework :)
I hadn't realized that some of the tutorials didn't follow best practices entirely (are there others?)
Just one more thing: in the best practices document you write:
Commands house the business logic of our application
(p. 18) and a few lines further:
The Model maintains its integrity through the use of Proxies, which house domain logic and [...]
When I look up "business logic" and "domain logic" at wikipedia both phrases lead me to the same article. Could you explain the difference to me? Or point me to a site which does?
I'm sorry for such noobish questions!
13  Announcements and General Discussion / Public Demos, Tools and Applications / Re: Tutorial: Getting Started with the PureMVC Startup Manager on: May 19, 2008, 03:35:51
Excellent tutorial, thanks a lot!
14  Announcements and General Discussion / General Discussion / Command confusion on: May 19, 2008, 01:01:08
I'm a bit confused about the responsibilities (and use) of commands. When I look at the provided examples I notice there are examples where all remote access is done through commands ( for instance there are commands for all CRUD operations in the Bookstore example)
But then in another example (IndexCards) all remote access is done through the proxies.
I'm not sure which approach I need to take.
I'm working on an application with around 20 tables and approximately the same amount of views. If I cut up all CRUD operations to separate commands this'll give me 60+ commands. That seems WAY overkill. But on the other hand if I go for the proxy-approach, I'll only have 3 (Startup, ModelPrep and ViewPrep) and suddenly commands seem completely useless to me.
So, when should I decide to put something into a command and when can I leave it to the proxy?
(I read the chapter on commands in the "best practices" document, but I must confess that I'm not familiar with most of the expressions like 'domain logic' etc. Looking them up at Wikipedia didn't make me any wiser, on the contrary)
15  Announcements and General Discussion / Architecture / Re: Cache frequently used assets... on: May 13, 2008, 12:45:49
You've got a point there.
But when it's not shown in a browser all external assets are still placed in a temp directory, so the same principle applies. (If I remember correctly the cache won't be re-used in a new session though, which is a difference with the browser's cache)
Pages: [1] 2