Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Welcome, Guest. Please login or register.
December 12, 2017, 08:24:50 PM
Home Help Search Login Register
News: Please DM @puremvc on Twitter to gain forum access. Spambots are why we can't have nice things.
  Show Posts
Pages: 1 2 3 [4] 5 6 ... 188
46  PureMVC Manifold / Standard Version / Welcome to the Swift Standard Port on: May 15, 2015, 09:04:57 AM
The project source is hosted at GitHub:

https://github.com/PureMVC/puremvc-swift-standard-framework/wiki

The Project Owner is:
Saad Shams <saad.shams@puremvc.org>
47  Announcements and General Discussion / Architecture / Re: Asynchronous Data Access Layer on: March 06, 2015, 09:54:13 AM
Essentially your system of Proxies do the same thing as the DAOs. The DatabaseProxy would have the reference to the DB and the CRUD logic. The BooksProxy, et al, would manage a set of BookVOs and expose methods for getting them or setting them so the rest of the app interacts with them and not the DatabaseProxy. Those classes wouldn't extend the DatabaseProxy (which has as its data object the database itself), but would interact with it via composition. During startup of the app, while preparing the model, you would create the DatabaseProxy first, and then create all the other proxies like BookProxy and give them references to the DatabaseProxy. They'd hang onto that proxy and make calls on it.

If you wanted to support multiple databases, then make an IDatabaseProxy interface, and have all the proxies like BookProxy interact with DatabaseProxy using the interface. So instead of DatabaseProxy, maybe its SqlLightDatabaseProxy. Then if another DB comes along, you build another proxy that implements IDatabaseProxy and provide that to your per-table proxies.
48  Announcements and General Discussion / Architecture / Re: Asynchronous Data Access Layer on: March 03, 2015, 10:11:52 AM
Hi there,

The XMLDatabase is just one utility, it doesn't mean PureMVC is necessarily geared more toward that than SQL. It just means there isn't a utility as of yet. Your idea of a DatabaseProxy is right. DAOs typically don't store data, so I'm not sure about the need for a factory. The data ends up in a VO. A DAO is equivalent to a Delegate on the client side. The DatabaseProxy would be the business object in the pattern: http://www.oracle.com/technetwork/java/dataaccessobject-138824.html

The SQLRunner instance as well as the VOs (or TOs - Transfer Objects if you like) would be maintained as well by the DatabaseProxy. No other actor should be fiddling with it, and should go through the DatabaseProxy for operations. The Proxy should hide ALL of the DB stuff from the app and provide methods for accessing VOs and updating them. Internally it would use the DAOs to reflect those operations on the database.

49  Announcements and General Discussion / General Discussion / Re: PureMVC's future... on: January 08, 2015, 09:56:35 AM
Hi there, turtlebite,

The Swift port is not 100% yet, but will be brought into the fold as soon as it is. Saad Shams is actually working on that project as well and has ports of StateMachine and Pipes on the way.

I realize PureMVC isn't burning up the world like frameworks such as Angular (which have massively funded teams behind them and continually reinvent what they are). But it is solid, works as advertised, and will not be forcing you to change your code because we decided that there was a better way to do things and we'd better throw everything out and start over with a new grand plan.

Unlike other frameworks which try to include everything and the kitchen sink, PureMVC is tightly-focused, so it's not continually changing, and thus generating news about the latest features, etc. As someone who was tired of being jerked around by the continual need to upgrade and change as a result of dependencies, I valued the goal of defining a clear scope, reaching stability, and freezing it, over trying to include everything, and therefore never getting it quite right and having to tinker and drag devs along with me on the journey up one side of the mountain and down the other each year. In this, I was inspired by the great Java XML object model XOM http://www.xom.nu/ Since 2002, it has just done the right thing, period. It hasn't exactly burned up the Java world, few people even know about it, but from the start it was always the best option, and continues to be today.
 
As for the PureMVC website, it would be great if it were redesigned, but the effort to incorporate the forums, where the bulk of our knowledge is housed is difficult, owing to the Simple Machines (not so simple) platform. If someone more talented than myself in the web design space were to offer, I'd gladly do everything I could to help.

And as to support, you ask a question, you almost always get an answer here, or find it already answered by some other thread. I'll admit that being a Flex coder, my personal focus has mostly been in that language, but most framework related questions are applicable across platforms, and the authors of the various ports are usually available for comment.

