Apotomo – Screencasts Of Glory – Episode 3

{{{
The third episode demonstrates using more than one widget in a page. As I write a task counter widget and a list widget we discuss

* rendering multiple widgets
* simple event bubbling
* observing non-local events

}}}

Advertisements

7 thoughts on “Apotomo – Screencasts Of Glory – Episode 3

  1. Wow this is pretty cool. I see myself using aptomo in near future, however I kind of don’t like verbosity:
    * Maybe there’s some reason for this, but why do I need to generate widget tree in every controller? Maybe it would be better for each widget just set it’s parent?
    * Why do I need to specify to listen to events on root? Maybe it should be default? I actually don’t even imagine scenario where I would want to listen for events on some other element rather than root.
    * render call in display state seems like it could be skipped (would like more railsy approach where widget renders state with same name by default.

    Like

  2. Hm can’t edit comment, but also wanted to mention that voice sound is too quiet compared to sound level of music.

    Like

  3. @Andrius: The initial idea with Apotomo was that controllers can have different widget trees. That’s why you can define it per controller. If you want the same tree in every controller, define it in ApplicationController, it’s inherited.

    Listening to events in root, only, can get yourself into trouble when different widgets have same-named events. Usually a widget attaches the observer to itself, the root observers are another use-case.

    We decided that we want an explicit #render not as found in Rails: http://blog.apotomo.de/2009/12/magic-sucks-the-new-render-is-explicit/

    Like

  4. @PetrB I’m just learning the backbone.js framework, so I’ll comment: backbone.js is very similar to apotomo in that they both make saving changes to model data easier. But the ease to implement depends on the application.

    I think that apotomo is easier to implement if the models are simple or the application is simple. By simple, I mean a smaller number of fields, smaller number of widgets, smaller widgets, less dependency between widgets, that sort of thing. Once you get a large application with views containing elements that depend on each other, with models that have a lot of fields that can be changed by the user, then apotomo begins to get convoluted on the server side.

    I haven’t dug into backbone deeply yet, but the marketing text reads like it moves the code that handles the dependencies and updating and validation into the client side, so that would make sense and perhaps decrease to complexity on the server side. What I don’t know is how “magical” this is, how complex the template becomes or what not.

    What I think might be a great “win” is using cells and backbone.js together. Cells to render the reusable templates and backbone.js to handle the validations and dependencies client side, plus ajax to handle the server side actions only when needed and only for those things that really change (not the dependencies on the client side in the view that change because of a model change).

    That makes sense to me but like I say, I haven’t dug into backbone.js but I will. I’m creating a javascript-heavy application and I’m beginning to see that apotomo is great for dashboards and reusable widgets, but it’s a bit of a monster when complex dependencies creep in. A lovable monster, one that I’m not scared of, but one that would require attention if something small like a selector id changes in the view code.

    Like

  5. I’ve looked into backbone with mustache and my opinion is that if you love writing javascript and your app is complex (or rich) then backbone with template software (like mustache or others) would be a good fit, using apotomo to render the view and respond to atomic requests, or cells and controllers to render the views and respond to model CRUD. Hope this helps, it’s just my initial examination.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s