You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Paul Davis <pa...@gmail.com> on 2009/09/09 22:20:28 UTC
Futon Improvements
Hey everyone,
So I'm at a bit of an impasse. I've got a couple ideas for how to give
Futon an extra bit of polish but I have no AJAX-fu. I thought I'd just
throw out some ideas and see if anyone wanted to try implementing
them. So, in no particular order:
* Editing design doc functions. The current view editors are awesome
for a "create design doc" work flow, but there's a bit of a disconnect
when you want to edit an existing function. When viewing a design doc,
an edit link that would load that view in the editor would be cool.
* Displaying functions in the Fields tab. It'd be nice to see if we
can make functions formatted a bit more nicely than just a plain
string as they are now. I'm not sure how well this would look, but
some smarts couldn't hurt.
* Closely related to the previous point is truncating large strings in
the fields tab. There's a source tab now so we can just let people
click that if they're wanting to see something all gigantic.
* Editing show/list functions. This is a big one, but something
similar to the view editor would be nice for editing lists and shows.
With similar edit links as above. I'm thinking that where we have view
rows output, we could just put up the view response as plain text and
then use the "raw view" button as a link to the live page.
* Simple syntax checking before doing a save or run of functions.
Throw an error if you can't compile the function locally. This could
be combined with the next idea.
* Function testing. This has been brought up before, but an
interesting thing to look into for editing views and lists would be to
have the browser fetch some subset of the db for testing. I'm not sure
on the best way to do this right now as it could be domain specific.
I'm thinking something like, create a filter function that can run
over _changes or a view and will select just some of the docs. Ideally
this would replace temporary views completely.
* Frickin tab support in the function editing boxes.
* Delete Test Suite DB's - A button on the test suite page that will
clean out the test suite db's. I tend to be OCD and going through and
deleting the test suite dbs gets old.
* Test editing - When you click a test name the browser opens a new
window showing the source code of that test. If we instead opened a
new tab that had the function source loaded into the custom test
editor that'd be cool.
* A selectable group_level or group=false on the view pages. And we
should probably change the default output in futon to a single row as
that's a constant confusion factor for new people.
* Create/Delete config section/key/value triplets.
* Raw view buttons for the config and status pages
* Remember the Fields/Source tab preference
* Another thing I'm just noting with the rest is that an interface for
setting up continuous replication is needed. Adam's still working on
some of the mechanics that will be required in the end, but some sort
of trigger for the existing functionality would be good.
* View compaction button.
* View info view (err, view of the info about a view)
That's all I can think of right now.
In terms of implementation, I'd take the well known URL approach.
Treat things on _design docs that are supposed to be functions as
functions and everything else is a string.
Also, I'm not completely helpless here. If you're a webdev and have
been discouraged by the requirement of needing to build all of CouchDB
just to have a decent environment for editing some html and
javascript, let me know and I'll put together a small script so you
can run a local web server to hack on those pages more easily. The
basic work flow could then just be to svn co the share/www directory
and then point the server at it (assuming a running couchdb instance).
Just let me know if you're interested and I can cook that up pretty
quick.
Thanks,
Paul Davis
p.s. I double posted to include user@ to cast as wide of a net as
possible. If you're not on dev@ I invite you to join up and continue
this discussion there.
Re: jQuery dependency (Re: Futon Improvements)
Posted by Vlad GURDIGA <gu...@gmail.com>.
On Thu, Sep 10, 2009 at 2:58 AM, Jan Lehnardt <ja...@apache.org> wrote:
> Hi :)
>
> On 10 Sep 2009, at 03:33, cinnebar wrote:
>
>> I am working with a group on a full featured ERP that proposes to
>> index/store data AND scripts in one or multiple json db files, perhaps
>> outputting function sets from json document/s to .js (for example) file/s
>> serverside maybe in a cache folder though perhaps clientside concates or
>> an
>> array function will be adequate for most use cases. For a number of
>> reasons
>> and although it is still infant we consider that CouchDB is the best
>> candidate for serverside handling of the json docs at the moment.
>>
>> We would like to see CouchDB independant of jquery (or even python re
>> CouchApp for that matter) for standalone couchapps 'out of the box'.
>>
>> Given the very excellent http request api that is a fundamental aspect of
>> CouchDB we consider that the current jquery dependancy is a major
>> deterrent
>> regarding general uptake of CouchDB.
>
> a) jQuery is a very popular js lib, I don't see how that is a deterrent.
> b) CouchDB has no dependency on jQuery :) Feel free to use any you like,
> I've seen raw JS, Dojo, Prototype & Sproutcore apps, maybe more without
> a line of jQuery.
+1
Re: jQuery dependency (Re: Futon Improvements)
Posted by kowsik <ko...@gmail.com>.
Been watching this thread and as a user of couchdb
(http://www.pcapr.net) and not a maintainer or a contributor I have
the following comments.
jQuery *is* the way (my personal opinion) to interact with the browser
and html and ajax and all the jazz. document.getElementById is so
passe' (Yes, I've played with Prototype and all the other
"frameworks").
In my mind the Futon UI is an application that interacts with CouchDB.
The core of couchdb has nothing to do with jQuery. As long as the REST
API is well defined (which it is) and there's an HTTP way of accessing
and managing the database, it's possible for anyone to build a
management layer with auto-completion of view results (prefix
searches), using code mirror (http://marijn.haverbeke.nl/codemirror/)
to syntax highlight the map/reduce functions for instant validation of
javascript, even going as far as eval'ing the function to make sure it
doesn't have typos (similar to
http://labs.mudynamics.com/wp-content/uploads/2009/04/icouch.html) and
so on and so forth with nothing to do with jQuery.
Furthermore, the _utils namespace access allows anyone to drop in an
alternative for managing the DB in any case. One of my first "apps"
was precisely this. Just a _utils html/javascript "app" that used the
map/reduce views to do all sorts of data-mining without requiring
another middle-tier. This was early this year, long before, CouchApp
existed.
I really don't see why jQuery is getting in the way of couch dev. It
happens to be used in the management of the database and is just one
choice of many in building a nifty UI. jQuery itself is already an
awesome abstraction for DOM manipulation. Building yet another
abstraction so we could swap jQuery with Prototype, etc doesn't make
sense to me.
My 2 cents,
K.
On Thu, Sep 10, 2009 at 9:22 PM, cinnebar <me...@gmail.com> wrote:
>> a) jQuery is a very popular js lib, I don't see how that is a deterrent.
>
> I am going to try to address this and it may take a few posts/emails.
>
> Firstly jquery is a useful, popular and all round great framework (perhaps
> this is stating the obvious).
>
> The discussion that this thread stems from began with this:
>
>> So I'm at a bit of an impasse. I've got a couple ideas for how to give
>> Futon an extra bit of polish but I have no AJAX-fu. I thought I'd just
>> throw out some ideas and see if anyone wanted to try implementing
>> them.
>
> Implementation of any new features in Futon immediately requires at least
> being down with jquery or otherwise being down with js and ajax with jquery
> on top.
>
> The project I am involved with is being built with its own js component lib
> to avoid longterm development cycles of third party libraries such as
> jquery. We are employing techniques and functions/methods from a number of
> popular and not so commonly used libraries with license requires and credits
> where credits are due...
>
> I am sure that a growing percentage of couchdb users consider jquery style
> js an unnecessary layer of complexity.
> Additionally as Futon serves as both initial access to the couch and as an
> 'out of box' demo of input methods and application design. Development of a
> couchapp first requires knowing or learning jquery which more or less first
> requires knowing or learning js and ajax. jQuery is an extra level of
> complexity.
> The argument I have noticed is that the primary target user group is running
> CouchDB to augment other complex components in a larger system but given the
> current and proposed feature set it does not seem to limit use to the said
> target user group it does not seem wise to develop CouchDB toward
> unnecessary exclusion of users that may not have years of experience using
> complex systems but may have stunning new ideas and unjaded enthusiasm.
>
> The profound succinctness of the design of CouchDB core is something that
> sets it apart and is worth vigorously maintaining. The more new features
> that are added to Futon using jquery methods the harder it is to factor out
> jquery (perhaps this is stating the obvious again). It is wise to
> anticipate progression from current standards. Perhaps loose coupling
> jquery/js libs somehow is worthwhile.
>
> One method of mitigating these issues is to provide more documentation of
> the current code base. I mentioned this as a point of discussion not as a
> feature request.
>
> Beyond this I think that clever alternatives based on Futon can only enrich
> CouchDB I dont really get why anyone would find it threatening? Often cover
> versions and remixes rock.
>
> Are there any other suggestions regarding development of Futon?
>
> I have working with a group on some alternative open source methods for
> using CouchDB that are quite different from any I have seen so far based on
> the idea that separating structure presentation and behavior of the front
> end is important but where the separation actually occurs is not important.
> More dev time is required tho and I seem to have wasted far too much time i
> wont get back being insulted for no reason.
>
>
>
>> b) CouchDB has no dependency on jQuery :) Feel free to use any you like,
>> I've seen raw JS, Dojo, Prototype & Sproutcore apps, maybe more
> without
>> a line of jQuery.
>
> the discussion that this thread stems from is concerned with Futon
> development so
>
>> Given the very excellent http request api that is a fundamental aspect of
>> CouchDB we consider that the current jquery dependancy is a major
> deterrent
>> regarding general uptake of CouchDB.
>
> was in the context of discussing the jquery dependency of Futon I thought
> that was clear there is no other CouchDB dependency. In many cases CouchDB
> is at least initially dependent on Futon. Futon serves as both initial
> access to the couch and as an 'out of box' demo of input methods and
> application design. I understand your point but given the context I am
> unsure why you felt it was a neccessary point to make?
>
Re: jQuery dependency (Re: Futon Improvements)
Posted by Simon Metson <si...@googlemail.com>.
Hi,
On 11 Sep 2009, at 06:31, Blair Zajac wrote:
> I would also rather see the CouchDB developers leverage a single
> JavaScript framework than build their own or even mix a few
> together, as the first wastes their time when they could be
> improving CouchDB core and the second limits the ease at which new
> developers can contribute, since it requires familiarity with more
> than one library. Additionally, backing ones own JavaScript library
> basically ensures that no one else will be familiar with it.
>
> Personally, if I were choosing a JavaScript library, I would choose
> ExtJs or YUI because I am familiar with them, but I don't see how
> choosing and settling on jQuery is a bad decision.
I think what's needed is a few examples of people using <insert
favourite AJAX framework here> with CouchDB on the wiki from the
community. What's used in Futon is somewhat irrelevant, and should be
decided by who ever is doing the work to upgrade it. So long as
there's not a proliferation of javascript frameworks in the CouchDB
dependancy list I don't see an issue.
Cheers
Simon
Re: jQuery dependency (Re: Futon Improvements)
Posted by Noah Slater <ns...@apache.org>.
Hey,
Should we move this over to dev@ now?
--
Noah Slater, http://tumbolia.org/nslater
Re: jQuery dependency (Re: Futon Improvements)
Posted by Benoit Chesneau <bc...@gmail.com>.
On Fri, Sep 11, 2009 at 8:35 AM, cinnebar <me...@gmail.com> wrote:
>> Building yet another abstraction so we could swap jQuery with Prototype,
> etc doesn't make
>> sense to me.
>
> Im not convinced that building a loose coupled jquery Futon is the way to go
> but I am interested in the discussion.
>
I don't see the point, jquery is a design decision made by developpers
to speed their developments and allowing couchdb to have an admin
interface. Contesting this choice would be like saying couchdb would
be better in __________ language of your choice.
Now if the question is more like having some pure js abstraction to
couchdb distributed with couchdb, I'm agree it would be nice but not
really needed.
- benoît
Re: jQuery dependency (Re: Futon Improvements)
Posted by Toby Hede <to...@gmail.com>.
I am totally puzzled ...
Futon is a simple management app built with, among other things,
jQuery. Abstracting Futon to allow switching of multiple client-side
libraries seems like a strange thing to focus on.
Anyone making a web application these days MUST be using a
cross-browser library of some description, and jQuery has the distinct
advantages of being lightweight, extensible, widely used in
production, and excellently documented.
CouchDb itself has a solid, well-documented RESTful API. If there is
an ongoing issue, the API allows anyone to build a management system
using whatever tech-fu they do posses.
Re: jQuery dependency (Re: Futon Improvements)
Posted by cinnebar <me...@gmail.com>.
Should we move this over to dev@ now? is the question
Also im uncertain if it is entirely evident from the discussion but I think
this is the critical element:
> I've got a couple ideas for how to give
> Futon an extra bit of polish but I have no AJAX-fu.
>From where I am standing it appears the current structure of Futon and its
dev procedure perhaps could be adjusted to speed up its feature development.
kind regards
Re: jQuery dependency (Re: Futon Improvements)
Posted by Noah Slater <ns...@apache.org>.
On Sat, Sep 12, 2009 at 11:10:55AM +1000, cinnebar wrote:
> There appears to be a grey area regarding what is dev@ appropriate
> discussion and what is users@ appropriate that pivots on what is core
> CouchDb and what is not.
There are no hard and fast rules, and I don't think we need any.
Generally, the developer list is for developers of CouchDB. That is, we discuss
design decision, bug squashing, releases, and other topics. The user list should
be for anything relating to the *use* of CouchDB. Even advanced use.
Best,
--
Noah Slater, http://tumbolia.org/nslater
Re: jQuery dependency (Re: Futon Improvements)
Posted by cinnebar <me...@gmail.com>.
I just wanted to clarify a statement I made in the thread that this thread
stems from:
> problem oriented development is not the only option
Of course users should be encouraged to come to users@ and look for help
with anything CouchDB(ish) but as wide scoped structural optimization is
also an important and parallel method of development its important that
users are not discouraged from opening discussion of this kind either.
There appears to be a grey area regarding what is dev@ appropriate
discussion and what is users@ appropriate that pivots on what is core
CouchDb and what is not.
cheers
Re: jQuery dependency (Re: Futon Improvements)
Posted by cinnebar <me...@gmail.com>.
> I would be very disappointed to see any management,
> demo, or whatever *human interface* be tightly coupled.
definitely
> I'm unclear on this point. Subtract jQuery for a moment. Are you
> interested in a loosely coupled Futon? Or no?
no
Re: jQuery dependency (Re: Futon Improvements)
Posted by Freddy Bowen <fr...@gmail.com>.
Hi, I've been reading...
On Fri, Sep 11, 2009 at 2:35 AM, cinnebar <me...@gmail.com> wrote:
> Im not convinced that building a loose coupled jquery Futon is the way to
> go
> but I am interested in the discussion.
>
I'm unclear on this point. Subtract jQuery for a moment. Are you
interested in a loosely coupled Futon? Or no?
I've been CouchDB for awhile now and I rarely use Futon for anything. I
think it's totally rad that it exists but I personally stick with CouchApp
and the command line. I would be very disappointed to see any management,
demo, or whatever *human interface* be tightly coupled.
Cheers,
FB
Re: jQuery dependency (Re: Futon Improvements)
Posted by cinnebar <me...@gmail.com>.
> Building yet another abstraction so we could swap jQuery with Prototype,
etc doesn't make
> sense to me.
Im not convinced that building a loose coupled jquery Futon is the way to go
but I am interested in the discussion.
Re: jQuery dependency (Re: Futon Improvements)
Posted by Blair Zajac <bl...@orcaware.com>.
cinnebar wrote:
>> a) jQuery is a very popular js lib, I don't see how that is a deterrent.
>
> I am going to try to address this and it may take a few posts/emails.
>
> Firstly jquery is a useful, popular and all round great framework (perhaps
> this is stating the obvious).
>
> The discussion that this thread stems from began with this:
>
>> So I'm at a bit of an impasse. I've got a couple ideas for how to give
>> Futon an extra bit of polish but I have no AJAX-fu. I thought I'd just
>> throw out some ideas and see if anyone wanted to try implementing
>> them.
>
> Implementation of any new features in Futon immediately requires at least
> being down with jquery or otherwise being down with js and ajax with jquery
> on top.
>
> The project I am involved with is being built with its own js component lib
> to avoid longterm development cycles of third party libraries such as
> jquery. We are employing techniques and functions/methods from a number of
> popular and not so commonly used libraries with license requires and credits
> where credits are due...
This is probably the right decision for your project, but...
> I am sure that a growing percentage of couchdb users consider jquery style
> js an unnecessary layer of complexity.
...as a new user of CouchDB I don't see it this way for the CouchDB project.
I would also rather see the CouchDB developers leverage a single JavaScript
framework than build their own or even mix a few together, as the first wastes
their time when they could be improving CouchDB core and the second limits the
ease at which new developers can contribute, since it requires familiarity with
more than one library. Additionally, backing ones own JavaScript library
basically ensures that no one else will be familiar with it.
Personally, if I were choosing a JavaScript library, I would choose ExtJs or YUI
because I am familiar with them, but I don't see how choosing and settling on
jQuery is a bad decision.
Regards,
Blair
--
Blair Zajac, Ph.D.
CTO, OrcaWare Technologies
<bl...@orcaware.com>
Subversion training, consulting and support
http://www.orcaware.com/svn/
Re: jQuery dependency (Re: Futon Improvements)
Posted by cinnebar <cc...@gmail.com>.
> If you are not familiar with jQuery already, check it out. Although if
> you really want to appreciate it, I suggest you attempt to do* without
> it for a while first.
>
Thanks for the advice. I have done a lot of front end dev and the way the
libraries like jquery balance across browsers is a great feature. I prefer
to build tweaked custom js etc on top of some intial balancing. It works
for me.
I would say a lot of CouchDB users are jquery dependent by choice or
necessity, which isnt good or bad, it just is.
cheers
Re: jQuery dependency (Re: Futon Improvements)
Posted by Oliver Boermans <bo...@gmail.com>.
2009/9/13 cinnebar <cc...@gmail.com>:
> There is a request for the development of Futon. Futon uses the built-in
> jQuery libraries which means that it is jQuery dependent.
I am jQuery dependent too. Without it attempting to write code for
cross browser compatible javascript would drive me insane. Or more
likely I would choose to do something else instead.
If you are not familiar with jQuery already, check it out. Although if
you really want to appreciate it, I suggest you attempt to do* without
it for a while first.
[For another perspective you could replace the word jQuery in the two
paragraphs above with the name of another JavaScript library.]
*Client side browser interactivity.
Re: jQuery dependency (Re: Futon Improvements)
Posted by cinnebar <cc...@gmail.com>.
Damien:
> I've haven't seen you being particularly helpful, but then I haven't been
reading your all your posts very closely
> either. However, you've definitely been disrespectful to others and if you
wish participate in this community I
> suggest you so in a respectful manner.
Basically im doing the best I can. I dont disrespect others intentionally
but my big picture is uncommon.
> In regards to JQuery functionality. You absolutely, positively DO NOT need
to use JQuery to use or administer
> CouchDB. You can do everything through simple tools like command line CURL
if you want.
> Futon is a set of static files in special dir served up via the Mochiweb
server. Futon definitely has dependency
> on JQuery
Im not sure how to express to you just how entirely I understand these
things.
> If you want a client that doesn't have a dependency on JQuery, then lead
an effort to make one and the PMC
> will consider it for inclusion into the project. Feel free to organize
such an effort on our mailling lists.
As it happens I am significantly involved in a large project already at the
moment. We are feeding a wide scoped interrelated app set to json docs and
using CouchDB to store and serve them which is why I initially involved
myself in this mail list.
The code lib we are developing is specific to the app set for an ERP system
we are already working with however I expect due to the nature of the
project at some point it will be a simple matter to use replication to
generate an app with a Futon feature set and requirements. It will take
some time as, for example, we are finding that refactoring and augmenting a
modular code base to apply js objects stored as standard json docs can be
complex though worthwhile in our view. Unfortunately this the most I
personally can reasonably offer regarding Futon dev at the moment.
>I hope you are sincere in your desire to help.
Ultimately we are concerned to assist where we can with ensuring the long
term viability and profile development of CouchDB. Beyond this I am
personally interested in supporting the use and development of CouchDB.
Following what I have learned and experienced recently its intriguing me how
the current dynamic will accommodate what may be potentially millions of new
users.
That said I really have been meaning to take a break from this mailing list
but people keep posing questions specifically in response to posts I have
made, and because I dont actually wish to be disrespectful, I have been
continuing to respond. It really was not my intention to get so entangled
in the recent discussions. If my efforts to help have been unhelpful that
is a disappointment... Never the less it would seem now is an appropriate
juncture to take a timeout.
Please understand I appreciate your taking the time to email, sincere
apologies for any disturbance and thanks for the invite to be involved in
the mailing lists whatever the reason.
UPS to you, UPS to Apache CouchDB and UPS to orders of magnitude.
cheers
Re: jQuery dependency (Re: Futon Improvements)
Posted by Damien Katz <da...@apache.org>.
cinnebar, I hope you are sincere in your desire to help. I've haven't
seen you being particularly helpful, but then I haven't been reading
your all your posts very closely either. However, you've definitely
been disrespectful to others and if you wish participate in this
community I suggest you so in a respectful manner.
In regards to JQuery functionality. You absolutely, positively DO NOT
need to use JQuery to use or administer CouchDB. You can do everything
through simple tools like command line CURL if you want.
Futon is a set of static files in special dir served up via the
Mochiweb server. Futon definitely has dependency on JQuery. If you
want a client that doesn't have a dependency on JQuery, then lead an
effort to make one and the PMC will consider it for inclusion into the
project. Feel free to organize such an effort on our mailling lists.
-Damien
On Sep 13, 2009, at 6:01 PM, cinnebar wrote:
>> Less of the fucking attitude please.
>
> soz no offence intended hope it was helpful
>
> regards
Re: jQuery dependency (Re: Futon Improvements)
Posted by Noah Slater <ns...@apache.org>.
On Mon, Sep 14, 2009 at 08:01:59AM +1000, cinnebar wrote:
> > Less of the fucking attitude please.
>
> soz no offence intended hope it was helpful
That's okay prettyboy, your berkish behaviour is amusing me.
--
Noah Slater, http://tumbolia.org/nslater
Re: jQuery dependency (Re: Futon Improvements)
Posted by cinnebar <cc...@gmail.com>.
> Less of the fucking attitude please.
soz no offence intended hope it was helpful
regards
Re: jQuery dependency (Re: Futon Improvements)
Posted by Noah Slater <ns...@apache.org>.
On Mon, Sep 14, 2009 at 07:53:38AM +1000, cinnebar wrote:
> >
> > Could you clarify? A request for…?
> >
> >
> Good gawd prettyboy where were you when they were handing out the smarts ?
Less of the fucking attitude please.
--
Noah Slater, http://tumbolia.org/nslater
Re: jQuery dependency (Re: Futon Improvements)
Posted by cinnebar <cc...@gmail.com>.
>
> Could you clarify? A request for…?
>
>
Good gawd prettyboy where were you when they were handing out the smarts ?
Development request refers to Pauls post titled Futon Improvements ...maybe
its closed already in @dev?
...either way for you cut and paste follows:
from Paul Davis <pa...@gmail.com>
reply-to user@couchdb.apache.org
to dev@couchdb.apache.org,
user@couchdb.apache.org
date Thu, Sep 10, 2009 at 6:20 AM
subject Futon Improvements
mailing list <user.couchdb.apache.org> Filter messages from this mailing
list
mailed-by couchdb.apache.org
Sep 10 (4 days ago)
Hey everyone,
So I'm at a bit of an impasse. I've got a couple ideas for how to give
Futon an extra bit of polish but I have no AJAX-fu. I thought I'd just
throw out some ideas and see if anyone wanted to try implementing
them. So, in no particular order:
* Editing design doc functions. The current view editors are awesome
for a "create design doc" work flow, but there's a bit of a disconnect
when you want to edit an existing function. When viewing a design doc,
an edit link that would load that view in the editor would be cool.
* Displaying functions in the Fields tab. It'd be nice to see if we
can make functions formatted a bit more nicely than just a plain
string as they are now. I'm not sure how well this would look, but
some smarts couldn't hurt.
* Closely related to the previous point is truncating large strings in
the fields tab. There's a source tab now so we can just let people
click that if they're wanting to see something all gigantic.
* Editing show/list functions. This is a big one, but something
similar to the view editor would be nice for editing lists and shows.
With similar edit links as above. I'm thinking that where we have view
rows output, we could just put up the view response as plain text and
then use the "raw view" button as a link to the live page.
* Simple syntax checking before doing a save or run of functions.
Throw an error if you can't compile the function locally. This could
be combined with the next idea.
* Function testing. This has been brought up before, but an
interesting thing to look into for editing views and lists would be to
have the browser fetch some subset of the db for testing. I'm not sure
on the best way to do this right now as it could be domain specific.
I'm thinking something like, create a filter function that can run
over _changes or a view and will select just some of the docs. Ideally
this would replace temporary views completely.
* Frickin tab support in the function editing boxes.
* Delete Test Suite DB's - A button on the test suite page that will
clean out the test suite db's. I tend to be OCD and going through and
deleting the test suite dbs gets old.
* Test editing - When you click a test name the browser opens a new
window showing the source code of that test. If we instead opened a
new tab that had the function source loaded into the custom test
editor that'd be cool.
* A selectable group_level or group=false on the view pages. And we
should probably change the default output in futon to a single row as
that's a constant confusion factor for new people.
* Create/Delete config section/key/value triplets.
* Raw view buttons for the config and status pages
* Remember the Fields/Source tab preference
* Another thing I'm just noting with the rest is that an interface for
setting up continuous replication is needed. Adam's still working on
some of the mechanics that will be required in the end, but some sort
of trigger for the existing functionality would be good.
* View compaction button.
* View info view (err, view of the info about a view)
That's all I can think of right now.
In terms of implementation, I'd take the well known URL approach.
Treat things on _design docs that are supposed to be functions as
functions and everything else is a string.
Also, I'm not completely helpless here. If you're a webdev and have
been discouraged by the requirement of needing to build all of CouchDB
just to have a decent environment for editing some html and
javascript, let me know and I'll put together a small script so you
can run a local web server to hack on those pages more easily. The
basic work flow could then just be to svn co the share/www directory
and then point the server at it (assuming a running couchdb instance).
Just let me know if you're interested and I can cook that up pretty
quick.
Thanks,
Paul Davis
p.s. I double posted to include user@ to cast as wide of a net as
possible. If you're not on dev@ I invite you to join up and continue
this discussion there.
Noah Slater, http://tumbolia.org/nslater
>
Re: jQuery dependency (Re: Futon Improvements)
Posted by Noah Slater <ns...@apache.org>.
On Sun, Sep 13, 2009 at 08:47:15PM +1000, cinnebar wrote:
> There is a request for the development of Futon. Futon uses the built-in
> jQuery libraries which means that it is jQuery dependent.
Could you clarify? A request for…?
Thanks,
--
Noah Slater, http://tumbolia.org/nslater
Re: jQuery dependency (Re: Futon Improvements)
Posted by cinnebar <cc...@gmail.com>.
For the sake of discussion:
> [1]
http://svn.apache.org/repos/asf/couchdb/trunk/share/www/script/couch.js
> [2]
http://svn.apache.org/repos/asf/couchdb/trunk/share/www/script/jquery.couch.js
These client libs were mentioned in the Futon Improvements thread which was
forked to this jQuery dependency thread.
> There's an advantage in using the built-in clients because the code
> will probably be in browser cache, and it makes application component
> reuse a little easier to have a shared basic library as well.
Its safe to say that a shared library (loaded to and stored in browser
cache) and code reuse are fundamental to good front end design, whether the
shared library is jQuery, Dojo, couch.js or whatever.
It may be worth mentioning that a long stack of js src files in a html doc
is probably ok after intial caching if they are static files. Excessive
weight is undesirable.
The built in libs with the prefix jquery (in the scripts folder in the www
folder next to the server folder containing the main.js file included in the
CouchDB install) are dependent on parts of the jquery.js file which
essentially is also a built-in lib.
There is a request for the development of Futon. Futon uses the built-in
jQuery libraries which means that it is jQuery dependent.
The request can be found in a thread called Futon Improvements.
cheers
Re: jQuery dependency (Re: Futon Improvements)
Posted by Chris Anderson <jc...@apache.org>.
On Thu, Sep 10, 2009 at 9:22 PM, cinnebar <me...@gmail.com> wrote:
>> a) jQuery is a very popular js lib, I don't see how that is a deterrent.
>
> I am going to try to address this and it may take a few posts/emails.
>
> Firstly jquery is a useful, popular and all round great framework (perhaps
> this is stating the obvious).
>
> The discussion that this thread stems from began with this:
>
>> So I'm at a bit of an impasse. I've got a couple ideas for how to give
>> Futon an extra bit of polish but I have no AJAX-fu. I thought I'd just
>> throw out some ideas and see if anyone wanted to try implementing
>> them.
>
> Implementation of any new features in Futon immediately requires at least
> being down with jquery or otherwise being down with js and ajax with jquery
> on top.
>
> The project I am involved with is being built with its own js component lib
> to avoid longterm development cycles of third party libraries such as
> jquery. We are employing techniques and functions/methods from a number of
> popular and not so commonly used libraries with license requires and credits
> where credits are due...
>
> I am sure that a growing percentage of couchdb users consider jquery style
> js an unnecessary layer of complexity.
Being tied to closely to a single library isn't always a great idea.
CouchDB ships with 2 javascript client libraries:
The couch.js reference client [1] is used for the test suite. It is
synchronous, instead of using callbacks, and is designed to document
the HTTP API. CouchRest and a few of the other non-JS client libraries
started out as ports of couch.js
jquery.couch.js [2] is the client Chris Lenz wrote for Futon, and
which is the basis for a lot of the CouchApp JS I've been writing. It
is a full featured asynchronous client, and since I already prefer
jQuery (I had a long slog getting there...) I don't have a big reason
to experiment with others.
There's an advantage in using the built-in clients because the code
will probably be in browser cache, and it makes application component
reuse a little easier to have a shared basic library as well.
There's another client called BrowserCouch [3] that is pretty cool.
It's JS that replicates with CouchDB and then makes local calls
against the HTML5 localStorage API.
That said, I encourage people to please do crazy stuff with the Couch
Ajax APIs. If you've written a JS CouchDB library, please release your
code. I don't think CouchApp or any of these are the end-all-be-all of
JS CouchDB development. What really matters is what people are doing
with it.
Chris
[1] http://svn.apache.org/repos/asf/couchdb/trunk/share/www/script/couch.js
[2] http://svn.apache.org/repos/asf/couchdb/trunk/share/www/script/jquery.couch.js
[3] http://hg.toolness.com/browser-couch/raw-file/blog-post/index.html
> Additionally as Futon serves as both initial access to the couch and as an
> 'out of box' demo of input methods and application design. Development of a
> couchapp first requires knowing or learning jquery which more or less first
> requires knowing or learning js and ajax. jQuery is an extra level of
> complexity.
> The argument I have noticed is that the primary target user group is running
> CouchDB to augment other complex components in a larger system but given the
> current and proposed feature set it does not seem to limit use to the said
> target user group it does not seem wise to develop CouchDB toward
> unnecessary exclusion of users that may not have years of experience using
> complex systems but may have stunning new ideas and unjaded enthusiasm.
>
> The profound succinctness of the design of CouchDB core is something that
> sets it apart and is worth vigorously maintaining. The more new features
> that are added to Futon using jquery methods the harder it is to factor out
> jquery (perhaps this is stating the obvious again). It is wise to
> anticipate progression from current standards. Perhaps loose coupling
> jquery/js libs somehow is worthwhile.
>
> One method of mitigating these issues is to provide more documentation of
> the current code base. I mentioned this as a point of discussion not as a
> feature request.
>
> Beyond this I think that clever alternatives based on Futon can only enrich
> CouchDB I dont really get why anyone would find it threatening? Often cover
> versions and remixes rock.
>
> Are there any other suggestions regarding development of Futon?
>
> I have working with a group on some alternative open source methods for
> using CouchDB that are quite different from any I have seen so far based on
> the idea that separating structure presentation and behavior of the front
> end is important but where the separation actually occurs is not important.
> More dev time is required tho and I seem to have wasted far too much time i
> wont get back being insulted for no reason.
>
>
>
>> b) CouchDB has no dependency on jQuery :) Feel free to use any you like,
>> I've seen raw JS, Dojo, Prototype & Sproutcore apps, maybe more
> without
>> a line of jQuery.
>
> the discussion that this thread stems from is concerned with Futon
> development so
>
>> Given the very excellent http request api that is a fundamental aspect of
>> CouchDB we consider that the current jquery dependancy is a major
> deterrent
>> regarding general uptake of CouchDB.
>
> was in the context of discussing the jquery dependency of Futon I thought
> that was clear there is no other CouchDB dependency. In many cases CouchDB
> is at least initially dependent on Futon. Futon serves as both initial
> access to the couch and as an 'out of box' demo of input methods and
> application design. I understand your point but given the context I am
> unsure why you felt it was a neccessary point to make?
>
--
Chris Anderson
http://jchrisa.net
http://couch.io
Re: jQuery dependency (Re: Futon Improvements)
Posted by Noah Slater <ns...@apache.org>.
On Fri, Sep 11, 2009 at 02:22:46PM +1000, cinnebar wrote:
> Implementation of any new features in Futon immediately requires at least
> being down with jquery or otherwise being down with js and ajax with jquery
> on top.
Yeps, sure. But hacking on the build systems requires knowledge of the GNU
Autotools, and hacking on the database core requires knowledge of Erlang and
to a large part, understanding of HTTP and hypermedia best practice.
I'm not saying that this isn't something we should be thinking about, but like a
few other people have pointed out, the browser environment is so heterogeneous
that we will need to use something like this whatever the case.
Swapping out jQuery for our own library smacks of NIH. But ultimately, I think
that decision rests with whomever is responsible for Futon, which is of course,
Chris Lenz at the moment. If he wanted to switch to Lenz's Awesome DHTML Library
of Win and it wasn't clearly an insane design decision, then sweet!
Best,
--
Noah Slater, http://tumbolia.org/nslater
Re: jQuery dependency (Re: Futon Improvements)
Posted by Tom Sante <to...@gmail.com>.
On Fri, Sep 11, 14:22, cinnebar wrote:
> Implementation of any new features in Futon immediately requires at least
> being down with jquery or otherwise being down with js and ajax with jquery
> on top.
>
> The project I am involved with is being built with its own js component lib
> to avoid longterm development cycles of third party libraries such as
> jquery. We are employing techniques and functions/methods from a number of
> popular and not so commonly used libraries with license requires and credits
> where credits are due...
>
> I am sure that a growing percentage of couchdb users consider jquery style
> js an unnecessary layer of complexity.
> Additionally as Futon serves as both initial access to the couch and as an
> 'out of box' demo of input methods and application design. Development of a
> couchapp first requires knowing or learning jquery which more or less first
> requires knowing or learning js and ajax. jQuery is an extra level of
> complexity.
Instead of a unnecessary layer of complexity, jquery avoids the couchdb
developers from having to waste time reinventing the wheel. So using
jquery actually avoids you having to spend time writing your own multi
browser compatible AJAX methods and helps you write easier more
concise js. Like the jQuery motto: Write Less, Do More. The dependency
on jQuery removes the need for unnecessary layers of complexity.
> Development of a
> couchapp first requires knowing or learning jquery which more or
> less first
> requires knowing or learning js and ajax.
If all communication with couchdb is by http than it's unavoidable to
use some js and ajax. But different js libraries like jQuery,
prototype,... make that easy to do too. Or you can go pure js. Or any
other language that can communicate through http. True Futon is the
demo and initial access for couchdb, but it's only one possible demo.
The couchdb wiki has several alternatives explained for interfacing
with couchdb and help you get on your way writing your own client.
I really don't understand you fixation on the usage of jquery. It's a
library used to make js programming easier, but anything else can be
used if your needs are different. That's the point of using a library
in any language, avoid doing the same work alrady done. And here
jquery was chosen, deal with it. It's not a complicated libary and
adding other abstraction layers to allow different libaries to be used
by futon wastes precious developer time that is better spend on
couchdb itself.
Re: jQuery dependency (Re: Futon Improvements)
Posted by cinnebar <me...@gmail.com>.
> a) jQuery is a very popular js lib, I don't see how that is a deterrent.
I am going to try to address this and it may take a few posts/emails.
Firstly jquery is a useful, popular and all round great framework (perhaps
this is stating the obvious).
The discussion that this thread stems from began with this:
> So I'm at a bit of an impasse. I've got a couple ideas for how to give
> Futon an extra bit of polish but I have no AJAX-fu. I thought I'd just
> throw out some ideas and see if anyone wanted to try implementing
> them.
Implementation of any new features in Futon immediately requires at least
being down with jquery or otherwise being down with js and ajax with jquery
on top.
The project I am involved with is being built with its own js component lib
to avoid longterm development cycles of third party libraries such as
jquery. We are employing techniques and functions/methods from a number of
popular and not so commonly used libraries with license requires and credits
where credits are due...
I am sure that a growing percentage of couchdb users consider jquery style
js an unnecessary layer of complexity.
Additionally as Futon serves as both initial access to the couch and as an
'out of box' demo of input methods and application design. Development of a
couchapp first requires knowing or learning jquery which more or less first
requires knowing or learning js and ajax. jQuery is an extra level of
complexity.
The argument I have noticed is that the primary target user group is running
CouchDB to augment other complex components in a larger system but given the
current and proposed feature set it does not seem to limit use to the said
target user group it does not seem wise to develop CouchDB toward
unnecessary exclusion of users that may not have years of experience using
complex systems but may have stunning new ideas and unjaded enthusiasm.
The profound succinctness of the design of CouchDB core is something that
sets it apart and is worth vigorously maintaining. The more new features
that are added to Futon using jquery methods the harder it is to factor out
jquery (perhaps this is stating the obvious again). It is wise to
anticipate progression from current standards. Perhaps loose coupling
jquery/js libs somehow is worthwhile.
One method of mitigating these issues is to provide more documentation of
the current code base. I mentioned this as a point of discussion not as a
feature request.
Beyond this I think that clever alternatives based on Futon can only enrich
CouchDB I dont really get why anyone would find it threatening? Often cover
versions and remixes rock.
Are there any other suggestions regarding development of Futon?
I have working with a group on some alternative open source methods for
using CouchDB that are quite different from any I have seen so far based on
the idea that separating structure presentation and behavior of the front
end is important but where the separation actually occurs is not important.
More dev time is required tho and I seem to have wasted far too much time i
wont get back being insulted for no reason.
> b) CouchDB has no dependency on jQuery :) Feel free to use any you like,
> I've seen raw JS, Dojo, Prototype & Sproutcore apps, maybe more
without
> a line of jQuery.
the discussion that this thread stems from is concerned with Futon
development so
> Given the very excellent http request api that is a fundamental aspect of
> CouchDB we consider that the current jquery dependancy is a major
deterrent
> regarding general uptake of CouchDB.
was in the context of discussing the jquery dependency of Futon I thought
that was clear there is no other CouchDB dependency. In many cases CouchDB
is at least initially dependent on Futon. Futon serves as both initial
access to the couch and as an 'out of box' demo of input methods and
application design. I understand your point but given the context I am
unsure why you felt it was a neccessary point to make?
Re: jQuery dependency (Re: Futon Improvements)
Posted by Jesse Hallett <ha...@gmail.com>.
Maybe the problem is that the JavaScript interface library that ships with
CouchDB depends on jQuery. If that is the case and if it only relies on
jQuery for XMLHttpRequest support then it should be reasonably easy to
factor out.
On the other hand a jQuery dependency in Futon is a good thing, and would be
much more difficult to factor out anyway.
On Sep 10, 2009 2:59 AM, "Jan Lehnardt" <ja...@apache.org> wrote:
Hi :)
On 10 Sep 2009, at 03:33, cinnebar wrote:
I am working with a group on a full featured ERP that proposes to
> index/store data AND scripts in one or multiple json db files, perhaps
> outputting function sets from json document/s to .js (for example) file/s
> serverside maybe in a cache folder though perhaps clientside concates or an
> array function will be adequate for most use cases. For a number of
> reasons
> and although it is still infant we consider that CouchDB is the best
> candidate for serverside handling of the json docs at the moment.
>
> We would like to see CouchDB independant of jquery (or even python re
> CouchApp for that matter) for standalone couchapps 'out of the box'.
>
> Given the very excellent http request api that is a fundamental aspect of
> CouchDB we consider that the current jquery dependancy is a major deterrent
> regarding general uptake of CouchDB.
>
a) jQuery is a very popular js lib, I don't see how that is a deterrent.
b) CouchDB has no dependency on jQuery :) Feel free to use any you like,
I've seen raw JS, Dojo, Prototype & Sproutcore apps, maybe more without
a line of jQuery.
Cheers
Jan
--
> While the jquery dependency still stands we consider that the dev rate of
> futon and more generally other standalone couchapps will be increased
> dramatically with detailed documentation (commented or otherwise) of the
> jquery.couch.js and other 'in box' jquery[].js files with a simple list of
> function dependancies regards to jquery.js and perhaps documentation of
> those functions too. Perhaps the fastest way for this to proceed would be
> for the author of jquery.couch.js to provide some explanation in order to
> augment general documentation of 'in box' CouchDB components.
>
> As yet no time to look through the test suite for specifically jquery
> dependancies and documentation would be helpful here too.
>
> Of course there is the couch.js providing SJAX methods if required but AJAX
> is 'the shit' (or AJAJ as is more exact in this case - hehe) and perhaps
> it
> could be included in a 'COUCH' object namespace. We are working with an
> 'EOS' object at the moment but this may change.
>
jQuery dependency (Re: Futon Improvements)
Posted by Jan Lehnardt <ja...@apache.org>.
Hi :)
On 10 Sep 2009, at 03:33, cinnebar wrote:
> I am working with a group on a full featured ERP that proposes to
> index/store data AND scripts in one or multiple json db files, perhaps
> outputting function sets from json document/s to .js (for example)
> file/s
> serverside maybe in a cache folder though perhaps clientside
> concates or an
> array function will be adequate for most use cases. For a number of
> reasons
> and although it is still infant we consider that CouchDB is the best
> candidate for serverside handling of the json docs at the moment.
>
> We would like to see CouchDB independant of jquery (or even python re
> CouchApp for that matter) for standalone couchapps 'out of the box'.
>
> Given the very excellent http request api that is a fundamental
> aspect of
> CouchDB we consider that the current jquery dependancy is a major
> deterrent
> regarding general uptake of CouchDB.
a) jQuery is a very popular js lib, I don't see how that is a deterrent.
b) CouchDB has no dependency on jQuery :) Feel free to use any you like,
I've seen raw JS, Dojo, Prototype & Sproutcore apps, maybe more
without
a line of jQuery.
Cheers
Jan
--
>
> While the jquery dependency still stands we consider that the dev
> rate of
> futon and more generally other standalone couchapps will be increased
> dramatically with detailed documentation (commented or otherwise) of
> the
> jquery.couch.js and other 'in box' jquery[].js files with a simple
> list of
> function dependancies regards to jquery.js and perhaps documentation
> of
> those functions too. Perhaps the fastest way for this to proceed
> would be
> for the author of jquery.couch.js to provide some explanation in
> order to
> augment general documentation of 'in box' CouchDB components.
>
> As yet no time to look through the test suite for specifically jquery
> dependancies and documentation would be helpful here too.
>
> Of course there is the couch.js providing SJAX methods if required
> but AJAX
> is 'the shit' (or AJAJ as is more exact in this case - hehe) and
> perhaps it
> could be included in a 'COUCH' object namespace. We are working
> with an
> 'EOS' object at the moment but this may change.
Re: Futon Improvements
Posted by Jan Lehnardt <ja...@apache.org>.
On 10 Sep 2009, at 17:03, Elton Okada wrote:
> jQuery and CouchApp are much easier to write, but what about security
> issues ? i mean, in this way our aplication logic get exposed, this
> is my
> great doubt in using it
>
> what do you think ?
Open Source FTW :)
Cheers
Jan
--
>
> On Thu, Sep 10, 2009 at 11:07 AM, Nitin Borwankar
> <ni...@borwankar.com>wrote:
>
>> I use CouchApp and jQuery a lot with CouchDB while my collaborator
>> and boss
>> strictly uses the REST API via Python ( this could be any language,
>> Python
>> not required as a client, or just curl from the command line )I
>> personally
>> like jQuery and CouchApp has certainly made it much easier to write
>> and
>> manage views, although I wish I did not have to use CouchApp just
>> for that.
>>
>> In any case CouchDB by itself does not depend on jQuery.
>>
>> Having said that, it is true that the *.js libs that make up the
>> client
>> api's and tools around CouchDB could use a lot more documentation -
>> usage
>> of
>> Couch would expand, IMHO, if these were better annotated.
>>
>> Nitin
>>
>> 37% of all statistics are made up on the spot
>>
>> -------------------------------------------------------------------------------------
>> Nitin Borwankar
>> nborwankar@gmail.com
>>
>>
>> On Thu, Sep 10, 2009 at 1:12 AM, Nils Breunese <n....@vpro.nl>
>> wrote:
>>
>>> cinnebar wrote:
>>>
>>>> We would like to see CouchDB independant of jquery (or even
>>>> python re
>>>
>>>> CouchApp for that matter) for standalone couchapps 'out of the
>>>> box'.
>>>>
>>>> Given the very excellent http request api that is a fundamental
>>>> aspect
>> of
>>>> CouchDB we consider that the current jquery dependancy is a major
>>>> deterrent
>>>> regarding general uptake of CouchDB.
>>>>
>>>
>>> I don't believe CouchDB depends on jQuery. It's there if you want
>>> to use
>>> it, but it's not required for anything AFAIK. CouchApp is a third
>>> party
>> tool
>>> written in Python, so yeah, you need Python if you want to use
>>> CouchApp.
>> You
>>> don't need to use CouchApp though, you can push design documents
>>> any way
>> you
>>> like.
>>>
>>> Nils Breunese.
>>>
>>
Re: Futon Improvements
Posted by Elton Okada <el...@gmail.com>.
jQuery and CouchApp are much easier to write, but what about security
issues ? i mean, in this way our aplication logic get exposed, this is my
great doubt in using it
what do you think ?
On Thu, Sep 10, 2009 at 11:07 AM, Nitin Borwankar <ni...@borwankar.com>wrote:
> I use CouchApp and jQuery a lot with CouchDB while my collaborator and boss
> strictly uses the REST API via Python ( this could be any language, Python
> not required as a client, or just curl from the command line )I personally
> like jQuery and CouchApp has certainly made it much easier to write and
> manage views, although I wish I did not have to use CouchApp just for that.
>
> In any case CouchDB by itself does not depend on jQuery.
>
> Having said that, it is true that the *.js libs that make up the client
> api's and tools around CouchDB could use a lot more documentation - usage
> of
> Couch would expand, IMHO, if these were better annotated.
>
> Nitin
>
> 37% of all statistics are made up on the spot
>
> -------------------------------------------------------------------------------------
> Nitin Borwankar
> nborwankar@gmail.com
>
>
> On Thu, Sep 10, 2009 at 1:12 AM, Nils Breunese <n....@vpro.nl> wrote:
>
> > cinnebar wrote:
> >
> > > We would like to see CouchDB independant of jquery (or even python re
> >
> >> CouchApp for that matter) for standalone couchapps 'out of the box'.
> >>
> >> Given the very excellent http request api that is a fundamental aspect
> of
> >> CouchDB we consider that the current jquery dependancy is a major
> >> deterrent
> >> regarding general uptake of CouchDB.
> >>
> >
> > I don't believe CouchDB depends on jQuery. It's there if you want to use
> > it, but it's not required for anything AFAIK. CouchApp is a third party
> tool
> > written in Python, so yeah, you need Python if you want to use CouchApp.
> You
> > don't need to use CouchApp though, you can push design documents any way
> you
> > like.
> >
> > Nils Breunese.
> >
>
Re: Futon Improvements
Posted by Nitin Borwankar <ni...@borwankar.com>.
>
>
> Emails to dev@ for discussion work fine. JIRA's are preferred for
> actual patches or bug reports.
>
>
I'd like to create a bug report about jQuery then - it appears that use of
jQuery by CouchDB results in long email threads on user@. Is this a feature
or a bug ? :-)
<duck>
Nitin
> Cheers Nitin!
>
> Jan
> --
>
>
>
Re: Futon Improvements
Posted by Jan Lehnardt <ja...@apache.org>.
On 10 Sep 2009, at 21:50, Nitin Borwankar wrote:
> On Thu, Sep 10, 2009 at 7:12 AM, Noah Slater <ns...@apache.org>
> wrote:
>
>> On Thu, Sep 10, 2009 at 07:07:09AM -0700, Nitin Borwankar wrote:
>>> Having said that, it is true that the *.js libs that make up the
>>> client
>>> api's and tools around CouchDB could use a lot more documentation
>>> - usage
>> of
>>> Couch would expand, IMHO, if these were better annotated.
>>
>> It sounds like you have the knowledge and motivation needed to lead
>> a push
>> of
>> effort on this front. CouchDB is a big project, and we're all
>> pulling in
>> our own
>> directions. If you'd want to send us a few patches for this, I'm
>> sure we
>> could
>> get them included for you!
>>
>>
> Motivation certainly, knowledge partially. But it's interesting you
> said
> this because I was thinking may be I should just take one of the .js
> files
> and start to comment it and ask questions on the list.
> I'll gladly volunteer to start with one of the .js files and follow
> your
> suggestions and take it from there.
> Thanks for pushing. Should I create an issue in JIRA or .... ?
Emails to dev@ for discussion work fine. JIRA's are preferred for
actual patches or bug reports.
Cheers Nitin!
Jan
--
Re: Futon Improvements
Posted by Nitin Borwankar <ni...@borwankar.com>.
On Thu, Sep 10, 2009 at 7:12 AM, Noah Slater <ns...@apache.org> wrote:
> On Thu, Sep 10, 2009 at 07:07:09AM -0700, Nitin Borwankar wrote:
> > Having said that, it is true that the *.js libs that make up the client
> > api's and tools around CouchDB could use a lot more documentation - usage
> of
> > Couch would expand, IMHO, if these were better annotated.
>
> It sounds like you have the knowledge and motivation needed to lead a push
> of
> effort on this front. CouchDB is a big project, and we're all pulling in
> our own
> directions. If you'd want to send us a few patches for this, I'm sure we
> could
> get them included for you!
>
>
Motivation certainly, knowledge partially. But it's interesting you said
this because I was thinking may be I should just take one of the .js files
and start to comment it and ask questions on the list.
I'll gladly volunteer to start with one of the .js files and follow your
suggestions and take it from there.
Thanks for pushing. Should I create an issue in JIRA or .... ?
Nitin
> Thanks,
>
> --
> Noah Slater, http://tumbolia.org/nslater
>
Re: Futon Improvements
Posted by Noah Slater <ns...@apache.org>.
On Thu, Sep 10, 2009 at 07:07:09AM -0700, Nitin Borwankar wrote:
> Having said that, it is true that the *.js libs that make up the client
> api's and tools around CouchDB could use a lot more documentation - usage of
> Couch would expand, IMHO, if these were better annotated.
It sounds like you have the knowledge and motivation needed to lead a push of
effort on this front. CouchDB is a big project, and we're all pulling in our own
directions. If you'd want to send us a few patches for this, I'm sure we could
get them included for you!
Thanks,
--
Noah Slater, http://tumbolia.org/nslater
Re: Futon Improvements
Posted by Nitin Borwankar <ni...@borwankar.com>.
I use CouchApp and jQuery a lot with CouchDB while my collaborator and boss
strictly uses the REST API via Python ( this could be any language, Python
not required as a client, or just curl from the command line )I personally
like jQuery and CouchApp has certainly made it much easier to write and
manage views, although I wish I did not have to use CouchApp just for that.
In any case CouchDB by itself does not depend on jQuery.
Having said that, it is true that the *.js libs that make up the client
api's and tools around CouchDB could use a lot more documentation - usage of
Couch would expand, IMHO, if these were better annotated.
Nitin
37% of all statistics are made up on the spot
-------------------------------------------------------------------------------------
Nitin Borwankar
nborwankar@gmail.com
On Thu, Sep 10, 2009 at 1:12 AM, Nils Breunese <n....@vpro.nl> wrote:
> cinnebar wrote:
>
> > We would like to see CouchDB independant of jquery (or even python re
>
>> CouchApp for that matter) for standalone couchapps 'out of the box'.
>>
>> Given the very excellent http request api that is a fundamental aspect of
>> CouchDB we consider that the current jquery dependancy is a major
>> deterrent
>> regarding general uptake of CouchDB.
>>
>
> I don't believe CouchDB depends on jQuery. It's there if you want to use
> it, but it's not required for anything AFAIK. CouchApp is a third party tool
> written in Python, so yeah, you need Python if you want to use CouchApp. You
> don't need to use CouchApp though, you can push design documents any way you
> like.
>
> Nils Breunese.
>
Re: Futon Improvements
Posted by cinnebar <me...@gmail.com>.
nah was a typo my apologies to you NOAH
>
Re: Futon Improvements
Posted by Matt King <sw...@gmail.com>.
Please take this discussion off-list, as I'm sure not everyone wants a
flood of flamemails clogging up their inbox.
> I would really like to know why the jQuery dependency in futon
> matters at
> all to anyone.
>
> On Thu, Sep 10, 2009 at 12:36 PM, Noah Slater <ns...@apache.org>
> wrote:
>
>> On Fri, Sep 11, 2009 at 02:27:02AM +1000, cinnebar wrote:
>>> nah + jan:
>>
>> My name is Noah.
>>
>>> o you guys are jumping in because you are defensive about your book
>>
>> This has nothing to do with our book.
>>
>> I am defensive of a project and community that I have had the
>> privilege to
>> be a
>> part of for many years now. And when someone wades in and is being
>> aggressive
>> about things not being good enough for them, and the quality and
>> type of
>> the
>> discussion not being pleasing for them, I will quickly remind them
>> how they
>> fit
>> into the ecosystem. If the documentation isn't up to your standards,
>> improve it.
>> If you're sick of all the people asking simple questions, help them
>> with
>> their
>> problems until they become experts.
>>
>> Thanks,
>>
>> --
>> Noah Slater, http://tumbolia.org/nslater
>>
Re: Futon Improvements
Posted by Nathan Stott <nr...@gmail.com>.
I would really like to know why the jQuery dependency in futon matters at
all to anyone.
On Thu, Sep 10, 2009 at 12:36 PM, Noah Slater <ns...@apache.org> wrote:
> On Fri, Sep 11, 2009 at 02:27:02AM +1000, cinnebar wrote:
> > nah + jan:
>
> My name is Noah.
>
> > o you guys are jumping in because you are defensive about your book
>
> This has nothing to do with our book.
>
> I am defensive of a project and community that I have had the privilege to
> be a
> part of for many years now. And when someone wades in and is being
> aggressive
> about things not being good enough for them, and the quality and type of
> the
> discussion not being pleasing for them, I will quickly remind them how they
> fit
> into the ecosystem. If the documentation isn't up to your standards,
> improve it.
> If you're sick of all the people asking simple questions, help them with
> their
> problems until they become experts.
>
> Thanks,
>
> --
> Noah Slater, http://tumbolia.org/nslater
>
Re: Futon Improvements
Posted by cinnebar <me...@gmail.com>.
your out of line fella. I think you better read the discussion through
carefully from the top instead of blindly taking swings.
Re: Futon Improvements
Posted by Flinn Mueller <th...@gmail.com>.
Take it outside please.
On Sep 10, 2009, at 2:20 PM, cinnebar wrote:
> You still haven't answered the simple question of why should anyone
> care
> that futon has a jQuery dependency?
>
> Jan asked a similar question in another thread and i am trying to
> answer it
> without causing another ruckus.
Re: Futon Improvements
Posted by cinnebar <me...@gmail.com>.
You still haven't answered the simple question of why should anyone care
that futon has a jQuery dependency?
Jan asked a similar question in another thread and i am trying to answer it
without causing another ruckus.
RE: Futon Improvements
Posted by "Moore, Alan BGI SF" <Al...@barclaysglobal.com>.
I see Futon as completely separate from CouchDb core - it's great for
setting things up and finding out what's going on, but in a production
use of CouchDb I'll write my own tools/ui appropriate to my application
use.
I don't really care whether it uses jQuery or not, except in the fact
that if I wanted to write my own web based ui to my application use of
CouchDb I would want to look at and learn (and contribute) to the effort
that's gone into Futon. And if it uses jQuery and produces good results
through that technique I'd be likely to use it too.
-Alan
-----Original Message-----
From: Jan Lehnardt [mailto:jan@apache.org]
Sent: Thursday, September 10, 2009 12:20 PM
To: user@couchdb.apache.org
Subject: Re: Futon Improvements
On 10 Sep 2009, at 20:12, cinnebar wrote:
> My motivation for making the comment about non jquery dependency stems
> primarily from our commitment to adopting CouchDb in out own systems
> and a desire to increase user base and therefore support and active
> development of CouchDB
Thats a great starting point. Thank you :)
Cheers
Jan
--
--
This message and any attachments are confidential, proprietary, and may be privileged. If this message was misdirected, Barclays Global Investors (BGI) does not waive any confidentiality or privilege. If you are not the intended recipient, please notify us immediately and destroy the message without disclosing its contents to anyone. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. The views and opinions expressed in this e-mail message are the author's own and may not reflect the views and opinions of BGI, unless the author is authorized by BGI to express such views or opinions on its behalf. All email sent to or from this address is subject to electronic storage and review by BGI. Although BGI operates anti-virus programs, it does not accept responsibility for any damage whatsoever caused by viruses being passed.
Re: Futon Improvements
Posted by Jan Lehnardt <ja...@apache.org>.
On 10 Sep 2009, at 20:12, cinnebar wrote:
> My motivation for making the comment about non jquery dependency stems
> primarily from our commitment to adopting CouchDb in out own systems
> and a
> desire to increase user base and therefore support and active
> development of
> CouchDB
Thats a great starting point. Thank you :)
Cheers
Jan
--
Re: Futon Improvements
Posted by cinnebar <me...@gmail.com>.
My motivation for making the comment about non jquery dependency stems
primarily from our commitment to adopting CouchDb in out own systems and a
desire to increase user base and therefore support and active development of
CouchDB
I am only interested in the tech the rest of it just seems senseless to me
Re: Futon Improvements
Posted by Nathan Stott <nr...@gmail.com>.
cinnebar, Noah is an established authority in this community. I find your
emails to be a bit disparaging as well.
You still haven't answered the simple question of why should anyone care
that futon has a jQuery dependency?
Every post you make that refers only to your squabble with Noah and to a
lesser degree Jan makes you look more like a troll and less like someone
interested in a discussion about couchdb. Please, stick to the tech and let
the rest drop and everyone will welcome you.
On Thu, Sep 10, 2009 at 1:42 PM, cinnebar <me...@gmail.com> wrote:
> i think you got something going on noah thats got little to do with this
> mailing list or what i wrote
>
> that last response is offensive and presumptuous as were a number of your
> responses in this thread
>
> i wasnt taking any jabs at the community at all despite your assertion to
> the contrary
>
> peace
>
Re: Futon Improvements
Posted by cinnebar <me...@gmail.com>.
i think you got something going on noah thats got little to do with this
mailing list or what i wrote
that last response is offensive and presumptuous as were a number of your
responses in this thread
i wasnt taking any jabs at the community at all despite your assertion to
the contrary
peace
Re: Futon Improvements
Posted by Noah Slater <ns...@apache.org>.
On Thu, Sep 10, 2009 at 05:44:13PM +0100, Noah Slater wrote:
> I invite you to reformulate them, and show me how I was mistaken.
On Fri, Sep 11, 2009 at 02:48:14AM +1000, cinnebar wrote:
> please do it yourself.
I am unable to reformulate something that you have said.
My interpretations of your communication were done in good faith, and while I do
not think that you were being intentionally antagonistic, I do feel that some of
the comments you made were a little presumptuous. Taking jabs at the mailing
list, which is an embodiment of the community, is a good example of this.
On Fri, Sep 11, 2009 at 02:44:28AM +1000, cinnebar wrote:
> your out of line fella. I think you better read the discussion through
> carefully from the top instead of blindly taking swings.
Maybe I would be if I was some random dude who's having a go at you because I
was bored. But I'm not.. As one of the community gate-keepers, it is my duty to
reinforce the behaviour and tone that we find acceptable here.
On Thu, Sep 10, 2009 at 09:47:06AM -0700, Matt King wrote:
> Please take this discussion off-list, as I'm sure not everyone wants a
> flood of flamemails clogging up their inbox.
I do not want this to spiral into some huge meta-thread about who did what, and
who's upset who. I think we would all find that very boring. But proper list
conduct is a public concern, and I think that is helpful to keep these things in
the open so we can all learn from them.
On Fri, Sep 11, 2009 at 03:01:27AM +1000, cinnebar wrote:
> look i just wasnt being aggressive about anything
I don't think you were being intentionally aggressive. But this email itself is
an example of how you might be sending out the wrong signals. While you are free
to choose whatever style you wish for your communication, sending poorly worded
emails without proper capitalisation and sweeping personal comments will make a
lot of people think that you have not properly thought about your response. And
when you combine that with negative comments about the community and the code,
it is easy to see why people might get upset.
I would like this thread to die now.
Thanks,
--
Noah Slater, http://tumbolia.org/nslater
Re: Futon Improvements
Posted by cinnebar <me...@gmail.com>.
look i just wasnt being aggressive about anything
problem oriented development is not the only option
i personally dont need the documentation i mentioned
the discussion was about developing Futon
Re: Futon Improvements
Posted by Jan Lehnardt <ja...@apache.org>.
On 10 Sep 2009, at 18:36, Noah Slater wrote:
>> o you guys are jumping in because you are defensive about your book
>
> This has nothing to do with our book.
>
> I am defensive of a project and community that I have had the
> privilege to be a
> part of for many years now. And when someone wades in and is being
> aggressive
> about things not being good enough for them, and the quality and
> type of the
> discussion not being pleasing for them, I will quickly remind them
> how they fit
> into the ecosystem. If the documentation isn't up to your standards,
> improve it.
> If you're sick of all the people asking simple questions, help them
> with their
> problems until they become experts.
+1.
Cheers
Jan
--
Re: Futon Improvements
Posted by Noah Slater <ns...@apache.org>.
On Fri, Sep 11, 2009 at 02:27:02AM +1000, cinnebar wrote:
> nah + jan:
My name is Noah.
> o you guys are jumping in because you are defensive about your book
This has nothing to do with our book.
I am defensive of a project and community that I have had the privilege to be a
part of for many years now. And when someone wades in and is being aggressive
about things not being good enough for them, and the quality and type of the
discussion not being pleasing for them, I will quickly remind them how they fit
into the ecosystem. If the documentation isn't up to your standards, improve it.
If you're sick of all the people asking simple questions, help them with their
problems until they become experts.
Thanks,
--
Noah Slater, http://tumbolia.org/nslater
Re: Futon Improvements
Posted by cinnebar <me...@gmail.com>.
nah + jan:
o you guys are jumping in because you are defensive about your book
i think you have been asked to start a new discussion if thats what you want
to discuss
cheers
Re: Futon Improvements
Posted by Noah Slater <ns...@apache.org>.
On Fri, Sep 11, 2009 at 02:19:41AM +1000, cinnebar wrote:
> want there some kind of sanction against unhelpful snide responses?
There was nothing snide about my response. I believe the tone of my email
appropriately matched the tone of yours. I think I made some good points and I
would like to see you address before the conversation moves on.
Thanks,
--
Noah Slater, http://tumbolia.org/nslater
Re: Futon Improvements
Posted by cinnebar <me...@gmail.com>.
want there some kind of sanction against unhelpful snide responses?
> --
> Noah Slater, http://tumbolia.org/nslater
>
Re: forking threads (Was: Re: Futon Improvements, Should be:
jQuery dependency)
Posted by Noah Slater <ns...@apache.org>.
On Thu, Sep 10, 2009 at 07:58:16PM +0100, Noah Slater wrote:
> Let me rephrase that as, you'll behave according to our community mores, and
> when you don't you will be reminded that you should, and if you continue, you'll
> be forcibly removed from the community. Pretty simple, and reasonable.
It has been pointed out to me that this could be taken in the wrong way.
Theoretically, this is how things would work. I don't think it's going to happen
like this, and in fact, it never has. I certainly wasn't suggesting that it's
anywhere near as bad as this right now! But that is how we should all expect
things to ultimately work. We need to pull together as a community, and people
who push against that should be corrected as appropriate. In general.
Best,
--
Noah Slater, http://tumbolia.org/nslater
Re: forking threads (Was: Re: Futon Improvements, Should be:
jQuery dependency)
Posted by Noah Slater <ns...@apache.org>.
On Fri, Sep 11, 2009 at 04:09:29AM +1000, cinnebar wrote:
> Stifling user discussion in open source communities is really really bad
> practice Ive never been assaulted by thugs online before
I don't need schooling on community and you're not being silenced.
I'm asking you to stop because this thread is boring. I've already told you that
I didn't like your tone, and you've told me that you don't like my tone, and
nothing seems to have changed. But that's cool. We don't need to keep reminding
each other how we feel. I don't think we need to talk about it any more.
> So to get things straight: the community structure is something like do it
> our way or we will bully you then tell you to be quiet?
Pretty much.
Let me rephrase that as, you'll behave according to our community mores, and
when you don't you will be reminded that you should, and if you continue, you'll
be forcibly removed from the community. Pretty simple, and reasonable.
Best,
--
Noah Slater, http://tumbolia.org/nslater
Re: forking threads (Was: Re: Futon Improvements, Should be: jQuery
dependency)
Posted by cinnebar <me...@gmail.com>.
Noah:
Stifling user discussion in open source communities is really really bad
practice
Ive never been assaulted by thugs online before
So to get things straight: the community structure is something like do it
our way or we will bully you then tell you to be quiet?
Re: forking threads (Was: Re: Futon Improvements, Should be:
jQuery dependency)
Posted by Noah Slater <ns...@apache.org>.
On Fri, Sep 11, 2009 at 03:46:48AM +1000, cinnebar wrote:
> in the context of the thread this was pulled from how can you think it is
> not offensive and disrespectful?
Stop now.
--
Noah Slater, http://tumbolia.org/nslater
Re: forking threads (Was: Re: Futon Improvements, Should be: jQuery
dependency)
Posted by cinnebar <me...@gmail.com>.
> I am defensive of a project and community that I have had the privilege to
be a
> part of for many years now. And when someone wades in and is being
aggressive
> about things not being good enough for them, and the quality and type of
the
> discussion not being pleasing for them, I will quickly remind them how
they fit
> into the ecosystem. If the documentation isn't up to your standards,
improve it.
> If you're sick of all the people asking simple questions, help them with
their
> problems until they become experts.
in the context of the thread this was pulled from how can you think it is
not offensive and disrespectful?
Re: forking threads (Was: Re: Futon Improvements, Should be: jQuery dependency)
Posted by Jan Lehnardt <ja...@apache.org>.
On 10 Sep 2009, at 18:42, cinnebar wrote:
> If you read the Futon improvements thread carefully from the top you
> my
> understand that your reply to my comment appeared rude in the
> context of the
> discussion. You and Jan seem to have missed the points I was making
> almost
> entirely.
>
> I sure didnt mean any disrespect and I dont expect any from you.
I hope my last mail made clear that I am furthest from any disrespect
to anyone in this community.
Cheers
Jan
--
Re: forking threads (Was: Re: Futon Improvements, Should be: jQuery
dependency)
Posted by cinnebar <me...@gmail.com>.
please do it yourself.
Re: forking threads (Was: Re: Futon Improvements, Should be:
jQuery dependency)
Posted by Noah Slater <ns...@apache.org>.
On Fri, Sep 11, 2009 at 02:42:03AM +1000, cinnebar wrote:
> If you read the Futon improvements thread carefully from the top you my
> understand that your reply to my comment appeared rude in the context of the
> discussion. You and Jan seem to have missed the points I was making almost
> entirely.
I invite you to reformulate them, and show me how I was mistaken.
--
Noah Slater, http://tumbolia.org/nslater
Re: forking threads (Was: Re: Futon Improvements, Should be: jQuery
dependency)
Posted by cinnebar <me...@gmail.com>.
If you read the Futon improvements thread carefully from the top you my
understand that your reply to my comment appeared rude in the context of the
discussion. You and Jan seem to have missed the points I was making almost
entirely.
I sure didnt mean any disrespect and I dont expect any from you.
cheers
Re: forking threads (Was: Re: Futon Improvements, Should be:
jQuery dependency)
Posted by Noah Slater <ns...@apache.org>.
On Thu, Sep 10, 2009 at 06:23:44PM +0200, Jan Lehnardt wrote:
> Forking threads is a common practice, we should allow for calls to thread forks.
I'll fork YOUR thread.
--
Noah Slater, http://tumbolia.org/nslater
forking threads (Was: Re: Futon Improvements, Should be: jQuery dependency)
Posted by Jan Lehnardt <ja...@apache.org>.
On 10 Sep 2009, at 18:17, Noah Slater wrote:
> On Thu, Sep 10, 2009 at 11:15:18AM -0500, Zachary Zolton wrote:
>> Please move discussion of the appropriateness of using jQuery to
>> another thread. Here we should be discussing features and
>> improvements
>> to Futon.
>
> Excuse me?
Forking threads is a common practice, we should allow for calls to
thread
forks.
Cheers
Jan
--
Re: Futon Improvements
Posted by Noah Slater <ns...@apache.org>.
On Thu, Sep 10, 2009 at 11:15:18AM -0500, Zachary Zolton wrote:
> Please move discussion of the appropriateness of using jQuery to
> another thread. Here we should be discussing features and improvements
> to Futon.
Excuse me?
--
Noah Slater, http://tumbolia.org/nslater
Re: Futon Improvements
Posted by Zachary Zolton <za...@gmail.com>.
Please move discussion of the appropriateness of using jQuery to
another thread. Here we should be discussing features and improvements
to Futon.
On Thu, Sep 10, 2009 at 11:10 AM, Noah Slater<ns...@apache.org> wrote:
> On Fri, Sep 11, 2009 at 02:04:25AM +1000, cinnebar wrote:
>> > I don't believe CouchDB depends on jQuery.
>>
>> > In any case CouchDB by itself does not depend on jQuery.
>>
>> Perhaps I didnt explain my point well. I mentioned jquery dependency in the
>> context of 'Futon improvements'. Futon is the 'in box' app for accessing
>> CouchDB in browser and is dependent on jquery.
>
> So what?
>
>> Beyond this we think that the effect of better documenting at least the js
>> included with CouchDB on installation would be greatly increased usability of
>> CouchDB. We do not have this opinion because we are stupid or because we do
>> not understand the code.
>
> How would this objectively improve usability?
>
>> I myself would welcome the demonstration of an alternative version of Futon
>> from either of you that does not require jquery and is as good as or more
>> full featured than the Futon that we have .
>
> Why on earth does it matter what JavaScript libraries Futon uses?
>
>> At the moment the feature set of Futon is far from useful for the level of
>> dev that we are already at.
>
> Patches welcome then.
>
>> I mentioned CouchApp only in passing and i realise its dependencies are not
>> really relevant to this discussion but it does seem odd to me that the demo
>> 'standalone couchapp' in couchdb documentation is 'out of the box' dependent
>> on a python module.
>
> How else would you do it? Bash scripts and curl statements?
>
> If you're going to be working with CouchDB, you need to do HTTP, and if you're
> going to do that in a way that doesn't involve using telnet, you need to use a
> library, so that means a language. I'd love to see your other suggestion.
>
>> At the same time personally i like using py and i like
>> using js so calling the CouchApp py module a 'third party tool' in the
>> context doesnt seem to make too much sense.
>
> The whole of CouchApp is third party.
>
>> ...development of CouchDB will also be aided if this user mailing list
>> involved a higher % of informed discussion and lower % 'o crap i cant it to
>> work'
>
> Development of CouchDB or development with CouchDB?
>
> And what makes you think that your particular needs are more important?
>
> Thanks,
>
> --
> Noah Slater, http://tumbolia.org/nslater
>
Re: Futon Improvements
Posted by Noah Slater <ns...@apache.org>.
On Fri, Sep 11, 2009 at 02:04:25AM +1000, cinnebar wrote:
> > I don't believe CouchDB depends on jQuery.
>
> > In any case CouchDB by itself does not depend on jQuery.
>
> Perhaps I didnt explain my point well. I mentioned jquery dependency in the
> context of 'Futon improvements'. Futon is the 'in box' app for accessing
> CouchDB in browser and is dependent on jquery.
So what?
> Beyond this we think that the effect of better documenting at least the js
> included with CouchDB on installation would be greatly increased usability of
> CouchDB. We do not have this opinion because we are stupid or because we do
> not understand the code.
How would this objectively improve usability?
> I myself would welcome the demonstration of an alternative version of Futon
> from either of you that does not require jquery and is as good as or more
> full featured than the Futon that we have .
Why on earth does it matter what JavaScript libraries Futon uses?
> At the moment the feature set of Futon is far from useful for the level of
> dev that we are already at.
Patches welcome then.
> I mentioned CouchApp only in passing and i realise its dependencies are not
> really relevant to this discussion but it does seem odd to me that the demo
> 'standalone couchapp' in couchdb documentation is 'out of the box' dependent
> on a python module.
How else would you do it? Bash scripts and curl statements?
If you're going to be working with CouchDB, you need to do HTTP, and if you're
going to do that in a way that doesn't involve using telnet, you need to use a
library, so that means a language. I'd love to see your other suggestion.
> At the same time personally i like using py and i like
> using js so calling the CouchApp py module a 'third party tool' in the
> context doesnt seem to make too much sense.
The whole of CouchApp is third party.
> ...development of CouchDB will also be aided if this user mailing list
> involved a higher % of informed discussion and lower % 'o crap i cant it to
> work'
Development of CouchDB or development with CouchDB?
And what makes you think that your particular needs are more important?
Thanks,
--
Noah Slater, http://tumbolia.org/nslater
Re: Futon Improvements
Posted by Jan Lehnardt <ja...@apache.org>.
Hi cinnebar,
On 10 Sep 2009, at 18:04, cinnebar wrote:
>> I don't believe CouchDB depends on jQuery.
>
>> In any case CouchDB by itself does not depend on jQuery.
>
> Perhaps I didnt explain my point well. I mentioned jquery
> dependency in the
> context of 'Futon improvements'. Futon is the 'in box' app for
> accessing
> CouchDB in browser and is dependent on jquery.
Futon wouldn't be what it is today without jQuery. But I'm happy to
consider alternatives.
> Beyond this we think that
> the effect of better documenting at least the js included with
> CouchDB on
> installation would be greatly increased usability of CouchDB. We do
> not
> have this opinion because we are stupid or because we do not
> understand the
> code.
Nobody said you're stupid :)
> I myself would welcome the demonstration of an alternative version
> of Futon
> from either of you that does not require jquery and is as good as or
> more
> full featured than the Futon that we have .
>
>> jQuery and CouchApp are much easier to write
>
> The addition of the features mentioned by Paul in the jquery
> dependent Futon
> would be good to see too.
>
> At the moment the feature set of Futon is far from useful for the
> level of
> dev that we are already at.
We're happy to consider any patches you might have for Futon. This is
all voluntary work, please appreciate this, see below.
>> CouchApp is a third party tool
>> You don't need to use CouchApp though, you can push design
>> documents any
> way you like.
>
> I mentioned CouchApp only in passing and i realise its dependencies
> are not
> really relevant to this discussion but it does seem odd to me that
> the demo
> 'standalone couchapp' in couchdb documentation is 'out of the box'
> dependent
> on a python module. At the same time personally i like using py and
> i like
> using js so calling the CouchApp py module a 'third party tool' in the
> context doesnt seem to make too much sense.
CouchDB is an Open Source project in alpha stage driven by voluntary
contributions. While we're very keen on hearing about areas that need
improvement there is no obligation to focus on anything an individual
developer doesn't fancy. The best way to raise awareness for a feature
request (I consider documentation a feature :) is opening an issue in
our bug tracker: https://issues.apache.org/jira/browse/COUCHDB (sorry,
it's JIRA).
As far as picking a Python dependency for the book, here's our
reasoning:
Pick a framework where we can focus on CouchDB, not the framework.
We decided that Rails, Django and the others are too heavyweight for
what we want to show. We opted for a pure JavaScript application.
The couchapp tool helps developing these but CouchApps per se are
not dependent on any particular tool. Other's have written their own
version.
Besides, our CouchDB book is not the official CouchDB documentation
nor is the couchapp project part of CouchDB (yet).
(I'm aware that it is all a bit in flux all the time, but that's the
nature of
an alpha-stage software)
> ...development of CouchDB will also be aided if this user mailing list
> involved a higher % of informed discussion and lower % 'o crap i
> cant it to
> work'
If people have problems installing, and there are a lot of potential
issues,
they should be encouraged to come here and look for help, even if all
they
receive is a friendly pointer to the archives or FaQ. I hope you can
skim
messages fast enough to just skip the mails you don't want to read or
you
can set up a filter for "problem installing" or similar.
Cheers
Jan
--
Re: Futon Improvements
Posted by cinnebar <me...@gmail.com>.
> I don't believe CouchDB depends on jQuery.
> In any case CouchDB by itself does not depend on jQuery.
Perhaps I didnt explain my point well. I mentioned jquery dependency in the
context of 'Futon improvements'. Futon is the 'in box' app for accessing
CouchDB in browser and is dependent on jquery. Beyond this we think that
the effect of better documenting at least the js included with CouchDB on
installation would be greatly increased usability of CouchDB. We do not
have this opinion because we are stupid or because we do not understand the
code.
I myself would welcome the demonstration of an alternative version of Futon
from either of you that does not require jquery and is as good as or more
full featured than the Futon that we have .
> jQuery and CouchApp are much easier to write
The addition of the features mentioned by Paul in the jquery dependent Futon
would be good to see too.
At the moment the feature set of Futon is far from useful for the level of
dev that we are already at.
> CouchApp is a third party tool
> You don't need to use CouchApp though, you can push design documents any
way you like.
I mentioned CouchApp only in passing and i realise its dependencies are not
really relevant to this discussion but it does seem odd to me that the demo
'standalone couchapp' in couchdb documentation is 'out of the box' dependent
on a python module. At the same time personally i like using py and i like
using js so calling the CouchApp py module a 'third party tool' in the
context doesnt seem to make too much sense.
...development of CouchDB will also be aided if this user mailing list
involved a higher % of informed discussion and lower % 'o crap i cant it to
work'
cheers
Re: Futon Improvements
Posted by Nils Breunese <n....@vpro.nl>.
cinnebar wrote:
> We would like to see CouchDB independant of jquery (or even python re
> CouchApp for that matter) for standalone couchapps 'out of the box'.
>
> Given the very excellent http request api that is a fundamental aspect of
> CouchDB we consider that the current jquery dependancy is a major deterrent
> regarding general uptake of CouchDB.
I don't believe CouchDB depends on jQuery. It's there if you want to use
it, but it's not required for anything AFAIK. CouchApp is a third party
tool written in Python, so yeah, you need Python if you want to use
CouchApp. You don't need to use CouchApp though, you can push design
documents any way you like.
Nils Breunese.
Re: Futon Improvements
Posted by cinnebar <me...@gmail.com>.
I am working with a group on a full featured ERP that proposes to
index/store data AND scripts in one or multiple json db files, perhaps
outputting function sets from json document/s to .js (for example) file/s
serverside maybe in a cache folder though perhaps clientside concates or an
array function will be adequate for most use cases. For a number of reasons
and although it is still infant we consider that CouchDB is the best
candidate for serverside handling of the json docs at the moment.
We would like to see CouchDB independant of jquery (or even python re
CouchApp for that matter) for standalone couchapps 'out of the box'.
Given the very excellent http request api that is a fundamental aspect of
CouchDB we consider that the current jquery dependancy is a major deterrent
regarding general uptake of CouchDB.
While the jquery dependency still stands we consider that the dev rate of
futon and more generally other standalone couchapps will be increased
dramatically with detailed documentation (commented or otherwise) of the
jquery.couch.js and other 'in box' jquery[].js files with a simple list of
function dependancies regards to jquery.js and perhaps documentation of
those functions too. Perhaps the fastest way for this to proceed would be
for the author of jquery.couch.js to provide some explanation in order to
augment general documentation of 'in box' CouchDB components.
As yet no time to look through the test suite for specifically jquery
dependancies and documentation would be helpful here too.
Of course there is the couch.js providing SJAX methods if required but AJAX
is 'the shit' (or AJAJ as is more exact in this case - hehe) and perhaps it
could be included in a 'COUCH' object namespace. We are working with an
'EOS' object at the moment but this may change.
Re: Futon Improvements
Posted by Nitin Borwankar <ni...@borwankar.com>.
Hi Paul,
Re: formatting of JSON strings in general there have been some discussions
at my "day job" where we are working on a JSON rendering of BibTeX data
(currently called BibJSON by us).
The annoying issue that comes up for us in human interactions with a JSON
string (i.e. when JSON is in a disk file or on the screen, rather than being
munged by a browser) is that it is one interminably long string as there are
no \n's for pretty printing.
So the BibJSON spec is considering doing something drastic ( there is
understandable opposition to this and I am on the fence) such as insisting
that
serialized BibJSON be formatted as
[
{...},
{...},
{...}
]
where there is an implicit \n after each of '[' ']' and '}' and after every
',' so that it renders as above.
Aside from visual rendering this way this approach is also useful when doing
some thing like 'head' or 'grep' on a file containing JSON.
Ever try doing that on a '\n' less JSON file that is a few 10's of MB?
For the uninitiated it gives you the whole friggin' file as a response to
'head' or 'grep' which is useless.
BTW the above serialization with superfluous \n's, validates just fine in
Doug Crockford's JSLint service http://jslint.com (note: 'jslint will hurt
your feelings' (TM) )
So aside from how Futon handles JSON strings I would suggest some thought to
the value of
a) a convention of adding \n's for human friendliness (even if just in
files, in a couchapp tree)
b) adding two methods to CouchDB's built in JS libraries that pretty-up and,
well, ugly-up a JSON string.
c) adding two methods that resp. replace \n with <p> and v.v in "JSON"
strings
This JSON string infrastructure support will make life much easier in Futon,
couchapp and other places where humans need to see/poke/prod JSON while
working with CocuhDB.
Aside from this, for Futon specific things, I would like to add my +1 to the
need for displaying/editing just one view function when you click on it
rather than all of them all at once in one large bowl of insufferable JSON
stringy noodle soup that is served up right now. I don't like JSON noodle
soup. Dear Abby, am I the only one?
Thanks much,
Nitin
37% of all statistics are made up on the spot
-------------------------------------------------------------------------------------
Nitin Borwankar
nborwankar@gmail.com
On Wed, Sep 9, 2009 at 1:20 PM, Paul Davis <pa...@gmail.com>wrote:
> Hey everyone,
>
> So I'm at a bit of an impasse. I've got a couple ideas for how to give
> Futon an extra bit of polish but I have no AJAX-fu. I thought I'd just
> throw out some ideas and see if anyone wanted to try implementing
> them. So, in no particular order:
>
> * Editing design doc functions. The current view editors are awesome
> for a "create design doc" work flow, but there's a bit of a disconnect
> when you want to edit an existing function. When viewing a design doc,
> an edit link that would load that view in the editor would be cool.
>
> * Displaying functions in the Fields tab. It'd be nice to see if we
> can make functions formatted a bit more nicely than just a plain
> string as they are now. I'm not sure how well this would look, but
> some smarts couldn't hurt.
>
> * Closely related to the previous point is truncating large strings in
> the fields tab. There's a source tab now so we can just let people
> click that if they're wanting to see something all gigantic.
>
> * Editing show/list functions. This is a big one, but something
> similar to the view editor would be nice for editing lists and shows.
> With similar edit links as above. I'm thinking that where we have view
> rows output, we could just put up the view response as plain text and
> then use the "raw view" button as a link to the live page.
>
> * Simple syntax checking before doing a save or run of functions.
> Throw an error if you can't compile the function locally. This could
> be combined with the next idea.
>
> * Function testing. This has been brought up before, but an
> interesting thing to look into for editing views and lists would be to
> have the browser fetch some subset of the db for testing. I'm not sure
> on the best way to do this right now as it could be domain specific.
> I'm thinking something like, create a filter function that can run
> over _changes or a view and will select just some of the docs. Ideally
> this would replace temporary views completely.
>
> * Frickin tab support in the function editing boxes.
>
> * Delete Test Suite DB's - A button on the test suite page that will
> clean out the test suite db's. I tend to be OCD and going through and
> deleting the test suite dbs gets old.
>
> * Test editing - When you click a test name the browser opens a new
> window showing the source code of that test. If we instead opened a
> new tab that had the function source loaded into the custom test
> editor that'd be cool.
>
> * A selectable group_level or group=false on the view pages. And we
> should probably change the default output in futon to a single row as
> that's a constant confusion factor for new people.
>
> * Create/Delete config section/key/value triplets.
>
> * Raw view buttons for the config and status pages
>
> * Remember the Fields/Source tab preference
>
> * Another thing I'm just noting with the rest is that an interface for
> setting up continuous replication is needed. Adam's still working on
> some of the mechanics that will be required in the end, but some sort
> of trigger for the existing functionality would be good.
>
> * View compaction button.
>
> * View info view (err, view of the info about a view)
>
> That's all I can think of right now.
>
> In terms of implementation, I'd take the well known URL approach.
> Treat things on _design docs that are supposed to be functions as
> functions and everything else is a string.
>
> Also, I'm not completely helpless here. If you're a webdev and have
> been discouraged by the requirement of needing to build all of CouchDB
> just to have a decent environment for editing some html and
> javascript, let me know and I'll put together a small script so you
> can run a local web server to hack on those pages more easily. The
> basic work flow could then just be to svn co the share/www directory
> and then point the server at it (assuming a running couchdb instance).
> Just let me know if you're interested and I can cook that up pretty
> quick.
>
> Thanks,
> Paul Davis
>
> p.s. I double posted to include user@ to cast as wide of a net as
> possible. If you're not on dev@ I invite you to join up and continue
> this discussion there.
>
Re: Futon Improvements
Posted by Nitin Borwankar <ni...@borwankar.com>.
Hi Paul,
Re: formatting of JSON strings in general there have been some discussions
at my "day job" where we are working on a JSON rendering of BibTeX data
(currently called BibJSON by us).
The annoying issue that comes up for us in human interactions with a JSON
string (i.e. when JSON is in a disk file or on the screen, rather than being
munged by a browser) is that it is one interminably long string as there are
no \n's for pretty printing.
So the BibJSON spec is considering doing something drastic ( there is
understandable opposition to this and I am on the fence) such as insisting
that
serialized BibJSON be formatted as
[
{...},
{...},
{...}
]
where there is an implicit \n after each of '[' ']' and '}' and after every
',' so that it renders as above.
Aside from visual rendering this way this approach is also useful when doing
some thing like 'head' or 'grep' on a file containing JSON.
Ever try doing that on a '\n' less JSON file that is a few 10's of MB?
For the uninitiated it gives you the whole friggin' file as a response to
'head' or 'grep' which is useless.
BTW the above serialization with superfluous \n's, validates just fine in
Doug Crockford's JSLint service http://jslint.com (note: 'jslint will hurt
your feelings' (TM) )
So aside from how Futon handles JSON strings I would suggest some thought to
the value of
a) a convention of adding \n's for human friendliness (even if just in
files, in a couchapp tree)
b) adding two methods to CouchDB's built in JS libraries that pretty-up and,
well, ugly-up a JSON string.
c) adding two methods that resp. replace \n with <p> and v.v in "JSON"
strings
This JSON string infrastructure support will make life much easier in Futon,
couchapp and other places where humans need to see/poke/prod JSON while
working with CocuhDB.
Aside from this, for Futon specific things, I would like to add my +1 to the
need for displaying/editing just one view function when you click on it
rather than all of them all at once in one large bowl of insufferable JSON
stringy noodle soup that is served up right now. I don't like JSON noodle
soup. Dear Abby, am I the only one?
Thanks much,
Nitin
37% of all statistics are made up on the spot
-------------------------------------------------------------------------------------
Nitin Borwankar
nborwankar@gmail.com
On Wed, Sep 9, 2009 at 1:20 PM, Paul Davis <pa...@gmail.com>wrote:
> Hey everyone,
>
> So I'm at a bit of an impasse. I've got a couple ideas for how to give
> Futon an extra bit of polish but I have no AJAX-fu. I thought I'd just
> throw out some ideas and see if anyone wanted to try implementing
> them. So, in no particular order:
>
> * Editing design doc functions. The current view editors are awesome
> for a "create design doc" work flow, but there's a bit of a disconnect
> when you want to edit an existing function. When viewing a design doc,
> an edit link that would load that view in the editor would be cool.
>
> * Displaying functions in the Fields tab. It'd be nice to see if we
> can make functions formatted a bit more nicely than just a plain
> string as they are now. I'm not sure how well this would look, but
> some smarts couldn't hurt.
>
> * Closely related to the previous point is truncating large strings in
> the fields tab. There's a source tab now so we can just let people
> click that if they're wanting to see something all gigantic.
>
> * Editing show/list functions. This is a big one, but something
> similar to the view editor would be nice for editing lists and shows.
> With similar edit links as above. I'm thinking that where we have view
> rows output, we could just put up the view response as plain text and
> then use the "raw view" button as a link to the live page.
>
> * Simple syntax checking before doing a save or run of functions.
> Throw an error if you can't compile the function locally. This could
> be combined with the next idea.
>
> * Function testing. This has been brought up before, but an
> interesting thing to look into for editing views and lists would be to
> have the browser fetch some subset of the db for testing. I'm not sure
> on the best way to do this right now as it could be domain specific.
> I'm thinking something like, create a filter function that can run
> over _changes or a view and will select just some of the docs. Ideally
> this would replace temporary views completely.
>
> * Frickin tab support in the function editing boxes.
>
> * Delete Test Suite DB's - A button on the test suite page that will
> clean out the test suite db's. I tend to be OCD and going through and
> deleting the test suite dbs gets old.
>
> * Test editing - When you click a test name the browser opens a new
> window showing the source code of that test. If we instead opened a
> new tab that had the function source loaded into the custom test
> editor that'd be cool.
>
> * A selectable group_level or group=false on the view pages. And we
> should probably change the default output in futon to a single row as
> that's a constant confusion factor for new people.
>
> * Create/Delete config section/key/value triplets.
>
> * Raw view buttons for the config and status pages
>
> * Remember the Fields/Source tab preference
>
> * Another thing I'm just noting with the rest is that an interface for
> setting up continuous replication is needed. Adam's still working on
> some of the mechanics that will be required in the end, but some sort
> of trigger for the existing functionality would be good.
>
> * View compaction button.
>
> * View info view (err, view of the info about a view)
>
> That's all I can think of right now.
>
> In terms of implementation, I'd take the well known URL approach.
> Treat things on _design docs that are supposed to be functions as
> functions and everything else is a string.
>
> Also, I'm not completely helpless here. If you're a webdev and have
> been discouraged by the requirement of needing to build all of CouchDB
> just to have a decent environment for editing some html and
> javascript, let me know and I'll put together a small script so you
> can run a local web server to hack on those pages more easily. The
> basic work flow could then just be to svn co the share/www directory
> and then point the server at it (assuming a running couchdb instance).
> Just let me know if you're interested and I can cook that up pretty
> quick.
>
> Thanks,
> Paul Davis
>
> p.s. I double posted to include user@ to cast as wide of a net as
> possible. If you're not on dev@ I invite you to join up and continue
> this discussion there.
>
Re: Futon Improvements
Posted by Paul Davis <pa...@gmail.com>.
Chris,
>> * Displaying functions in the Fields tab. It'd be nice to see if we
>> can make functions formatted a bit more nicely than just a plain
>> string as they are now. I'm not sure how well this would look, but
>> some smarts couldn't hurt.
>
> This is part of a general frustration I have with using Futon to read or
> even edit large strings, be they functions or blog post content or whatever.
> Futon just uses the raw JSON encoding, which means you get \n instead of
> line breaks, you need to escape double quote characters in the content, etc.
>
> It'd be nice if we could just view and edit strings as text, but then the
> problem is: how do you enter non-string types (e.g. numbers or booleans)?
> We'd probably need a separate type selector of some kind, and I haven't yet
> had any bright idea on how to make that elegant and sufficiently efficient.
> An other option would be to treat anything that isn't parseable as JSON as a
> string, but then you'd need to enter "42" or "true" (with the quotes) to
> force a JSON parseable value to a string. Hmm. Might work though.
I didn't have a specific vision when I considered this, just the
common frustration. Though running off your idea, I think something
that could be plausible might be like:
Adding new values keeps the current behavior
Editing an existing string value would do magic to json decode the
value and put it in a text box if it had newlines, or a plain text
field otherwise
Editing other types is the same
As to viewing, detect if the value is a string and 'make it pretty' is
about all I can come up with. Using a <pre> around it to preserve the
new lines, maybe trimming to the first N characters or similar.
>> * Simple syntax checking before doing a save or run of functions.
>> Throw an error if you can't compile the function locally. This could
>> be combined with the next idea.
>
> I tried that at one point, but (a) it only works for Javascript views, and
> (b) it only works when the Javascript interpreter in the browser actually
> supports the features you're using in the view code. So you'd be getting
> pretty bad results when using E4X or some of the SpiderMonkey extensions not
> in the ECMAScript 3 standard. It'd be a dismissable warning at best, and
> that would be pretty annoying for people using such extensions. [I get these
> kind of erroneuos warnings for stuff *I know is perfectly fine* from
> VisualStudio all the time during working hours. Very annoying]
>
> I think it'd be *way* better if CouchDB itself had a way to report actual
> syntax/compilation errors in view (or other) code. Futon could use that and
> relay any error messages to the user. Better runtime view error reporting
> would be nice, too.
Touché. Reporting errors encountered during the view build would also
improve the experience for all users of the view.
Thoughts that come to mind would be to add a "status": ("error" |
"ok") to view output and then a secondary endpoint that you could use
to retrieve the actual error. Candidates for info might be the number
and types of errors, first docid where those errors occurred, etc etc.
I don't think I'd want to keep all the tracebacks for errors, maybe
one for each type or something.
>> * Function testing. This has been brought up before, but an
>> interesting thing to look into for editing views and lists would be to
>> have the browser fetch some subset of the db for testing. I'm not sure
>> on the best way to do this right now as it could be domain specific.
>> I'm thinking something like, create a filter function that can run
>> over _changes or a view and will select just some of the docs. Ideally
>> this would replace temporary views completely.
>
> I'm not sure I like this idea. IMO its value is limited because you're not
> testing the real thing.
I must admit that my real motivation is to delete all of the
_temp_view code. I understand the desire to provide a quick
learning/dev/testing tool I just wish we could find a decent way to
provide that without _temp_views. This was just one of the more
reasonable ways to remove the _temp_view dependence. The other one
that I remember was to have _temp_view create a _design/$(UUID)
document that had a '"futon": true' member which would allow for a
button that said "Delete Temporary Design Docs". Now that we have
index files by hash, this would also allow for "Done developing, save
as real view" and there'd be no need to recalculate.
>> * Frickin tab support in the function editing boxes.
>
> Would that insert tabs or spaces? And what indentation level should be used?
> :P J/K
>
7 apostrophes would be fine as long as focus doesn't leave the text
area I'm looking at. :)
> Seriously, that would be nice. And it should be pretty darn simple to
> implement. Where's the JIRA issue? ;)
>
>> * Delete Test Suite DB's - A button on the test suite page that will
>> clean out the test suite db's. I tend to be OCD and going through and
>> deleting the test suite dbs gets old.
>
> How would Futon know which databases can be deleted? The tests would
> probably need to register any disposable databases they create for testing.
I was thinking that we either just use well known names and delete
those or register the databases. Technically registering would be
cleaner, but tagging the db and then iterating an unbounded number of
db's seems like it could get weird.
>> * Test editing - When you click a test name the browser opens a new
>> window showing the source code of that test. If we instead opened a
>> new tab that had the function source loaded into the custom test
>> editor that'd be cool.
>
> Great idea. Shouldn't be hard, either.
>
>> * A selectable group_level or group=false on the view pages. And we
>> should probably change the default output in futon to a single row as
>> that's a constant confusion factor for new people.
>
> I'd love this but simply haven't figured out a nice way to get this into the
> UI. Ideas welcome! (but for a *nice* way, not *some* way ;)
I was thinking a drop down next to run with values of
True/False/Level. When Level is selected, dynamically show a small
text field that accepts only integers.
>> * Create/Delete config section/key/value triplets.
>
> Yes please :) Definitely not easy, though.
>
>> * Raw view buttons for the config and status pages
>
> Would be nice, and simple.
>
>> * Remember the Fields/Source tab preference
>
> Ditto. I actually thought we had that already. Hmm.
>
>> * Another thing I'm just noting with the rest is that an interface for
>> setting up continuous replication is needed. Adam's still working on
>> some of the mechanics that will be required in the end, but some sort
>> of trigger for the existing functionality would be good.
>
> I haven't followed this development close enough to comment.
>
>> * View compaction button.
>>
>> * View info view (err, view of the info about a view)
>
> Like what info?
>
A URL like:
http://127.0.0.1:5984/test_suite_db/_design/test2/_info
Gives:
{
"name":"test2",
"view_index":{
"signature":"f740096892b522e24d9088cab46e0860",
"language":"javascript",
"disk_size":4185,
"compact_running":false
}
}
> Ideally, the JS source files would be extensively commented, but then
> minified during the installation process (for example using the yui
> compressor, if enabled and installed). I don't know if we could get that to
> work, or how hard it would be. Certainly would be nice. We could also
> compress jquery/json2/etc in that case, which are currently included in
> their uncompressed form (which is uncomfortably large). Maybe we could even
> concat a couple of the scripts to reduce the number of requests needed in
> Futon.
>
> Alternatively, we could document the JS files out-of-band, such as on a set
> of Wiki pages, or in text files in the repository. But the very real risk
> here is that the docs will quickly get out of date as people change the code
> but forget to update the docs.
>
> Thoughts?
My vote is for inline docs that get removed during a compression step
in the build process. OOB docs are always out of date, and incorrect
docs are worse than no docs as they say.
> Cheers,
> --
> Christopher Lenz
> cmlenz at gmx.de
> http://www.cmlenz.net/
>
>
Paul Davis
Re: Futon Improvements
Posted by Christopher Lenz <cm...@gmx.de>.
On 09.09.2009, at 22:20, Paul Davis wrote:
> * Editing design doc functions. The current view editors are awesome
> for a "create design doc" work flow, but there's a bit of a disconnect
> when you want to edit an existing function. When viewing a design doc,
> an edit link that would load that view in the editor would be cool.
Personally, I don't view design docs in Futon much, and just use the
view selector to edit views. But I guess a neat shortcut from the
design doc to the view editor wouldn't hurt.
> * Displaying functions in the Fields tab. It'd be nice to see if we
> can make functions formatted a bit more nicely than just a plain
> string as they are now. I'm not sure how well this would look, but
> some smarts couldn't hurt.
This is part of a general frustration I have with using Futon to read
or even edit large strings, be they functions or blog post content or
whatever. Futon just uses the raw JSON encoding, which means you get
\n instead of line breaks, you need to escape double quote characters
in the content, etc.
It'd be nice if we could just view and edit strings as text, but then
the problem is: how do you enter non-string types (e.g. numbers or
booleans)? We'd probably need a separate type selector of some kind,
and I haven't yet had any bright idea on how to make that elegant and
sufficiently efficient. An other option would be to treat anything
that isn't parseable as JSON as a string, but then you'd need to enter
"42" or "true" (with the quotes) to force a JSON parseable value to a
string. Hmm. Might work though.
> * Closely related to the previous point is truncating large strings in
> the fields tab. There's a source tab now so we can just let people
> click that if they're wanting to see something all gigantic.
Agreed. That one should be pretty simple, too.
> * Editing show/list functions. This is a big one, but something
> similar to the view editor would be nice for editing lists and shows.
> With similar edit links as above. I'm thinking that where we have view
> rows output, we could just put up the view response as plain text and
> then use the "raw view" button as a link to the live page.
As I'm not a CouchApp/show/list user (yet?) I'll abstain about this
feature. But I think adding it to database.html and
$.futon.DatabasePage would likely overwhelm that part of the Futon
code, so preferrably this would be in a separate area of some kind.
But maybe I'm overestimating the amount of code this would take. IIRC
there's a patch for this in JIRA that I haven't looked at yet.
> * Simple syntax checking before doing a save or run of functions.
> Throw an error if you can't compile the function locally. This could
> be combined with the next idea.
I tried that at one point, but (a) it only works for Javascript views,
and (b) it only works when the Javascript interpreter in the browser
actually supports the features you're using in the view code. So you'd
be getting pretty bad results when using E4X or some of the
SpiderMonkey extensions not in the ECMAScript 3 standard. It'd be a
dismissable warning at best, and that would be pretty annoying for
people using such extensions. [I get these kind of erroneuos warnings
for stuff *I know is perfectly fine* from VisualStudio all the time
during working hours. Very annoying]
I think it'd be *way* better if CouchDB itself had a way to report
actual syntax/compilation errors in view (or other) code. Futon could
use that and relay any error messages to the user. Better runtime view
error reporting would be nice, too.
> * Function testing. This has been brought up before, but an
> interesting thing to look into for editing views and lists would be to
> have the browser fetch some subset of the db for testing. I'm not sure
> on the best way to do this right now as it could be domain specific.
> I'm thinking something like, create a filter function that can run
> over _changes or a view and will select just some of the docs. Ideally
> this would replace temporary views completely.
I'm not sure I like this idea. IMO its value is limited because you're
not testing the real thing.
> * Frickin tab support in the function editing boxes.
Would that insert tabs or spaces? And what indentation level should be
used? :P J/K
Seriously, that would be nice. And it should be pretty darn simple to
implement. Where's the JIRA issue? ;)
> * Delete Test Suite DB's - A button on the test suite page that will
> clean out the test suite db's. I tend to be OCD and going through and
> deleting the test suite dbs gets old.
How would Futon know which databases can be deleted? The tests would
probably need to register any disposable databases they create for
testing.
> * Test editing - When you click a test name the browser opens a new
> window showing the source code of that test. If we instead opened a
> new tab that had the function source loaded into the custom test
> editor that'd be cool.
Great idea. Shouldn't be hard, either.
> * A selectable group_level or group=false on the view pages. And we
> should probably change the default output in futon to a single row as
> that's a constant confusion factor for new people.
I'd love this but simply haven't figured out a nice way to get this
into the UI. Ideas welcome! (but for a *nice* way, not *some* way ;)
> * Create/Delete config section/key/value triplets.
Yes please :) Definitely not easy, though.
> * Raw view buttons for the config and status pages
Would be nice, and simple.
> * Remember the Fields/Source tab preference
Ditto. I actually thought we had that already. Hmm.
> * Another thing I'm just noting with the rest is that an interface for
> setting up continuous replication is needed. Adam's still working on
> some of the mechanics that will be required in the end, but some sort
> of trigger for the existing functionality would be good.
I haven't followed this development close enough to comment.
> * View compaction button.
>
> * View info view (err, view of the info about a view)
Like what info?
In response to some of the Futon feedback on this thread, let me talk
a bit about documentation of the JS files. Futon comes with a colorful
mix of JS files, some written by third parties (jquery.js, json2.js,
jquery.form.js, etc) and many by myself and other CouchDB hackers.
For the former we can of course defer to the official documentation,
which is often included in the file itself. For the latter, it'd sure
be nice if they were documented in some way. One challenge with the
(rapidly increasing number of) Javascript files used by Futon and the
test suite is that Futon is just a collection of static files. In
addition, we want to be able to "run" them directly from the source
directory to enable easy development. That means that we can't really
have extensively commented Javascript files if we still want Futon to
load somewhat quickly.
Ideally, the JS source files would be extensively commented, but then
minified during the installation process (for example using the yui
compressor, if enabled and installed). I don't know if we could get
that to work, or how hard it would be. Certainly would be nice. We
could also compress jquery/json2/etc in that case, which are currently
included in their uncompressed form (which is uncomfortably large).
Maybe we could even concat a couple of the scripts to reduce the
number of requests needed in Futon.
Alternatively, we could document the JS files out-of-band, such as on
a set of Wiki pages, or in text files in the repository. But the very
real risk here is that the docs will quickly get out of date as people
change the code but forget to update the docs.
Thoughts?
Cheers,
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/