I don't see the problem with this.
If you were doing a Rails project, you wouldn't complain that you had to
move your Ruby files into a specific structure. Nor would you if you were
doing a Django project. In fact, for any system that uses the filesystem as
state, it is fairly common to have structure. And as Benoit pointed out
before, CouchApps are more than just uploading some HTML into CouchDB.
On Wed, Sep 26, 2012 at 9:49 AM, Dale Harvey <d...@arandomurl.com> wrote:
> I have a folder here with an index.html file in it
>
> Can I upload it to CouchDB as an attachment without moving it? last time
> remember (admittedly a long time ago) I couldnt do that with erica nor the
> couchapppy tool
>
> If not, I think that is one of the primary use cases that should be kept in
> mind, despite the fact I wrote (yet another) one of these tools (and a fair
> few patches to erica) I dont use them because even the very basic tasks
> forced you into a couchapp specific workflow
>
> On 26 September 2012 09:05, Benoit Chesneau <bchesn...@gmail.com> wrote:
>
> > On Wed, Sep 26, 2012 at 7:58 AM, Eli Stevens (Gmail)
> > <wickedg...@gmail.com> wrote:
> > > On Tue, Sep 25, 2012 at 10:25 PM, Ryan Ramage <ryan.ram...@gmail.com>
> > wrote:
> > >> 1) We have to decide on the directory structure. Based on what benoit
> > >> and dale have brought up. I have opinions, along with others. Lets not
> > >> rattle sabres around this yet. But pick something relatively user
> > >> friendly, and straightforward. This can be actioned in our weekly irc.
> > >
> > > Would it make sense to have the directory structure be something that
> > > isn't couchapp specific, and instead dump/load *entire databases*
> > > to/from disk? I could see that actually making it a simpler tool,
> > > since there would be a natural tendency to resist a bunch of
> > > special-case handling for corner cases, ease of use, etc. Instead,
> > > you'd end up with a directory full of:
> > >
> > > my_doc_id.json
> > > my_doc_id.attachments/my_bin_file.dat
> > > my_doc_id.attachments/my_image_file.jpg
> > > etc.
> > >
> > > Then the various couchapp tools could focus on various workflows to
> > > make creating the simple structure and calling the default DB load
> > > tool.
> > >
> > > I'm not a couchapp user, so feel free to discard this idea if it
> > > doesn't make sense or if it doesn't gain any traction.
> > >
> > > Cheers,
> > > Eli
> >
> > The current structure isn't couchapp specific. In fact you can
> > clone/push a doc using erica or couchapp (py the original).
> >
> > The structure reflect JSON properties on a doc, eg.:
> >
> > folder/item -> {"folder": {"item": "value"}}
> > some.json will be addeded as {"some": contentofsomejson}
> > _attachments/ will contains all attachements.
> >
> > Specific to ddoc :
> >
> > views/vname/{map,reduce}.js
> > shows/
> > lists/
> >
> > and even that is just the result of the structure above. The original
> > idea is to allow anyone to create a couch app using the editor he
> > want. That why you have plugin in eclipse, standalone editor on top of
> > it it's really easy. Somehow it also follow the plan9 idea of having
> > everything on the fs.
> >
> > Also as a side note the couchapp fs schema is widely deployed around.
> > Even pubished a doc about it [1]
> >
> >
> > - benoit
> >
> > [1]
> >
> http://www.ibm.com/developerworks/opensource/tutorials/os-couchapp/index.html
> >
>
--
NS
