Dynamically load wire specs and view controllers

[Lars Kappert]

Here's diving into cujo/wire. After looking at some demos, and reading some pages at cujo/wiki, I took the plunge...

Let's assume a basic application setup using Backbone (incl. $ and _). An HTML document having multiple data-view-type attributes in the DOM, where Backbone.Views should be instantiated. I want to decouple the core and view controllers, and wire things together with cujo/wire. A Backbone.View has a specific constructor signature (i.e. an options hash to define el and model), which I can configure in a wire spec. This dependency injection is important, since we can easily build view controllers with something else than Backbone, and all we need to worry about is the wire spec.

The application as described is implemented without cujo in this github repo: webpro/baseplate (in src/app-demo).

Looking at the cujo branch (in src/app-cujo), I'm wrapping my head around how to manage the view controllers. First, I would like to dynamically load and instantiate the view controller. And instantiate it twice, since it's declared twice in the HTML. What the app wire spec + controller do now is a 1-on-1 mapping of a wire spec to a view controller (which is already a win), but obviously it's not dynamic at all. The main issue now is the hard-coded el:$ref argument in the "moduleA" wire spec. Should it come from the app/controller? Or can cujo/wire handle this already? I would love to hear how you guys would tackle this scenario.

Do you have any pointers where to go from here? Of course you could open a ticket at github to discuss something if that makes sense.

I have seen some demos, but afaic they are pretty static, in that they assume a specific application to be instantiated on that specific page. What I am eventually looking for is an application layer ("portal"), managing any sub views ("widgets") it might have (think iGoogle and gadgets). So after this "baseplate" stuff I want to extend this idea a lot further, but I would be happy to first understand cujo/wire better, especially in what it could/should handle for me and what not. I'm planning to build a demo/proof-of-concept for that portal + widgets setup using cujo. Including server-side rendering, which is why all of the above is DOM-based (to apply progressive enhancement).

[Brian Cavalier]

Hey!  These are great questions.  I sent a pull request that I hope provides some interesting examples of how to do this in a wirey/cujo-ish way.  Please feel free to ask more questions in the PR :)

[unscriptable]

There's another cujo user, "Strickn" on the #cujojs channel (freenode), who is doing something similar.  His app loads "bundles" of functionality based on which features a user has purchased.  He's had some success doing this and may have some insights to offer.  :)

-- John

On Monday, February 25, 2013 7:29:21 AM UTC-5, Lars Kappert wrote:

[Lars Kappert]

Thanks, Brian! Looking into it now, and probably will ask questions in that or another repo at github.

[Jose.Badeau]

Hi,

We currently load core services (settings, logging, etc) in a wire then create the portal instance (glorified gadget dashboard with navigation) and inject the context into it. We then are able to dynamically load wire files which contain related groups of functionality such as theme, header, navigation from rest, progress similar to eclipse Orion operations, content layouts, gadgets from urls, footer, etc. Boilerplatejs does something similar except they have their own context implementation. We are looking to introduce a declarative service plugin to allow modules to request services. One service would be the wire service. This will allow us to not have to pass the wire context around. I am unable to post source code as it is private and not owned by me but maybe this was helpful.

>Jose

[Brian Cavalier]

Sounds pretty cool, Jose!  Mmmmm "wire service" ... I respect that you can't share more, but boy does that sound intriguing! :)

[Jose.Badeau]

Hey Brian, we would def like to contribute back to the community but just too busy till end of April. After that it would be great to discuss option. One thing I have noticed is most js frameworks and libs are geared towards application development. We are currently developing a client-side portal/gadget framework that will be used as the bases for Internet and intranet portals. Our main concerns are: modularity, extensibility, flexibility, security and ease of use therefore; we are very interested in things like the eclipse e4 project (javascript osgi modularity), declarative services, and plugin architecture. We have some ideas that I think fit in nicely with cujo js. There is a local swiss company who has developed a minimal but working osgi js runtime. See java magazine.de April edition for info (it's in german). It's exciting to see where js in the enterprise will go!

On another note we will try to get back to you by next week about concrete plans about a visit. Seems we are all really busy at the moment :)