Is this project going anywhere?

[apotonick]

I would love to see some public discussion about this Apotomo extension first. Are you interested? ;-)

The main intend is to make widget instance variables persist over requests. Let me add a README so we can discuss. Also, consider donating if you want to speed up development. I'm sorry to mention that but I am helplessly overwhelmed by all the work for all my gems and I would love to give them all the same love but it's not easy....

[kristianmandrup]

Yeah, please make a readme or a least a design documents in a docs folder with some ideas and overview of the intentions/goals of this project. I'm not at a point where I need persistence, but I'm sure the need will arise naturally at some point for a larger project. Wouldn't it be enough with a key-value store. I guess your idea was to store it in the session hash (key-value) and then let the user configure an appropriate datastore based session store and not the cookie cache.

Currently however, I'm more willing to sponsor some feature enhancements on the apotomo core gem.

Mountable widgets Allow engines to provide widgets to main app (unless already possible via basic engines folder merge functionalilty?) I can see this is already possible in the cells gem (hidden deep down in the engine code). Docs upgrade?

Share view partials and cells Would be nice to be able to call cells or existing partials from a widget, perhaps using render_partial and render_cell, sidestepping normal render entirely.

Generators default options (outside apotomo scope) I think Rails generators in general need a common place to store default options for generators. I envision a .generators file in a yaml format:

generators
  apotomo:
    widget:
       off:
          - styles
       on:
          - scripts
       script_clazz: base2
       template: haml
...

then rails g apotomo:widget Menu would result in rails g apotomo:widget Menu --template haml --script-class base2 --no-styles --scripts

Nice!

apotomo asset integration

I started this in my own fork. Tried to provide a template for Coffeescript classes, one for each widget to encapsulate client side widget functionality instead of having ll those global functions scattered around. Also makes sense with a stylesheet for each widget I think.

Just some ideas ;) Have a nice evening!

[kuraga]

@kristianmandrup :+1: ideas! Some news?

[kristianmandrup]

I sent a mail with some ideas to Nick, and he said he wanted to work some more on this, but looks like he is too busy and needs others to take charge. You wanna join in the effort @kuraga?

I'm not sure I need the stateful aspects just yet however. Maybe due to a lack of understanding of how to use it?

[kuraga]

@kristianmandrup Source "tweet-26" non-existent. problem (http://apotomo.de/peters-guide-1.1/nesting.html) is not a lack?

P.S. I want! I think Rails components is the-best-idea-that-is-not-popular-in-the-gems-creators'-world. (The second is render_callbacks, I'm writing it :))