Topics

programming

php drupal scheme scheming macros design patterns da la

design

design css

random thoughts

scribbles

alter ego

other me 'em that link us my space me linked in

Collections

Programmable web
PHP design patterns

Similar things

  • Drupal at LinuxWorldExpo
  • a mod to robert's linux expo t-shirt design
  • fat tap entry for the drupal design contest - london 2005 LinuxWorld
  • drpkg - drupal package manager
  • taxonomy filebrowser
  • taxonomy_addon module
  • warholesque drupal panel
  • Ok, Ok, the code will follow (very) soon
  • BarCamp in Amsterdam - October 2005
  • Design contest: LinuxWorld 2005 t-shirt - champagne for the winner

guild
Home » blogs » vlado's blog

Drupal and files and documents

Submitted by vlado on Tue, 2007-06-05 10:52.document management | drupal | file handling

The state of affairs with files and file handling is strange.

  • Files are not first class content in core. It is disputable whether they should be or not, I have no clue about the answer either, basically I'm sitting on the fence on that.
  • There is a file api, which provides basic file operations. It is quite improved in D6, and I hope that hook file will get into core as well.
  • The only file related module in core provides attachments, similar to email attachments, and with various filter modules you can embed them inside your node's content. This is a very specific text document oriented need, and is very useful
  • There are loads of contrib modules and ways you can deal with files in the larger drupal universe.
  • There is a lack of modules tackling what I would call document management.

So what do I mean by document management?

  • Documents are files
  • Documents can be classified, tagged, grouped, dowloaded...
  • Documents have revisions
  • Document metadata should be extendable, according to one's needs
  • Documents can have an editorial life-cycle, but not always, so all workflow related issues I'll simply ignore
  • It would be a very good practice, as Morbus said to
    ...Thus, files and folders need to have some sense of logic to them such that if the manager goes away (ie., Drupal, Gallery, the database), the files still make sense.

    , but it is related to a storage backend, so I will ignore it for the time being

Where stuff falls short currently in Drupal

There are decent file system reflection interfaces in contrib, unfortunately they are not up to speed with update over the web or having revision/version control.

There are file-node/field style modules, but they don't provide decent directory overviews, expected UI, etc...

It is hard to commit to contrib modules for the long term, since you don't know how long they will survive in the wild.

Where Drupal hits home

The direction of the fileapi is (IMO) right. The evolution towards different file handling backends is both sensible and good. The distinction in HEAD between upload module and general drupal file db data is a good direction, I hope. The hook file patch idea is very good, hopefully it will get before code freeze.

All of the above do set up a base framework which, while not providing document management, does provide consistent extensible file handling.

When all that is settled we can think about how do we satisfy the various diverse needs - filesystem based directory structure, file dupes handling, revision handling, permissions, webdav, ftp integration, ....

Until then I'm meeting some of my users day to day needs with my docs module. Well, a shamless plug, but I'm not sorry for it :) It is mainly a UI project, not commiting into any of the hard decisions outlined above. That one should be a cleanup the contrib style project, by merging the efforts of a bunch of interested developers.

vlado's blog | add new comment
Home » blogs » vlado's blog

dikini.net

spreading confusion by accident since 1970