Comment by evanmoran | Hacker News Reader

Comment by evanmoran | Hacker News Reader

Parent Full thread

This is actually exactly what OJ is trying to solve: creating your own helpful objects to make reasoning about your site. The plugin objects are just a bonus!

So ShoppingListView would be a powerful object that you could test and reuse. For example in the ojjs.org site I have an object called TryEditor, which does the live compiling examples. Clearly this isn't a plugin people will want (though it is made with the AceEditor plugin, which is pretty darn useful!), but it helped me to abstract it easily so I could use it, well, pretty much everywhere=).

Another way to think of it is imagine you were making Gmail. It would be helpeful to have an object handle EmailView, LabelView, and FriendView. These things are tied to data but wouldn't it be easier to interface with them as an object interface (addEmail, archiveEmail), then with direct DOM manipulation?

Indeed, that is actually how my project (strut.io) does it.

IMO you'd get a better reaction if you put a large chunk of your Plugins page on your main page. The "plugins" page better illustrates the purpose and vision of OJJS. The example on the main page is so low level it turns people off.

That being said, I still think the bulk of the "markup" should be in markup and reside as a template for your "plugin" or component to use.

So you have an EmailView component but with an EmailView template file as well. The EmailView is instantiated and manipulated in Javascript but it still has the benefits of markup via its template file.

Concrete example: Template: https://github.com/tantaman/Strut/blob/master/app/bundles/ap... Component: https://github.com/tantaman/Strut/blob/master/app/bundles/ap...

Thanks for the suggestion about the plugins. I think you are right they aren't emphasized enough=).

As for separating templating from the View it is a good point. In OJ you can use functions to create templates (or partials) since everything is just code.

I did find the unification of structure (HTML) and code (JS event bindings) quite helpful because this way the code that needs to find the HTML to bind an event is the very same code that created it. This removes the need to have class names / ids just so you can refer across HTML/CSS/JS boundaries.

Reply on news.ycombinator.com