Using Filebrowser as a utility for other modules - inline table, popup widget, autocomplete, AJAX

The patch itself...

And here's an entire module that uses this hook and handle - I don't know if I can be bothered releasing it as a project, but it's something I've needed for a while when dealing with legacy sites - the ability to 'attach' existing files to nodes.

If only I can find a way to turn OFF the date column, filebrowser will be a useful widget to use for many things.

.dan.

I've done a significant rewrite - Adding AJAX updates and made bits more configurable.
The results are demonstrated in a sandbox here.

CHANGELOG
danm - July 2006

Added AJAX inline requests for subdirectories.
Added new menu callbacks :
filebrowser_raw, the AJAX Callback
filebrowser_lite, a demo on how to select columns
filebrowser_popup, a widget that can be used from other places
Adjusted the page callback to take the path as arguments, not just from GET
Re-worked the table construction to use a set of column callbacks,
to allow caller to define which columns get displayed,
and to extend with their own columns.
Abstracted all the column layouts into their own function.
Column cells are now named arrays, not indexed numerically.
better for arbitray column sorting, and allows better CSS styling
Added some css to stop date column wrapping, and tighten layout.
Fixed problem where an empty directory request would list root (!)
Modified README to describe the new method of table building, and give sample code.
Added help page (pipes the README and displays demo code)

I actually started with disknode, but didn't think it was appropriate for the functionality IT provided to be building the browse routines.
I actually modeled the pop-up widget on the disknode code.

I found filebrowser a bit simple, (not much different from a default apache directoryindex) but liked the descript.ion support.

Yeah, I ended up with what looks like a significant chunk of new code, but most of it was just pulling the table row renderer out into a set of table cell renderers.
I can easily abstract the AJAX additions out into a sub-library of their own.
The actual points of contact with the orginal code are probably 6 lines.

Thanks for the links ... I tried to get ezdownload working, but it's 4.6 and PostGres only. It sounds like it handles user roles more usefully, but I couldn't see any inspiration in the docs or code.

... and had a look at filesystemapi . Again, pretty good on authentication but no UI to speak of.
Filebrowser is definately the one I'm plugging closest into. I can strip the code a bit (into an external library) if that would make it easier to see and adapt to...

I have two other modules in the works that will be using this, I can also see it becoming an in-page selector thing with a bunch of UI uses.

FWIW, here's a version with the optional extras (AJAX and sample code) split out from the core modifications.
We can compare the relevant changes without being distracted by the new bits.
That's all part of what I put the new hooks into it for anyway.

As before, the main change was to the engine in the middle -
from

        $details[] = array_merge(
          array(
            array('data' => $link, 'class' => 'filename', 'sv' => $file),
            array('data' => $size, 'sv' => ($size ? $stat['size'] : 0)),
            array('data' => format_interval($age), 'sv' => $age)
          ), $extrainfo);

to

  $cols = array('expander','icon','name','size','age','info');
...
     foreach($cols as $colname){
        $func = 'filebrowser_get_cell_'.$colname;
        if(function_exists($func)){
          $row[$colname] =  $func($completepath);
        }
      }
     $details[] = $row;

Everything else is gravy.

Hey :)
The extrainfo is the column called 'info'!
Previously all the cells were built in the array, and the extra info was fetched from a separate call.
Now ALL cells are built from individual calls - the way extrainfo does.

I really like the descript.ion support, and I think the parser *callback* idea works well (although it puts code in a funny place).
I've built RDF parsing for metadata alongside files as well (historically).

I haven't got the best answer yet for adding multiple cells in one callback, (descriptions are parsed, but not extended ones) but the way I'm thinking, each type of column would be fetched individually.
So 'translator' and 'status' could be turned on and off independant of each other, could be swapped in position, and be sortable or filterable.

I know I moved the icon out of the filename cell. That's just to make it optional. Problem?
And, well now you can place the description wherever you want.
$cols = ('icon','name','info','size')
$cols = ('icon','name','size','info')
Or if you really want, we can add a merged version.
$cols = ('icon','name+info','size') ... but I don't know why.

I just went and had a look. Currently a bit broken it would seem, but the public demo works nice in FF. The promise of actual file management is good, but I really don't like how everyone defines their own content type for every job they want to do.

Having the ability for attach a node to a folder (cool, I was planning that myself) is not a node definition, it's a property a node may have. This is what turned me off disknode and into my own version.

