mojit level routing: proxyBinder or ?

Hi. Thanks for you great work on mojito. I like it but I'm still a bit confused about some points (how should I do what).

Let's I have a mojit with a button/link/events (I'll refer to it as event) that should trigger an action in the mojit controller. (As exemple, think about a form mojit that handles by himself the the submit). I see two way of doing it:

1) Having an route at the application level: the event will trigger a http request to a path define in routes.json that call or mojit action. We do not need a binder to do that, it could even not need javascript. But the route is defined at the application level. So the mojit will not work out of the box(*) (i.e. going to <localhost:8666/@myMojit/index>). Is there a way to define mojits routes with path relatives to the mojit?

2) Having a binder that listen to the event and handle it with a mojitProxy.invoke . No need to have routes, but we need to deploy the mojit to the client (then we need HTMLFrameMojit, no? the mojit will not works out ot the box(*) neither...). The good point is we do not need to configures routes.

Did I kind of get the point? Or not? Which one should I tend to use? (I would say 2)

*) I like the ability to be able to access the mojit directley with the @myMojit in the url. But this is usually lost after configuring some routes, of putting them in an HTMLFrameMojit. Some tips there?

3 Replies
  • Hey Dodo, few notes:

    • @MojitName/actionName is an artifact for development, and you should not use it in production. The only reason it is there is to get the app running even when you don't have routes. I'm pushing to get that removed from the framework in 0.6.x

    • About the specific use-case, in theory, if you have a form, you should support both use-cases, submittion by navigating to another page (non-javascript escenario) and an internal process to deal with the submit using ajax. In other words, you should have a route that handles the submit action by calling an action in a mojit, which can do something and redirect to a new url. And also, handle the action by doing mojitProxy.invoke(), which will do the same but thru a controlled tunnel request.

    • invoke does not requires all mojits to be deployed to the client side, it can execute actions in the server side if the affinity of the mojit is server.

    • invoke only works if mojito is deployed to the client side, which is what HTMLFrameMojit does, so, yes, you need that.

    Hopefully this will help to clarify!

  • Hi Caridy,

    Thanks for your clarification. I still have some confusion (point 2).

    • I was thinking this @MojitName/actionName should not be used in production, thanks for confirming that. It's however quite convenient to have a fast look at a freshly created/discovered mojit.

    • Thanks for pointing out that bot use-cases should be supported. In the non-javascript scenario, the route that handles the submit is defined at the application level, there is no way to define it in the mojit? If I put my mojit on npm, people that want to use it will need to be aware of what routes they need to set up for the mojit to work. No? Or can I imagine a way (as an addon) for my mojit to render a dynamicly created url (that is routed to the action) in my view? Bad idea, or not so possible?

    • I was a bit confused with the difference between mojito deployment and mojits deployement. Super clear now, thanks.

  • Yes, routes are, and should be, independent of the mojits, specially shareable mojits, so you can use the same mojit in two different apps without forcing those apps to use a particular url. For that matter, app developer will have to define those routes.

    About an addon generating urls, that's absolutely find, and desired. Just keep in mind that generating a url based on a defined route is not the same as creating routes dynamically.


Recent Posts

in Yahoo! Mojito