You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Jan Lehnardt <ja...@apache.org> on 2009/09/10 11:58:53 UTC
jQuery dependency (Re: Futon Improvements)
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: 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.
>