topleft topright

Welcome, Guest. Please login or register.
May 22, 2013, 11:25:44 PM
Home Help Search Login Register
News: ATTENTION: Spambots must die! Humans must visit http://contact.futurescale.com to request forum access.

Pages: 1 2 [3] 4 5 ... 10
 21 
 on: February 15, 2013, 01:44:56 AM 
Started by openoli - Last post by openoli
Hi Cliff,
sorry for the confusing question, maybe I'm confused by myself Wink
I should think about my formulations before posting.
Seems that I've not understand the pipes concept completely.

Of course I don't want to separate every function to a core of its own.

The question was regarding the arrangement of modules and if it's a appropriate way to place 'submodules'
inside a 'mainmodule' and if all these modules could talk to each other without involving the shell.
Perhaps the differentiation in 'main-/submodules' is completely rubbish, I should think about it!

But sometimes I tend to think too much about whether the things the 'right' are.
Instead of thinking and asking too much I should just implement my ideas to see if it works and dispel doubts ;-)

Quote
You certainly can plumb cores together without them having to be plumbed to the shell. Have a look at this slide in the MultiCore Overview Presentation:
http://puremvc.tv/#P002/T235
Yes, that's it... don't know why I don't registered this slide before.

Now I'll try to install my pipes to get the cores connected;-)

Thanks for help!
Olaf

 22 
 on: February 14, 2013, 08:12:52 AM 
Started by openoli - Last post by puremvc
Quote
Imagine we'd like to extend the the PrattlerModule (from the PipeWorks demo) with more features.
For instance there is a navigation tree with some items that offers some more complex functions (in prattler context).
To be encapsulated we would like to build an own core for each function.
So here a function is something like a 'submodule' but of course each submodule should be independent and self-contained.

How we could solve this by using pipes?


I'm not fully sure I understand the question. Yes, you could extend a module and extend the classes used in that module. That's not pipes, that's just normal OOP. I don't fully understand each 'function' being a core, though. A core usually provides a number of related functions. You could separate every function to a core of its own, but that would mean an untenable amount of coding overhead for each function. You have to ask yourself why you're doing the separation and what the real, tangible benefit of that separation is first.

Quote
Would it basically a good idea that some cores are connected directly with each other without involving the shell?

You certainly can plumb cores together without them having to be plumbed to the shell. Have a look at this slide in the MultiCore Overview Presentation:
http://puremvc.tv/#P002/T235

-=Cliff>



 23 
 on: February 14, 2013, 02:54:24 AM 
Started by openoli - Last post by openoli
Hi,
after switching to Multicore and adding the PipesUtility by implementing the ideas of the PipeWorks demo
there remain some questions regarding 'submodules'.
I've read a lot in this forum regarding this issue but at least I don't understand it.

Imagine we'd like to extend the the PrattlerModule (from the PipeWorks demo) with more features.
For instance there is a navigation tree with some items that offers some more complex functions (in prattler context).
To be encapsulated we would like to build an own core for each function.
So here a function is something like a 'submodule' but of course each submodule should be independent and self-contained.

How we could solve this by using pipes?

Is this a appropriate way:
A PrattlerSkeletonModule implements the 'main' module frame including the navigation.
A PrattlerModuleX implements the current PrattlerModule features as 'submodule'.
A PrattlerModuleY implements new Prattler feature(s) as 'submodule'.
A PrattlerModuleZ implements more new Prattler feature(s) as 'submodule'.
...

By requesting the Prattler from the shell, the PrattlerSkeletonModule is delivered.
After this the PrattlerSkeletonModule request the default module, e.g. PrattlerModuleX from the shell and displays it.
By clickling a navigation item inside the PrattlerSkeletonModule the suitable module is requested by the PrattlerSkeletonModule and the shell will deliver this to the PrattlerSkeletonModule to display it.
(Or should the PrattlerSkeletonModule deliver the requested module directly, without involving the shell? )
Each Module(core in this case) is connected by own pipes from the shell to itself and vice versa.

Would it basically a good idea that some cores are connected directly with each other without involving the shell?

Thanks for help!

Olaf


 

 24 
 on: February 11, 2013, 01:41:06 AM 
Started by openoli - Last post by openoli
I've got it Cliff, thanks!

