It was surprisingly simple to write, and using it is quite trivial.
Please check out the haddock documentation and the included sample
project derived from `snap init`.
Features:
. Every user can upload, download, and delete files into her private
home directory.
Still missing (see TODO for a full list):
. Sub-directories.
. Handling of user groups and shared folders.
. Version control.
. Snaplet / Cabal file handling is a little crude.
. The file system interface uses System.Cmd instead of POSIX libs.
Please drop us a line if you use it. We would be particularly
interested in which features we should do next.
> It was surprisingly simple to write, and using it is quite trivial.
> Please check out the haddock documentation and the included sample
> project derived from `snap init`.
> Features:
> . Every user can upload, download, and delete files into her private
> home directory.
> Still missing (see TODO for a full list):
> . Sub-directories.
> . Handling of user groups and shared folders.
> . Version control.
> . Snaplet / Cabal file handling is a little crude.
> . The file system interface uses System.Cmd instead of POSIX libs.
> Please drop us a line if you use it. We would be particularly
> interested in which features we should do next.
Looks cool. One suggestion...have you thought about using the
built-in config file functionality? You're currently passing a few
configuration options as parameters to fileDialogInit. There's
certainly nothing wrong with that, but it means that the user will
have to recompile his application to change any of those parameters.
If the parameter is something that you might want the user to be able
to change without recompiling, then you should put it in a config
file.
>> It was surprisingly simple to write, and using it is quite trivial.
>> Please check out the haddock documentation and the included sample
>> project derived from `snap init`.
>> Features:
>> . Every user can upload, download, and delete files into her private
>> home directory.
>> Still missing (see TODO for a full list):
>> . Sub-directories.
>> . Handling of user groups and shared folders.
>> . Version control.
>> . Snaplet / Cabal file handling is a little crude.
>> . The file system interface uses System.Cmd instead of POSIX libs.
>> Please drop us a line if you use it. We would be particularly
>> interested in which features we should do next.
On Fri, Oct 05, 2012 at 10:25:19AM -0400, MightyByte wrote:
> Date: Fri, 5 Oct 2012 10:25:19 -0400
> From: MightyByte <mightyb...@gmail.com>
> To: snap_framework@googlegroups.com
> Subject: Re: [snap] [ANNOUNCE] snaplet-file-dialog-0.1.0.0 available on
> patch-tag
> Looks cool. One suggestion...have you thought about using the
> built-in config file functionality? You're currently passing a few
> configuration options as parameters to fileDialogInit. There's
> certainly nothing wrong with that, but it means that the user will
> have to recompile his application to change any of those parameters.
> If the parameter is something that you might want the user to be able
> to change without recompiling, then you should put it in a config
> file.
> On Fri, Oct 5, 2012 at 6:15 AM, Alfredo Di Napoli
> <alfredo.dinap...@gmail.com> wrote:
> > Thanks for your effort :)
> > A.
> > On 5 October 2012 12:06, Matthias Fischmann <m.fischm...@googlemail.com>
> > wrote:
> >> Dear all,
> >> the first version of the file dialog snaplet is out:
> >> It was surprisingly simple to write, and using it is quite trivial.
> >> Please check out the haddock documentation and the included sample
> >> project derived from `snap init`.
> >> Features:
> >> . Every user can upload, download, and delete files into her private
> >> home directory.
> >> Still missing (see TODO for a full list):
> >> . Sub-directories.
> >> . Handling of user groups and shared folders.
> >> . Version control.
> >> . Snaplet / Cabal file handling is a little crude.
> >> . The file system interface uses System.Cmd instead of POSIX libs.
> >> Please drop us a line if you use it. We would be particularly
> >> interested in which features we should do next.
> thanks, i like that idea. i added it to the TODO list for parameters
> "file system root" and the "upload file size limit".
> btw, are there any snaplets on hackage that use data file (cabal
> "data-dir") or config file (o'sullivan configurator) support?
> On Fri, Oct 05, 2012 at 10:25:19AM -0400, MightyByte wrote:
>> Date: Fri, 5 Oct 2012 10:25:19 -0400
>> From: MightyByte <mightyb...@gmail.com>
>> To: snap_framework@googlegroups.com
>> Subject: Re: [snap] [ANNOUNCE] snaplet-file-dialog-0.1.0.0 available on
>> patch-tag
>> Looks cool. One suggestion...have you thought about using the
>> built-in config file functionality? You're currently passing a few
>> configuration options as parameters to fileDialogInit. There's
>> certainly nothing wrong with that, but it means that the user will
>> have to recompile his application to change any of those parameters.
>> If the parameter is something that you might want the user to be able
>> to change without recompiling, then you should put it in a config
>> file.
>> On Fri, Oct 5, 2012 at 6:15 AM, Alfredo Di Napoli
>> <alfredo.dinap...@gmail.com> wrote:
>> > Thanks for your effort :)
>> > A.
>> > On 5 October 2012 12:06, Matthias Fischmann <m.fischm...@googlemail.com>
>> > wrote:
>> >> Dear all,
>> >> the first version of the file dialog snaplet is out:
>> >> It was surprisingly simple to write, and using it is quite trivial.
>> >> Please check out the haddock documentation and the included sample
>> >> project derived from `snap init`.
>> >> Features:
>> >> . Every user can upload, download, and delete files into her private
>> >> home directory.
>> >> Still missing (see TODO for a full list):
>> >> . Sub-directories.
>> >> . Handling of user groups and shared folders.
>> >> . Version control.
>> >> . Snaplet / Cabal file handling is a little crude.
>> >> . The file system interface uses System.Cmd instead of POSIX libs.
>> >> Please drop us a line if you use it. We would be particularly
>> >> interested in which features we should do next.
