View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 218 | Composr | commandr | public | 2010-11-22 00:31 | 2015-12-07 23:14 |
| Reporter | Chris Graham | Assigned To | Chris Graham | ||
| Priority | normal | Severity | feature | ||
| Status | closed | Resolution | duplicate | ||
| Summary | 218: Webdav support | ||||
| Description | Webdav is a web filesystem that most OS's can connect to just as a normal network share. Composr would export a webdav implementation that provided certain features: - Online allow super-admins access, via httpauth - Full Composr filesystem access - Access to the Commandr virtual filesystem - Extend the Commandr virtual filesystem to allow native file format representations of Composr data. Each content type would be able to define an Commandr virtual filesystem hook. E.g. - the download system would provide a file tree hierarchy based on the download category structure. You'd be able to manipulate the structure, upload, download, etc. - the calendar would provide an ical file for each event type. Renaming files would rename event types, replacing them would do a delete-all-then-import. (this is basically caldav, so we can try and match that) - addon management would be provided via an addons directory full of tar files - try to use atompub for news - virtualised theme directory, that allows easy overriding just by editing - virtualised override in general, with genius auto-per-function override calculation (i.e. it only saves - overriding for what needs to be overrided) - on programmers file list screens, and template edit links screens, and template tree screens, provide button to “save fileset” (under a name), which puts the fileset into webdav for easy future reference. - integration with planned template import/export feature, whereby screen previews and screens attached to saved template file sets can be edited as normal HTML files ; Composr converts to HTML files from a virtual directory, and back to template files upon saving This should make Composr management a lot faster, with great integration with traditional desktop tools. | ||||
| Additional Information | The following new Commandr-fs hooks will be written: - news, via atom/rss files (preferably support atompub), one level folder structure using news category titles - calendar, via ical files, one level folder structure using calendar type titles - catalogues, via csv files, folder structure using catalogue name then category titles - cedi, via txt files, folder structure using CEDI page titles - downloads, via any files, folder structure using download category titles - galleries, via image/video files (must be smart to detect which), folder structure using download gallery names - iotds, via image files, no folder structure - emoticons [Conversr-only], via image files, one level folder structure using 'importance' - members [Conversr-only], via csv files, folder structure using group names - newsletter subscribers, via csv files, one level folder structure using newsletter name - pages, via txt files, one level folder structure using zone name - addon management, via tar files, one level folder structure of 'installed' or 'not installed' - templates, via htm/css files, one level folder structure of 'theme name'/'file set ID' If there are duplicate names (e.g. two download categories with the same name on the same level) it must be smart enough to suffix them with the formal ID to differentiate (e.g. "Ships (54)"). It must not have any difficulty of duplicate names in different hierarchy positions (i.e. must do full path lookups, not just rely on unique global category names). Where we are representing using atom/rss/ical/csv there will be only one file shown in the directory. However, you can copy in a new file and it will import it all and when you refresh there will still only be one file. You can do this at the top level for the content type, in which case it will try and find the right category for each entry in the file. Template editing works via the screen preview system. Each .tpl file is represented as the .htm of it's preview. When it is saved the system identifies any changes made using a diff and apply them back to the .tpl. CSS changes can also be saved and it'll do a diff to apply them back to the CSS file. | ||||
| Tags | No tags attached. | ||||
| Attach Tags | |||||
| Time estimation (hours) | 25 | ||||
| Sponsorship open | |||||
| parent of | 31 | Closed | Chris Graham | Document to page conversion |
| parent of | 153 | Closed | Chris Graham | Implement Composr web service |
| related to | 627 | Closed | Chris Graham | New untar command |
|
|
test on Windows, make sure Composr serves propfind etc on root if needed too and advertises single dir which is Commandr dir |
|
|
A cool feature would be if you could drag files from your desktop onto icons in the CMS/Admin-Zone, and that would tie into the appropriate Commandr-fs handler (same as WebDav uses) to 'copy' them. E.g. drag a load of word documents onto the News icon, to add them as news. E.g. drag a load of jpegs onto the IOTDs icon to add them as IOTDs. |
|
|
It would be really really cool if git could be run on top of webdav. So this needs to allow a ".git" symlink to exist in any webdav directory (presumably by mapping to a corresponding symlink stored on the real filesystem). I say symlink because if you were running git over webdav you'd want the git files locally. So it is a symlink to your local .git control directory. You'd effectively have two git checkouts locally. A test one (staging site) and a webdav one. You'd pull on the webdav one after pushing from the test one. |
|
|
I also love the idea of a site being a directory on a computer, clean from all the social 'noise' (from a CMS p.o.v.) that is on the live site. You could use diff tools to compare a staging site to a live one, seeing what files are different. Could be really handy. |
|
|
I really like this idea |
|
|
Would be cool to be able to sync any set of Commandr-fs directories with git paths. You could therefore set it all to be under one subpath of a git repository, or have different repositories for different kinds of content (e.g. one for just wiki+). |
|
|
Recreating this in a new issue. |