In the meantime I've moved my application to multicore by doing all the necessary stuff.
That was a little work but pretty easy:-)

Now I'll try to understand the PipesUtility... perhaps there will be some questions soon;-)
   

 25 
 on: February 08, 2013, 08:29:36 AM 
Started by openoli - Last post by puremvc
Plumbing is what we call all the pipes and pipe fittings that connect sinks and showers and toilets the like so that water runs to them. In this case think of message flow as water flow.

But the pipes concept for modular software really came about with Unix, where you can 'pipe' the output of one command (like a directory listing) through another command (like a sort) and build a pipeline of commands that process the data that flows through it.

Cheers,
-=Cliff>

 26 
 on: February 08, 2013, 01:07:10 AM 
Started by openoli - Last post by openoli
Cliff, your continuous support over years by now is unbelievable, many thanks!
There a lot hints inside your answer that I have to grapple with, hope I'll get a better understanding of all these things.

One simple question:
In pipes context there's an extensive usage of the word "plumb/plumbing".
The german translation(s) are not comprehensible within the context for me.
Could you describe what is meant with this?

Thanks!

Olaf

 27 
 on: February 07, 2013, 08:42:24 AM 
Started by openoli - Last post by puremvc
Quote
1) More than one shell core inside a multicore project?
There is a skeleton with some navigation buttons and common functions.
In multicore context this would be the 'shell', right?
Inside this 'shell' the user could open different tabs wich will be place inside a view stack.
A tab is like a module and provides different views with different functionalities and it's own tab related navigation. Should be each tab have it's own shell core? Or should each tab 'submodule' including the tab skeleton be represented by a core?
It all depends. Will each tab be massive, really different, and possibly only loaded sometimes? If so, probably make it a core of its own. But that's not the only reason to make something a separate core. Even if every section will be loaded each time, sometimes it's just easier to have each section be a core of its own because it simplifies the overall app. Inside a core, you usually only have to deal with the stuff in that core. This makes it easy for you to split the functionality across teams. You can have different teams working on different cores. Also, to answer the other question here, only one shell exists - the main app.

Quote
2) How granular-> how many cores in a multicore project?
I've read one benefit using multicore is to be able to create unit tests in a proper way.
But what should we define as a unit, my understanding is that one core represents a unit.
Within an application there could be tons of functions, modules, submodules... units after all.
As a result of this we would have tons of cores inside a project. Is there a limitation for the number of cores inside a project?
No, for unit testing, you don't have to have the core be the 'unit'. The benefit of MultiCore for unit testing is that with each test in the test suite, you can create a NEW facade for testing. With Standard, each test uses the one and only Facade, so you can't get back to a clean slate for the next test. You can test whatever you want. Look at the MultiCore framework unit tests to understand this better.

Quote
3) Shared proxies
In my application each tab has references to same proxies.
E.g. one tab provides a userlist and another tab displays detailed informations of one user. So both tabs have a reference to the 'UserCollectionProxy' and both could manipulate the proxy. How this works with the multicore version? Should this be done by using pipes?
I know the best way is to have 100% encapsulated modules, but I think this doesn't work in real life!?
Yes, this absolutely works in real life or there'd be no point in doing a modular approach at all!

The only thing that needs to be shared is data object classes and 'protocol' classes - i.e. custom message types.

All you have to change is your thinking. Don't have multiple cores 'share' a proxy, make a separate core (or cores) for talking to the service(s) and send that core a message (if you're using pipes to comm between cores) or invoke a method (if you're using interfaces and core references for comm). So your service core is the only one that has the proxy. Send it a message that says, give me the user list, and the core receives the message, executes a command to figure out what you're trying to do, and manipulates the proxy to make a call. It should use the async token pattern to remember what it was doing so that when the service responds, it can trigger a command that sends a message back (if using pipes) or calls a method on the other core (if using interfaces) to get the data back to the caller.

Quote
4) 'Dynamic' cores
To make sure that each view/mediator inside a tab handles the right notifications I make an extensive usage of notifications type parameter by passing an unique id with it. Sometimes this is a bit confusing.
Is it right that by using the multicore version I'll don't have to pay attention to this cause within multicore each core have an unique id?
Each core does have a unique ID. You still have to target the right core, and you'd be sending pipe messages instead of notes, (or making method calls if using interfaces). But your mediators wouldn't need to check for note type all the time.

