[TYPO3-hci] files_with_pages backend extension

Christopher bedlamhotelnospam at gnospammail.com
Wed Aug 23 01:20:52 CEST 2006


Mark Stephenson wrote:

> To help make a good idea a reality, here is an idea for an extension 
> that will address #2:
> 
> "2) Web List could show page related folders and file or new module for 
> this purpose For every page own folder like in Plone - only need to 
> create those folders on-demand (when a file actually exists)."
> 
> I agree that, in our experience, having two trees (page and file) is 
> confusing to users and allowing files to be placed inside pages would 
> simplify things and ease maintenance. One of my frustrations is when we 
> move pages to different sections. The pages move beautifully but the 
> associated files in fileadmin do not move. Here is the proposed extension:
> 
> files_with_pages backend extension
> 
> The extension configuration will include specifying a directory in 
> fileadmin where the page-based directories are stored. So a user could 
> specify fileadmin/pagefiles. Within the pagefiles directory, the 
> extension will automatically create directories that are named by each 
> unique page ID in the page tree. I really like this because the ID is 
> unique already and now pages can be moved around but the files can 
> remain where they are because they are tied to the ID. If a user needs 
> to, they can look at files and manager files in Fileadmin normally. The 
> only catch is that they will see a ton of directories that correspond to 
> the page IDs.
> 
> Within the Page view, the extension adds an icon that switches to the 
> new file view for that page. All the page file view can do is upload 
> files to that single directory, rename files, and delete files. It could 
> also support a copy or a move operation. Note: We could go with another 
> view on the left like a File view below the Page view, but it seems like 
> we want the files to feel more connected with the page. However, you 
> interface designers may have a better ideas. In any case, files would 
> feel like they are connected to pages and we would preserve the current 
> way TYPO3 handles files. Can someone prototype how this should look? 
> Here are some other technical details:
> 
> - Just to avoid creating a bunch of empty directories, it seems like the 
> extension could only create a directory if a user wants to upload or to 
> copy a file there.
> 
> - When pages are copied, it might be best not to copy the files because 
> it could create a lot of extra files and most people want just one copy 
> of a file unless they are explicitly copying a file.
> 
> - For deleting pages, I am unsure how best to handle it. Perhaps we 
> leave the files as well, but they may seem orphaned.
> 
> - Linking to the files may require some more work because creating a 
> file link automatically browses the fileadmin directory. For an initial 
> version of the extension, the user may just need to look in the 
> fileadmin/pagefiles directory for the page ID. But it would be great for 
> the files that are local to the page to be available under one tab or a 
> special node in the fileadmin tree.
> 
> Those are my initial thoughts. Please reply to say how we can make this 
> lots better. I believe this approach preserves the current design of 
> TYPO3 and does not force people to use pages with files. However, if we 
> create this extension, I expect that it will be popular. I believe we 
> would add it to our Web-Empowered Church Starter Package 
> (http://webempoweredchurch.com/gettingstarted/installing/).

Ok, but I have one question about the need: in what way is the current 
method for attaching files to pages inadequate? (I'm referring to the 
'Files' field)

Plus one (genuine!) question about the problem you've had: I've /never/ 
had a client come up with the idea of mirroring the page tree in the 
filelist module, and I can't think of /any/ good reason to do so myself 
(since any given file may have legitimate uses in more than one part of 
the tree). Why would somebody do this?


-Christopher



More information about the TYPO3-team-hci mailing list