Plus, from looking at the code (it just won't run for me, looks like the formAPI rendering is gone wrong) I really dunno why it tries to replace the normal file upload.module instead of just enhancing it.

Anyway, on this project, there IS a small amount of breakage in that (as I mentioned) one cell callback cannot currently create two columns. It's not happy about inventing new cells on the fly.
To work exactly as gobas example does right now, two custom functions for the two custom columns must be written.
Then the display request would become
$cols=array('icon','name+description','size','age','translator','status');

function filebrowser_get_cell_translator(){}

must be created in a way similar to how the filebrowser_get_cell_info() works now.

So not a totally seamless change.
Alternatively, we could just tack the old $extrainfo on the end, but it won't work with the AJAX, and ... I can't disable it!

Adding an actions column to provide a delete button or even 'move' is now almost trivial - but that's certainly a separate module - just one that happens to use this new widget.
'editing' is not gonna happen, and renaming is possible, but inappropriate.
However an 'attach *to*' button will happen, and possibly a 'describe'

I came up with the idea for attaching folders following a client request for bulk (zip) uploads.

By tricking the upload.module 'files' value into pointing at a dir, then using this filebrowser table to render an enhanced view of that dir, I think I've got it sorted. ... without custom SQL and without custom content types.

Unreleased yet is the tiny itch that started it all - the attach.module seen at the top of this discussion. It now runs on my AJAX filebrowser instead of the one in the picture.

I've thrown up a sandbox Demonstrating the updates in action. See the popup and autocomplete demos towards the bottom.

If you try making a page (anonymous uploads are OK for there) You can see the widget doing magic as an upload and browse attachments handler.

I still need to pretty up the UI (fighting with forms API still) but the power there is a leap beyond the previous file management utils!

Note the attach module (which provides the 'find' and 'save as' functions) is separate from the filebrowser, but works close with it, for obvious reasons.
Some of the JScript may be a bit funky - browser testing as I go.

The latest version of the bundle is pretty stable, and (as before) has the enhancements in a different file from the original core.

.dan.

Doh! Preview is your friend.
I'm just sick of my attachments getting lost when I try to preview in this interface... sorry.

Here's the latest refinements, including :

Added extended demo to the help page
Support whole-site browsing
Added support for displaying selected cols via the http request
Added recursive/non-recursive flag
Added list rendering support, a semantic alternative to tables

I also bundled my (alpha) 'attach.module' do show a few ways I'm using the filebrowser in action.
it allows browsing existing attachments from the node edit, a 'save as' browers for uploads, an attachment-centric browser (here's the file, where's the owner?) and allows folders to be 'attached' to nodes - and a listing viewed inline with the node body.

I've made almost no changes to the actual filebrowser.module since last time (just a tweak on the way info is cached), all dev is happening in the 'extension' file.

Sorry, I moved the sandbox.
demo at http://www.coders.co.nz/drupal_development/4.7/node/10
and README at http://www.coders.co.nz/drupal_development/4.7/node/2
and yes, you can try the attachment upload live if you want.

A bit odd.
"Number 2" ?? No way would it be inventing that string.

It's not relying on the database file registration table at all - I went this direction because I don't trust it at all, and it's specifically to support the finding and absorbing of unknown (Legacy or FTPed) files that I made it.

I have a suspicion I left a small piece out of the bundle - I'll try a fresh install on yet another shell site to see what's happening. Drupal 4.7 stable, not CVS, though I don't think that would be a problem.

(PS, my email to you earlier today appears to have bounced, I'll forward my reply through Drupal.org...)

The 'extensions' file was specially created on request further up this issue thread.
It's to separate the changes to the lightweight core that I needed from the additional functionality.
So that the volatile bits can be reviewed without getting confused by the new goodies.

If the base changes are made to filebrowser.module, the extensions CAN indeed just become its own optional module. That's the idea.

I added the js for Ajax, another js to support a 'select-all' and 'select contents' checkbox for the recursive tree-view filemanager, the demo just because I like verbose documentation. All the resource files are conditional, and all do distinctly different jobs (apart from one which is totally redundant and shouldn't be there :) Whoops.

I know I've been a bit lazy on the error-message translation strings. They are trivial to tidy up, and were not really a priority during testing. Can probably get them fixed in minutes.

If I thought it was at all likely that anyone would be translating the entire README document into multiple languages, then including it as a help file might look less clever. I've not seen them around much. The include trick is just a quick hack that makes up for having NO help at all. I'd consider having README.en.txt or something instead. Could work.

I can easily run a pretty-printer over the code, spaces between paranthesis didn't really seem a problem at the time. Normally I stretch things out lots, the only one-liners are no-brainers.

I've got CVS for some of my other projects. I do need to do a bit more dependancy testing. I use some other libraries for nicely rendering forms inside tables, and I'm just looking for the best way to include them.

Sorry, I haven't forgotten this.
As requested above,
I've reworked all strings to be translatable, and run a lint-beautifier over the code.

I've mostly renamed the 'extensions' into a module of its own.
This is almost identical to how the code was structured before, but with more Drupal scaffolding.

I'm just trying to triple-test to make sure there's no dodgy dependancies, and things work PHP4/5 and with good and bad file directory settings.

Um, I can't recall whether I fixed the '2' problem, although I think I did see it once.
Off to yet another fresh install... But you can try this bundle in the meantime.

Oh fart. I'd left this out (I keep them in another dir, because I use them in multi places)

I guess I could embed them, but it'd be wrong.

As requested by Goba, Here is just the original filebrowser.module file with the modifications needed for my new hooks to work.
I actually decoupled the 'extensions' into a separate module in the tarball I sent last week, and this file hasn't essentially changed from that version.

However, for cleanliness, from now we'll leave the filebrowser as much as-is as possible, and I'll go start a new project for the extensions.
The following version of filebrowser.module is expected to behave exactly as before - only the internals have changed to make extension possible.

- the description callback functionality should still work, but may need review, as I didn't impliment/test it myself.

Or if you'd prefer a patch (with 1/3 of the code somewhat modified, the patch is as big as the original) here it is

The extensions now all live on their own in a new project

I agree.
I soon figured that allowing the arbitrary columns to be defined from the GET was indeed too flexible - IE not restrictive or 'safe' enough.
It was fun to test during dev, but then I soon went with admin-configurable profiles - which were attached to their respective subdirectories - instead. It's a little more complex to maintain, but allows the granular access control I needed to support multiple, parallal archives and invocations.

Other tweaks, controlling 'unsafe' folders etc were added later also.
One requirement (for my use) was for admin users to be able to browse and link to files from anywhere in the webroot - not just /files/ - because I wanted to rebuild a legacy site in-place without breaking or moving any of the archived resources. Thus, finding a safe way to set the filebrowser_root to '/' was needed.