Component Actions?

[jlmi...@kahalawai.com]

Hi,

I'm sure this question is as obvious as my last!

How do you go from one montage page to the next?  So suppose I have main.reel and the someotherpage.reel how do I create a link that goes from one page to the other?

And is it possible to use an action to only change one section of the page?  So like in the splitter example... if one side of the splitter was a navigation and the other a content area can I have an action that just loads a new page into the content area?  And without having to use the substitution component?

Thanks again,

Johnny

[Kris Kowal]

I’ll let others better versed in this respond, but here are my two cents. We do not at present have a solution for this, but I believe the architecture moves us in a particular direction.

For one, any anchor tag will behave normally. Navigating away from a single page app to another single page app will work normally. Capturing navigation without leaving a single page application is the more interesting story.

I hope that we will introduce the concept of a "navigate" event, with "event.data" being the fully qualified URL of the intended target. The "navigate" event would be dispatched, for example, by clicking on a "montage/ui/anchor.reel", and unless the default is prevented by an event handler up the component responder chain, the click would be permitted to be handled as normal navigation.

It would make sense to introduce a "RouteController" component that would be able to handle "navigate" events by checking whether the "event.data" target location matches a route within the application, prevent the default of the event, and then set its "state" to information gleaned from the router, parsing parameters and the query string. The application would then respond to the state change either with change observers or bindings. You could bind a Substitution to the selected route, the model to the parameters, the controller to the query. Tom Dale of Ember talks about this idea in general.

http://vimeo.com/77760308

We could also introduce a much more powerful version of the Substitution, a NavigationController and Navigator view that would manage state transitions among panels, including animations.

The RouteController would handle the window.history or hashchange depending on how it is configured. Manipulating window.history makes sense for applications that have a <base> tag and a server that will serve up the application regardless of the path under the base URL. Using the window hash makes sense in other cases, especially when debugging without a specialized server.

Kris Kowal

[Benoit Marchant]

Kris is right that we don't have a strong solution for this. That said, the approach that Kris is talking about and that ember/Angular proposes is a server-born concept: client technologies don't do that, iOS, Cocoa or .NET don't have the concept of routing as a central concept. Each part of the MVC UI is either responsible to translate actions in the area it controls into bringing new UI in, or it's been factored in some reusable objects such as ViewController that provide services in that area.

It's an area where we will provide better answers that simplify development, and we'll take the time to design it in a way that fits well Montage and its modular, component oriented approach.

Benoit

--
You received this message because you are subscribed to the Google Groups "Montage JS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to montagejs+...@googlegroups.com.
Visit this group at http://groups.google.com/group/montagejs.
For more options, visit https://groups.google.com/groups/opt_out.

[Benoit Marchant]

Johnny,

MontageJS can be used on classical web pages to implement interactive features, widgets, etc, like other more traditional frameworks… in which case the “flow” from one page to another probably still belong server side. But MontageJS was designed to implement single page applications with an architecture similar to one of a Cocoa, Cocoa Touch or other client side technologies. 

WebObjects WOComponent was a simplification of Cocoa’s Nib. In Cocoa, an object has to load a Nib as the “Owner”, but one rarely loads different Nibs from the same object. So in WebObject the design was simplified and a WOComponent always comes with its wod, which also works great with the natural tree structure of HTML.

MontageJS uses a little bit of both: A Component by default loads its template, like in WO, as the “owner”, like in a Nib, but it does so using APIs that open the door for a component to load a different template if that were needed.

I hope that helps.

Benoit

[jlmi...@kahalawai.com]

Hi Benoit,

Thank you for that explanation that does help.  So is the idea that the main.reel is kind of like the main skeleton for the different "sections" of the application?  We are evaluating using Montage for an application that has one main view port and then about a dozen or so different panels and some panels would have their own series of subsections.  So would the right layout be having one substitution component that holds the various main panels in the main.reel?  And then each panel could have it's own substitution component that holds the components that contain the actual UI? 

Thank you,

Johnny

[Benoit Marchant]

Hi Johnny,

On Feb 16, 2014, at 10:21 AM, jlmi...@kahalawai.com wrote:

Hi Benoit,

Thank you for that explanation that does help.  

Glad it did!

So is the idea that the main.reel is kind of like the main skeleton for the different "sections" of the application?  

Yes, a benefit is that you could re-use that Main.reel in another App if you wanted to. Main is, by convention, the primary component loaded by the framework.

We are evaluating using Montage for an application that has one main view port and then about a dozen or so different panels and some panels would have their own series of subsections.  So would the right layout be having one substitution component that holds the various main panels in the main.reel?  And then each panel could have it's own substitution component that holds the components that contain the actual UI? 

The substitution is designed to help show one element/component out of a group, based on the switchValue property. A simple way to think about it is a tab view where buttons brings one of the content. So if your panels can have different kind of content, yes, that’s the idea, but if your panels organize something more static, you just instantiate components at the right place and they will bring their template in there. And in their templates, they can bring in what they need as well, and so on. Composition with Montage works really well. 

Hope that helps!

Benoit

[jlmi...@kahalawai.com]

Hi,

The app is a "multi-source map".  So the main screen is a composition of different maps i.e. a google satellite map, a map that shows the locations of recent earthquakes, a population density map et al...  The map always stays on the screen.

Then there is a "tab panel" where you have different sections i.e. a tree of the map layers (> 100) you can turn on and off, a panel for inspecting a specific object, a panel for inspecting an area of the map etc...  Some of those panels have subsections.  

In it's current manifestation it's a Flash application and the soon to be released version was written with angular.  We are looking at Montage for a future release because we think that FRB could simplify many things like automatically updating the UI after we get a refresh from the data services. 

From that very brief description would you sense that this application would be a good fit for Montage?

Best,

Johnny

[Kris Kowal]

Briefly, yes. This sounds like a good fit for Montage and FRB will probably eliminate a lot of repetitive code. You will get at least a couple uses out of Substitution based on this description.