Details

Description

I just tested the mod/resource mod edit form - the file manager with main file selection is absolutely horrible, working on a temporary workaround,
but the main file selection really needs to be implemented natively in the file manager - only when JS off it should be a separate text box

Activity

The main file selection actually has been in the main file manager for a long time, but it was hard to find. I think the new menu from yesterday improves that at least. Click on the menu icon after any file to see it.

However, I think we need to improve this a lot more.

Javascript version:

1) Hide the Main file element COMPLETELY.
2) If only one file is copied into the file area, then select that by default (this can be done after submit in server-side validation).
3) If more than one file is uploaded and a main file isn't specified, then server-side validation should reload the form and tell the user what to do. This will happen so infrequently that I think it's worth not confusing everyone with the main file element.

Non-Javascript version (completely broken at the moment!)

1) I think we again need to hide the main file element with CSS
2) Add a "set as main file" link after each file, but only if there are more than one.

Martin Dougiamas
added a comment - 26/May/10 10:34 AM Yes, no arguments here about that.
The main file selection actually has been in the main file manager for a long time, but it was hard to find. I think the new menu from yesterday improves that at least. Click on the menu icon after any file to see it.
However, I think we need to improve this a lot more.
Javascript version:
1) Hide the Main file element COMPLETELY.
2) If only one file is copied into the file area, then select that by default (this can be done after submit in server-side validation).
3) If more than one file is uploaded and a main file isn't specified, then server-side validation should reload the form and tell the user what to do. This will happen so infrequently that I think it's worth not confusing everyone with the main file element.
Non-Javascript version (completely broken at the moment!)
1) I think we again need to hide the main file element with CSS
2) Add a "set as main file" link after each file, but only if there are more than one.

After some more talking and looking at this, the main technical difficulty with non-Javascript is the separation of the "Main file" concept from the file API. It's difficult to have a clean interface inside the filemanager to update a field belonging to a module.

Why don't we add a small boolean field to the "file" table called "mainfile" and add some File API call to set the main file for a filearea? Right now this would mostly only be useful for the resource module, but I think it could be very useful for other modules in future. I can imagine students submitting a web site in an assignment, for example (yeah yeah XSS risks etc, that is a problem for the module and permissions). All that can be discussed later, but the File API should support the concept.

I propose we do this:

1) GET JS INTERFACE FIXED FOR TESTERS NOW

hide the main file element completely

implement server form validation to auto-select mainfile when there is one, and flag error on form when 2 or more, telling them how to use the context menu to select the main file.

2) IF WE AGREE ON THE MAINFILE FIELD IN FILE TABLE

add the flag field, and any new API call to set the flag for any file in a given filearea

add a flag to filemanager element to enable/disable the mainfile selection in the menus (so that it will normally not be seen in generic file areas)

add upgrade code to make sure mainfile selections in the resource table are copied to the file table

drop the varchar mainfile field from the resource table

update the resource code to use the new API for server form validation

3) FIX THE NON-JS INTERFACE

We need to load the OBJECT in the page by default and hide/replace it with the JS version. It should be possible to make this pretty seamless with some work (Sam is doing a lot of this with the custom menus and docked blocks etc)

Add [Set as main file] links after every file whenever mainfile selection is enabled AND there is more than one file.

Petr, let me know if you have a strong objection to this new field in the file table. The other option would be a new table like file_mainfile but that seems overkill for such a small boolean value.

Martin Dougiamas
added a comment - 26/May/10 11:20 AM - edited After some more talking and looking at this, the main technical difficulty with non-Javascript is the separation of the "Main file" concept from the file API. It's difficult to have a clean interface inside the filemanager to update a field belonging to a module.
Why don't we add a small boolean field to the "file" table called "mainfile" and add some File API call to set the main file for a filearea? Right now this would mostly only be useful for the resource module, but I think it could be very useful for other modules in future. I can imagine students submitting a web site in an assignment, for example (yeah yeah XSS risks etc, that is a problem for the module and permissions). All that can be discussed later, but the File API should support the concept.
I propose we do this:
1) GET JS INTERFACE FIXED FOR TESTERS NOW
hide the main file element completely
implement server form validation to auto-select mainfile when there is one, and flag error on form when 2 or more, telling them how to use the context menu to select the main file.
2) IF WE AGREE ON THE MAINFILE FIELD IN FILE TABLE
add the flag field, and any new API call to set the flag for any file in a given filearea
add a flag to filemanager element to enable/disable the mainfile selection in the menus (so that it will normally not be seen in generic file areas)
add upgrade code to make sure mainfile selections in the resource table are copied to the file table
drop the varchar mainfile field from the resource table
update the resource code to use the new API for server form validation
3) FIX THE NON-JS INTERFACE
We need to load the OBJECT in the page by default and hide/replace it with the JS version. It should be possible to make this pretty seamless with some work (Sam is doing a lot of this with the custom menus and docked blocks etc)
Add [Set as main file] links after every file whenever mainfile selection is enabled AND there is more than one file.
Petr, let me know if you have a strong objection to this new field in the file table. The other option would be a new table like file_mainfile but that seems overkill for such a small boolean value.

Martin Dougiamas
added a comment - 26/May/10 10:42 PM I think we reached general agreement in chat this afternoon to call the new field "sortorder" and to make it an int with a default value of 0.
The resource module can use it to make the "main file" the "first file". I guess the value would be 1 for this file. (Higher numbers mean higher in importance).
Other modules may choose to use this field to sort files in a particular way, or use it to store version numbers or whatever. It's up to the module.

Dongsheng Cai
added a comment - 27/May/10 2:50 PM This is the patch to add sortorder field including related changes to resource module.
I wasn't sure if we should remove the mainfile field in resource module table.

Petr Skoda
added a comment - 27/May/10 3:18 PM 1/ function file_set_sortorder($contextid, $filearea, $itemid, $filepath, $filename, $sortorder=0) {
why default 0 there?
2/ the lib/db/upgrade.php should be updated also when it creates the files table
3/ the mod/resource initial migration should be updated too to not use the mainfile at all + there should be some upgrade path for PR2 users
Otherwise it looks ok, please upload the the patch here again, thanks!

Eloy Lafuente (stronk7)
added a comment - 28/May/10 5:21 PM hehe, I guess it's not only about removing 'mainfile' from resources backup (that, indeed, needs dropping from DB too?)
But it's about to add the new field 'sortorder' to backup_final_files_structure_step (seems not done).
Ciao