Quote
5) EmployeeAdmin multicore demo?
For me it would be helpful if the EmployeeAdmin demo would be available as multicore demo.
Are there any examples like this out there?
Well, there is the PipeWorks demo, and the Modularity Demo for Flex. They should give you some idea.
https://github.com/PureMVC/puremvc-as3-demo-flex-pipeworks/wiki
https://github.com/PureMVC/puremvc-as3-demo-flex-modularity/wiki

Also you can see a real world example at http://seaofarrows.com + http://seaofarrows.com/srcview

Hope this helps!
-=Cliff>

 28 
 on: February 07, 2013, 01:12:16 AM 
Started by openoli - Last post by openoli
Hi,
I'd like to move from standard to multicore version.
After reading a lot of posts in this forum and some blog articles I've got more and more questions.
Simply changing the flex project from standard to multicore seems easy.
But unterstanding the wohle concept and transfer it to my application to get an handsome architecture seems not so easy.
Perhaps there's anybody out there who could ligten me ;-)

I'm building a tab based flex application, here're my questions:

1) More than one shell core inside a multicore project?
There is a skeleton with some navigation buttons and common functions.
In multicore context this would be the 'shell', right?
Inside this 'shell' the user could open different tabs wich will be place inside a view stack.
A tab is like a module and provides different views with different functionalities and it's own tab related navigation. Should be each tab have it's own shell core? Or should each tab 'submodule' including the tab skeleton be represented by a core?

2) How granular-> how many cores in a multicore project?
I've read one benefit using multicore is to be able to create unit tests in a proper way.
But what should we define as a unit, my understanding is that one core represents a unit.
Within an application there could be tons of functions, modules, submodules... units after all.
As a result of this we would have tons of cores inside a project. Is there a limitation for the number of cores inside a project?

3) Shared proxies
In my application each tab has references to same proxies.
E.g. one tab provides a userlist and another tab displays detailed informations of one user. So both tabs have a reference to the 'UserCollectionProxy' and both could manipulate the proxy. How this works with the multicore version? Should this be done by using pipes?
I know the best way is to have 100% encapsulated modules, but I think this doesn't work in real life!?

4) 'Dynamic' cores
To make sure that each view/mediator inside a tab handles the right notifications I make an extensive usage of notifications type parameter by passing an unique id with it. Sometimes this is a bit confusing.
Is it right that by using the multicore version I'll don't have to pay attention to this cause within multicore each core have an unique id?

5) EmployeeAdmin multicore demo?
For me it would be helpful if the EmployeeAdmin demo would be available as multicore demo.
Are there any examples like this out there?

Many many thanks for reading this and sorry for my bad english;-)

Kind regards
Olaf






 29 
 on: January 28, 2013, 08:14:40 AM 
Started by wbarto - Last post by puremvc
All of the SVN history for the PureMVC projects was transferred over to GitHub.

For the PureMVC AS3 Standard Version, look here:
https://github.com/PureMVC/puremvc-as3-standard-framework/commits/master

For MultiCore:
https://github.com/PureMVC/puremvc-as3-multicore-framework/commits/master

I don't know if the SWC format has changed in the latest Flex version or not, but you might want to just try adding the PureMVC source tree to your project and see if that changes anything. Let me know what you find.

-=Cliff>

 30 
 on: January 23, 2013, 01:56:57 PM 
Started by wbarto - Last post by wbarto
I'm trying to resurrect an old project that started under FlexBuilder 2. Under FlashBuilder 4.7 and the latest PureMVC .swc file I'm getting errors in all my Mediator classes that try to call super() (error 1118: implicit coercion of a value with static type Object to a possibly unrelated type String.)

I think there must have been some refactoring of PureMVC from the version previous to 2.0x that are causing this and I was hoping to find some update notes that would describe the changes from one version to the next.  However, everything is now hosted on github and I can't seem to find this information.  Any suggestions?

Thanks!
Bill

Pages: 1 2 [3] 4 5 ... 10


Login with username, password and session length

Powered by SMF 1.1.11 | SMF © 2006-2007, Simple Machines LLC
Copyright © 2006-2008 Futurescale, Inc.