@Caridy Thanks again! I posted a issue in the mojito-shaker github.

https://github.com/yahoo/mojito-shaker/issues/46

I keep posting here mostly for the benefit of others who might be having similar issues.

@Jesse, thanks for the note, but I guess that will be more useful as a issue under mojito-shaker repo. As for the compatibility with 0.6, I am sure there is a version that goes well with it because the team behind a big project at Yahoo! is the team behind shaker and they are running 0.6 as today :), just make sure you ask for details thru the proper channels.

Just as a follow up, I did get Shaker working. But I was partially right about it's short comings. I had a real hell of a time getting it working until I realized, it is out of sync with Mojito and does not work with 0.6.

Also the default config used in the examples won't cause Shaker to do anything with your assets. You have to specify a location other than 'default' for any of your assets to get minified, etagged, or even comboed. This is really unclear in the documents. It might be a good idea for the 'default' to be local. Or change your example to use local. It would have saved me a lot of time.

Thanks again for all your help.

Oh right it's just a YUI module. Awesome, thanks, I didn't know the app level modules overrode the core ones.

Glad to hear you guys are going so strong with 0.7. And I'm still going to give shaker another try.

You are super awesome thank you again for all your time and effort.

@Jesse, we are focused on mojito-next (0.7) at the moment, I don't think we will get back and add those hooks for you. You can copy that particular script in the yui_modules folder (at the app level), and you should be able to modify them and they will overrule any file coming from mojito (yes, app has precedence here).

That will unblock you for the time been. Just keep in mind that you have to keep an eye on any patch release for 0.6.x so you might need to recopy and rebuild the custom scripts.

thanks Caridy:)

PS I'm super excited about the changes you were talking about for 0.7.

Thanks @Carldy I'll give shaker another shot.

But in the mean time I was VERY close to having my combo service working with mojito I just needed a small change in one spot

I would propose changing getAllURLDetails from this:

getAllURLDetails: function() {    var r,        res,        ress,        m,        mojit,        mojits,        urls = {};...

To this:

getAllURLDetails: function() {    var r,        res,        ress,        m,        mojit,        mojits,        urls;    if(this._urls){        return this._urls;    }    urls = this._urls = {};...

And similarly in the YUI store. Just so the url descriptor hashes would be availible after the Mojito store init. Here is what my middleware looks like:

https://gist.github.com/anonymous/5777728

I've done a LOT of digging around in the mojito code and the only missing piece I need is to get access to the descriptors after optimizeForEnvirontment runs.

@Jesse, I can assure you that shaker does DO what you want, and @albert is very responsive, if you have any question or issue, you can open an issue in github under yahoo/mojito-shaker repo, cc' me if you want.

One of the big problems of the current mojito is that it does too much magic for users, so advance users like you will have a hard time changing things, and bending features. This is something we truly want to fix in 0.7.x. I wrote the combo and all the other pieces related to the loader, and I can probably help, but I should warn you that all those stuff are pretty complex and you have cero hooks to modify them from outside, so you will have to replace many pieces to bend it.

I tried using shaker and just found the documentation and implementation extremely lacking. I also didn't see where it was adding url based cache busting. I understand it's well integrated into your systems but it just didn't seems to be doing anything when I was using it. I used the shaker frame and added a definition into my application.json and ran shaker. But when I then ran mojito it didn't appear to have even comboed the urls. It also just seemed like Shaker was a little out of sync with Mojito as far as docs and functionality.

Is there any way to get something like what I proposed in #2 of my last post into mojito soon? I have no idea how long 0.7 will be and need a solution relatively quickly.

Ok, got it now. So, essentially, the solution with the current mojito is to use mojito-shaker. Mojito itself should not be serving static files, normally, static files are build and pushed to CDN. Shaker can do that for you, but if you don't have a CDN, or your product should run off from your own network, Shaker can do that too, by hashing the files based on the content of each file, as well as creating rollups.

That being said, mojito next (probably 0.7.x) will have some new features built-in to build and version yui modules and other assets.

More info here:https://github.com/yahoo/mojito-shaker

Now, if that's not enough, yes you will have to take control over the static combo handler that we have and do your own thing.

Ok so this editor couldn't handle my last post so here it is as a GIST:

https://gist.github.com/anonymous/5775771

Hi, Sorry for the late feedback, I rarely access Windows.It looks like it was a setup problem, it works fine.

.

My problem isn't refreshing in Dev mode. It's making sure when we do a push to our internal production environment or our public one, users are forced to get the latest code. Right now we just did a big change and push to internal production. We are starting up in production mode.

And users who have visited the site before are seeing the site broken until they clear their cache.

I've had a lot of experience and url based cache busting is by far the most effective in guaranteeing users see synced up to date static files.

Hey @Jesse, you don't have. Mojito has a feature built-in to deal with browser cache without the need of the token, but using special headers to avoid caching when in dev mode. Read more here:

http://developer.yahoo.com/cocktails/mojito/docs/faq/index.html#moj-nodemon

Basically, just restart your app using $ mojito start --context en and that should do the trick.

In 0.7.x we will improve this even more to use the NODE configuration to run in dev mode.

It's a pretty common practice to use a version param in your static urls so that it's much easier to ensure users are getting the most up to date files.

I've been working on a Mojito app that is now in an internal alpha release and people are having to hard clear their cache to get the latest files.

In my previous work with YUI I would just toss in a version into the comboBase config like so:

comboBase: "/combo/?ver=2&",comboSep: "&"

But in mojito the built in mojito combo doesn't support this method because it uses that weird ~ delimited format and breaks on any non-existent files.

Is there some better way to do URL base cache busting in Mojito? Why does Mojito break from YUI with the ~ delimited paths?

Jesse

About sockets, you can read this:

http://developer.yahoo.com/forum/Yahoo-Mojito/Mojito-and-socket-io-/1359238331872-d544f960-6f1e-4ad2-8c4c-3a7fce412eb2

Mojito is divided into two main workflows: a) middleware, who are responsible for handling the original req, and decide what to do with it, and in some cases. b) dispatching a command thru the mojito dispatcher (we call this the dispatch engine, which happens to be request agnostic).