That said I'm more than open to suggestions that could be readily implemented that could help with the PR image Smiley
50  Announcements and General Discussion / Architecture / Re: handlePipeMessage function on: November 19, 2014, 08:38:22 AM
Good luck. I think you're on the right track now.
51  Announcements and General Discussion / Architecture / Re: handlePipeMessage function on: November 17, 2014, 02:43:28 PM
You can still take the logic out of the JunctionMediator and place it in a Command. Route the message to a command, where you determine if it needs to be bounced through the auth core, and if so, then send the message off to the auth core.
52  Announcements and General Discussion / Architecture / Re: handlePipeMessage function on: November 14, 2014, 12:44:01 PM
Why not run the message through the authentication core first? then if its checks are good, it writes to an output pipe that goes to the module that consumes it. Or to a tee if multiple modules can consume.
53  Announcements and General Discussion / Architecture / Re: handlePipeMessage function on: November 13, 2014, 05:31:05 PM
I try not to have a lot of logic in the handlePipeMessage. All we want to do is transform a message into a notification.

To reduce what goes on there, you can use what we used to call a jump table in assembly.

In the JunctionMediator, set up a dictionary of message names and corresponding notification names. Then in the handlePipeMessage() method, just forward the message in the body of the appropriate notification. Let other internal actors consume the message.

If it's a display object or displayable data, one or more Mediators might handle.

If its something that requires logic like inspecting auth tokens, then commands would respond.

Do that and you don't need if/else or switch/case. You just lookup the note name, and fire off the message in the body of that note. QED.
54  Announcements and General Discussion / Architecture / Re: handlePipeMessage function on: November 06, 2014, 10:13:37 AM
Hi Saad,

It's difficult with these abstract designations to know what a better module plumbing architecture would be. Just like when we create a set of classes to solve a problem, so with modules, we need to understand and clearly define the roles, responsibilities, and collaboration patterns of the modules in question.

Perhaps you could provide a simple overview of the problem being solved by this set of modules, and what roles you've assigned to the modules themselves?

Cheers,
-=Cliff>
55  PureMVC Manifold / Multicore Version / Re: Port to Native JS - PureMVC JavaScript Utility: State Machine on: October 10, 2014, 04:37:48 PM

http://forums.puremvc.org/index.php?topic=2110.0

Cheers,
-=Cliff>
56  PureMVC Manifold / Demos and Utils / LockableDoor - A PureMVC JS StateMachine Demo on: October 10, 2014, 04:27:32 PM
This simple demo shows how the StateMachine utility works in a PureMVC application.

With click of buttons the Application can transition from OPENED to CLOSED to LOCKED state. Use of entry and exit guards. Also sends changed announcements. The demo was ported from an AS3 implemenation http://mariusht.com/blog/2009/07/14/puremvc-statemachine-lockable-door-demo/.

Pseudo-classes are written in PureMVC's optional built-in style.

The demo is located here: https://github.com/PureMVC/puremvc-js-demo-lockabledoor/wiki

It was ported from an AS3 implemenation found here: http://mariusht.com/blog/2009/07/14/puremvc-statemachine-lockable-door-demo/

The authors are Mariush T. and Saad Shams.
57  PureMVC Manifold / Demos and Utils / StateMachine - A PureMVC JS Utility on: October 10, 2014, 03:50:16 PM
This utility provides a simple yet effective Finite State Machine implementation, which allows the definition of discrete states, and the valid transitions to other states available from any given state, and the actions which trigger the transitions.

A mechanism is provided for defining the entire state machine in JSON and having a fully populated StateMachine injected into the PureMVC app.

The utility is is located here: https://github.com/PureMVC/puremvc-js-util-statemachine/wiki

The authors are Neil Manuell, Cliff Hall, and Saad Shams.
58  Announcements and General Discussion / Architecture / Re: Multicore PureMVC with Routing on: October 06, 2014, 06:26:14 AM
You could run a fully plumbed app as a daemon, and pass requests to it from a simpler CGI app, bypassing the complicated startup each time.
59  PureMVC Manifold / Port to JavaScript / Re: State Machine Utility (using native prototype property) with LockableDoor Demo on: October 03, 2014, 03:12:54 PM
Actions happen and the state changes; it's async already. Beyond that, handling retries is a stretch of the State Machine's responsibilities.

Instead, the command that deals with an enter or exit guard notification should be responsible for executing the retry policy.
60  Announcements and General Discussion / Architecture / Re: Multicore PureMVC with Routing on: October 02, 2014, 06:52:28 AM
I believe I'd implement a mediator in the shell which takes the input from the hash and sends pipe message on a STDOUT pipe to all plumbed modules. That message would pass the hash fragment to the modules, and any that need to respond may do so. If a module needs to change the hash to reflect internal state change, it could send a pipe message back to the shell which would handle that. That way, each module doesn't have to know anything about the hash. And it would be more testable, because you create a mock BrowserMediator that could send those messages without actually making hash changes, to see that the modules respond.
Pages: 1 2 3 [4] 5 6 ... 188