jQuery.Globalize

[michaelaird]

I've pushed a new project to my branch for jQuery.Globalize (https://github.com/jquery/globalize). It's pretty simple but I'd appreciate a bit of feedback before I put in a pull request.

Here's the branch: https://github.com/michaelaird/scriptsharp/tree/jQuery.Globalize

[nikhilk]

This should be helpful. I imagine this is a commonly used jQuery plugin. Though one thing to in fact note would be the support for globalization that comes from script# itself, esp. parsing and formatting that mimics .net like APIs, string format patterns etc. Are there things in in the jQuery.Globalize plugin that aren't available with the existing globalization story. One thing that does need to happen in script# is a tool that can spit out culture infos for various cultures.

Back to jQuery.Globalize... it would be interesting to have a named values enum with culture identifiers (or selectors as the api calls them ... not sure why, but anyway).

Minor other things would be to fix up the doc-comment on the class ... and whatever of the coding guidelines you can apply (I will take care of the rest). Those guidelines have now been converted from word doc form into wiki format at https://github.com/nikhilk/scriptsharp/wiki/Coding-Guidelines, so hopefully they're more readily available.

Also, if at all possible, when you create the pull request, can you exclude the change to the .sln file. That will save me a painful merge with the changes that have happened in the "cc" branch.

---

One other thing - we should avoid same namespace names and type names - how about the namespace being jQueryApi.Globalization?

[michaelaird]

I'm hesitant to add the cultures/selectors as named value enums. the plugin seems to include each culture as a separate file and it's up to the user to include the cultures they care about. using the named values might confuse people.

I will definitely take care of the doc-comments and try to reformat the code nicely.

For the naming, I like the namespace matching the plugin/tool and the object being named differently, like you did with jQuery.History and the jQueryHistory object. How about jQuery.Globalize and jQueryGlobalize for the object?

[michaelaird]

I didn't realize there was similar functionality built into script#. Now that I look at mscorlib, I see the InvariantCulture. maybe it makes more sense for me to work on a tool that would generate CultureInfos rather than pulling in this plugin...

[nikhilk]

On culture names ... here is a sample I saw on their github page:

Globalize.culture( "fr" );

I was hoping in script# one could write:

Globalize.Culture(Cultures.French);

So its only for the string selectors, rather than all of the information associated with the culture itself. Incidently, this comment applies to script# as well. The enum would be useful in mscorlib as well.

---

On namespace... I am fine with the class being called jQueryGlobalize. Btw, I was surprised the plugin doesn't extend the $ object which seems to be standard and instead introduce a new global method called Globalize ... wondering if the Globalize folks couldn't resist a global :)

---

Check if the script# stuff gets you everything you need, as its entirely possible the plugin might be doing more. Its probably fine to include this, while having the generator tool exist separately.

[andrewharry]

Isn't a culture made of two strings generally speaking. i.e french Canadian? Just saying french is good, but not how .net normally does things

[nikhilk]

fr and fr-CA are both valid cultures. fr is the parent of fr-CA (and fr-FR) and is less specific than the other two, and certainly useful where you're not trying to distinguish between the specific ones.

[andrewharry]

@nikhilk How far away is verion 0.8?

I was attempting to migrate my project over yesterday - but had to abandon my efforts - just couldn't trust the code base just yet (hit a few bugs as you know)

I definitely liked what I was seeing with the reduced javascript payload size. And the simplifed enums and attributes.

[nikhilk]

The general idea behind the preview release is to work out those issues. There isn't any other way they are going to surface without real-world use. Its either put out a release, and address issues as they come up, or put out a preview, stabilize it and call it a release. The sooner it appears to be working (i.e. no more issues reported), the sooner there will be a release.

Like many other oss projects, this relies on folks using it to report issues, and better yet, going the next steps to help debug them, work through them ... the sources are all there now, so my expectation is their absence should no longer be an issue on the table (something I've heard in the past).

[michaelaird]

@nikhilk how "safe" is it to move back and forth between 0.74 and 0.8? I want to try it out and give feedback but i don't have a secondary environment to use and i'm hesitant about mucking with my daily dev machine...

[nikhilk]

Things should be good between 0.7.5+ versions - since everything is packaged as nuget packages. 0.7.4 used to install scriptsharp.dll to the gac, so I am not completely sure. I did change the assembly version from 0.7 to 0.8, so theoretically it should work ... the older version pulling stuff out of the gac/program files, and newer version pulling stuff out from packages installed into a project.

The one thing that doesn't work so well side-by-side is templates. They do work, but if multiple versions are installed, then you end up seeing duplicate templates in the UI. Putting in different locations requires restructuring the vsix for each version... but maybe that needs to be done to be 100% side-by-side.

[andrewharry]

It took me a few hours to migrate a large set of projects from 0.7.5 to 0.8 Mainly getting settings right in the project files. There are a couple of changed attributes which I had to hunt around to work out what maps to what etc. I hit a couple of bugs which @nikhilk was very quick to address and patch.

But this is for work and production code, so in the end I rolled back to 0.7.6 - I just couldn't justify spending longer to hoping there weren't more subtle bugs.

I will spend some more time on the weekend with that particular fork - i'm definitely all for version 0.8 becoming stable and production ready.