I think a) is clear, just express middleware. But b) is more complicated, specially because the concept of a command is not well documented. In the short, a command is a simple object that tells what mojit to dispatch, what action to dispatch, some basic configurations for the mojit instance, context and parameters. Also, dispatching an action means we will need an OutputHandler, something that you can easily build since it has a very simple API.

I'm explaining all this because you can create your own layer that dispatches a mojit instance, just like mojito-tunnel-middleware does today. This also means you can have a middleware that handles the websocket and dispatches mojit instances when needed, and flush the response of those executions to the client side.

We are not focus on socket.io at the moment, but eventually we will be writing a couple of examples to people can get the idea and create their own mojits and middleware for it. I will recommend to:"create enhancement tickets thru github.com/yahoo/mojito so we can prioritize it".

P.S.: mojito 0.7.x, which is going to rely more on express and provide more ways for developers to customize things at the app level, should facilitate this use-case a lot.

Awesome work. We plan to have a page with all mojito related packages, I will make sure we add your component as well.

@caridy

I have created an npm module with your suggestions incorporated. Currently I am using Y.Cache but I am thinking to providing redis alternatives as well.

To install the addon:

npm install mojito-session-addon

Github: https://github.com/akshar100/mojito-session

fair enough, at least I learned something about middleware. what about sockets? Does Mojito allow for sockets? As an npm, the net npm should be usable for a mojito app, but am I wrong? Second, is there an example of a simple game, using mojito. Some YUI modules would be needed but I figured you may know of a simple game example, I would like to study it.

The whole multi-domain thing is really not related to mojito though. Even the serving schema that you use it not mojito specific, that's more nodejs/express related.

Caridy,i figure if the domain is different shouldnt the port be different as well. if I have a yahoo yap or yahoo group and i want some action to occur when i visit that site from the mojito app, wouldnt i need the app port to be 80, for http?

I stated i ran the test app function, to tell that i checked my code first to see if it had issues.

sequently,I can change the app port value to 8666 and it wouldnt matter?

can you look at my middleware file in my github repository and see what i am doing faulty?

and thanks for the variable help:)

I am going to crack this mojito egg if it is the last thing i do:)

I figure the appport should be 80 instead of the 8888 and other user available values, since the application is trying to read from a different domain than localhost?

I don't understand that.

In the middleware javascript file, i names it static. I call the alert function, figuring if a certain url arrives, then it will trigger it. The middleware javascript Nothing happens when i start it?

middleware will get executed on every request that comes in.

I did mojito test app

this is to run unit tests on every script in your app, nothing to do with the runtime.

for the controller server, i would like a value to be set in the middleware javascript that can be accessed within it. How do I do that?

There are many ways to set value in the middleware and get the value back into your controller, normally, what you do is to add the value to the request object like this:

req.foo = 'value in the middleware';

then in the controller you can use mojito-http-addon and do something like this:

var foo = ac.http.getRequest().foo; // this value comes from middleware

That's pretty much it.

Caridy , a made a repository for my mojito projects. The first being hconts2.The link to my repositoryin the app level application. json I figure the appport should be 80 instead of the 8888 and other user available values, since the application is trying to read from a different domain than localhost? application.jsonIn the middleware javascript file, i names it static. I call the alert function, figuring if a certain url arrives, then it will trigger it. The middleware javascriptNothing happens when i start it?I did mojito test app . and didnt get any errors?for the controller server, i would like a value to be set in the middleware javascript that can be accessed within it. How do I do that? I figured I could use some sort of global variable but where and how do you create such a variable?this is the controller.server

Thanks Caridy.

Will work on this. As far as point 3 is concerned I thought of using redis but that only increases the friction to get started. Y.Cache seems like a good option to begin with.

@Akshar, thanks for sharing the gist. A couple of recommendations:

1- you can create a npm package with your addon, and whoever wants to use it, just need to add it to the app dependencies instead of copying the code into their app. Here is a similar example: https://github.com/caridy/mojito-alter-mojit

2- dependsOn directive is deprecated in favor of the regular YUI requirements. Just make sure you require mojito-http-addon instead.

3- This Y.MemoryStore[this.sessionCookie] is problematic on the server side because you don't have a mechanism to clean up that structure. Keep in mind that on the server side, memory will continue to build up over time. That's why, in the majority of the cases, you should offload that into a different layer, saying memcache, redis, or whatever persistent and shared layer with the clean up mechanism built-in. The other option here is to use Y.Cache with a max value that is configurable per app, so memory will be recovered for old sessions.

You might find this useful

http://www.babmailer.info/2013/06/session-management-in-yahoo-mojito.html>

Note: It is not battle ready.

I guess what you're looking for here is to invoke an action on the server side for the mojit that contains the form, to do something with those values if the user is logged in, otherwise fail to process and reporting an error. Assuming that's what you need, then you can do this by simply doing what you're doing in the binder of the mojit, picking up the data from the form elements, and eventually using mojitProxy.invoke() to make a call back to the server and wait for the mojit to be dispatched.

Now, the RPC built-in in mojito for the tunnel requests will honor the middleware, so, if you have a middleware that validates the logging information, you should be able to control that in your controller for the invoked mojit, which is responsible for rendering the new result, or reporting an error. There is not need to involve the framemojit in this schema.