-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
1870 add language option to mapreduce editor #137
1870 add language option to mapreduce editor #137
Conversation
@garrensmith, @deathbearbrown for your reviewing entertainment. 🎉 |
Hey @BigBlueHat ! That's awesome! Small quick check from me: File File |
Also, question to you and @garrensmith with @deathbearbrown. The good old Futon has also predefined templates for Python and Ruby languages. As for active user of Python query server I'd like to ask: will they be preserved in Fauxton?(: If templates there are only for query servers that are ships with CouchDB, may be also add template for Erlang views like: fun({Doc}) ->
Id = couch_util:get_value(<<"_id">>, Doc),
Emit(Id, null)
end. |
Hey @BigBlueHat, Thanks for this. We are going to have to change the way we do this. We need to add this functionality as a plugin that is a seperate module that hooks in as an extensions. Not all couchdb instances that run Fauxton are capable of running different languages eg Pouchdb-server and Cloudant. The other advantage of making this a module is that we could add full support for Ruby, Python and Erlang. |
} | ||
}, | ||
|
||
defaultLang: "javascript", | ||
|
||
initialize: function(options) { | ||
var self = this; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we use that
instead of self
. It is a personal choice but for Fauxton we have stuck to the convention of that
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noted, and will fix.
@kxepal handled the Also, good thoughts on the other language stuff. @garrensmith and I are talking about how to make this an extension rather than a direct change to |
@garrensmith @deathbearbrown I think my last commit uses |
@BigBlueHat That looks right. Nice. |
Status report for anyone watching (/me glances over at @kxepal). @garrensmith and I are discussing making this a Fauxton extension and/or part of the Config addon. As it is now, it tangles the addons a bit and makes Documents unusable with pouchdb-server, Cloudant's Dashboard, and anyone else who might have a CouchDB API supporting product, but no Making it an extension should also lay the ground work for Ruby, Python, and Erlang query servers + templates, etc. Stay tuned. 📻 |
@garrensmith @kxepal @deathbearbrown I can squash this before we merge it of course, but this should properly provide javascript + one (or eventually more) languages for design docs. Right now it's JS & CoffeeScript. I'll do a separate batch of language adds later. @garrensmith I figure we can add the |
@@ -1324,9 +1353,13 @@ function(app, FauxtonAPI, Components, Documents, Databases, pouchdb, resizeColum | |||
updateReduce: function(event) { | |||
var $ele = $("#reduce-function-selector"); | |||
var $reduceContainer = $(".control-group.reduce-function"); | |||
var langTemplate = _.filter(_.pluck(this.queryservers, this.language))[0]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you make _.filter(_.pluck(this.queryservers, this.language))[0];
its own method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this.queryservers
needs to be a function that takes a the language as a parameter.
hey @BigBlueHat, so far looking good. The only issue I'm getting is that you can save a coffeescript view to a design doc thats javascript. I think we have to do some validation around that. |
@@ -63,6 +63,7 @@ function (app, FauxtonAPI) { | |||
parse: function (resp) { | |||
return _.map(resp, function (section, section_name) { | |||
return { | |||
id: section_name, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this still needed?
Needed an additional mode for ACE for handling CoffeeScript (vs. JS). Once query servers are plugins (and can presumably also provide Fauxton plugins/addons) these modes should ship with their related query server.
Maybe someday Erlang will be the default. Maybe.
mode-coffeescript.js & worker-coffeescript.js are part of ACE which has a reference in NOTICE already, so no change there.
Yeah, who knew... This also properly sets the `this.language` bit in `beforeRender()`.
If there are no others
Also removed left over console.log from earlier
@garrensmith it's closer, I think. :) I'm working on fixing the "saving coffeescript into a javascript ddoc" thing...but it's taking some heavy refactoring...and therefore time. My plan is to make the language selector it's own view and pass events between it and ViewEditor and DesignDocSelector. I'd vote that we get this into master (so it doesn't go stale) and do a refactoring pass after that--mainly to keep things moving and not block on me sorting through all all these bits interrelate. Tnx! |
Refactoring the ViewEditor is a great idea, unfortunately @BigBlueHat this PR is not ready to be merged into master. Two things need to be done to make it usable. I've added the The second fix is when a user creates a new view. If a user creates a view for an existing design doc, then they cannot choose the language for the new view but must use the language that the design doc is set as (unless the design doc is empty, then they can choose which language to write the new view in). If a user selects a new design doc then the language option should appear and they can then choose what language this design doc is written in. Once those two are implemented we should be ready to merge this in. |
@BigBlueHat I think we should close this PR but keep the branch. It needs a fair amount of work before it can be merged. As shown in (COUCHDB-1870)[https://issues.apache.org/jira/browse/COUCHDB-1870] you have assigned it back to me. It will be awhile before I get to this. |
Cool by me. Thanks, @garrensmith |
This closes apache#137 Signed-off-by: ILYA Khlopotov <[email protected]>
let vm.args and sys.config as optional
* fix Dialyzer warning * fix formatting
Fixes for apache#137 and apache#142
* Update mango docs Remove some text references and update how index is chosen * fix from review
* Update mango docs Remove some text references and update how index is chosen * fix from review
This should close the deceptively simple sounding COUCHDB-1870.
It includes a new ACE mode for CoffeeScript and all the surrounding ephemera.
Enjoy! 🍰