Richard,

Sounds great !

We're hoping some of those issues will be simpler to address with 5.0; I'd 
advise you to follow closely :)
The 2-step upload sounds like it's what you need, although some level of 
control can already be achieved by the MultiPartFilter. Again, with 5.0, those 
things should be a little more user friendly, as you'll probably be able to 
upload a file to the server without leaving the dialog.

I'm sure it's a problem others are or have been facing too: how about 
open-sourcing your module(s), and let other chip in with more improvements ?

Cheers,

-greg

On 22 Dec 2010, at 17:10, Unger, Richard wrote:

> Hi Magnolians!
>  
> A little discussion I would like to start before Christmas: the way 
> file-upload works in Magnolia (Images, Documents).
>  
> We’re looking at replacing/modifying some of the logic handling file-uploads.
>  
> Shortcomings of magnolia’s current implementation include:
>  
> ·         No separation between images and documents
> ·         No way to force “the correct choice” – user can pick a PDF when 
> they should be picking an image, they can pick a folder instead of a 
> document, etc…
> ·         No way to make an internal Link (or document Link) field required 
> (“required” setting for controls does not work on uuidLink)
> ·         No way to force file-types on upload – user can upload anything, 
> from .exe to .psd, no filtering of allowed file-types is possible
> ·         No preview when picking images
> ·         No handling of embedded image metadata (EXIF, XMP)
> ·         No difference between “New File” and “New Image” à all document 
> metadata is the same
> ·         Useability: if you make a mistake in the “New File” dialog, the 
> field with the file to upload is cleared, forcing you to choose the file again
>  
> We’re addressing these issues with some custom modules, which:
>  
> ·         Provide specific Trees (based on DMSAdminTree) for Images and 
> Documents
> o   Trees are based on DMS content (use the dms repository) but show only 
> images or documents, respectively
> ·         Provide different Upload dialogs for our custom trees, allowing 
> different metadata on images and documents
> ·         Provide specific uuidLinkDocument and uuidLinkImage controls 
> forcing the user to pick documents of a specific type
> ·         Provide an improved repository browser, with image preview, image 
> upload, and using our trees
>  
> This is mostly working well.
>  
>  
> However, to handle issues related to file-upload, I am now running into some 
> problems:
>  
> ·         How to force upload of specific file types?
> ·         How to extract metadata from images at the right moment?
>  
> The Problem is that the current implementation for the “New Document” dialog 
> does everything in one step: the user enters the metadata and picks the 
> image, and then uploads everything at the same time.
>  
> I was thinking of a 2-step solution:
> 1.       first the user chooses and uploads the document
> ·         the system can check the document type against configured allowed 
> types
> ·         the system can extract the metadata from the document to provide 
> default values for the next step
> 2.       in a second step, the user is presented with the metadata form and 
> can enter the values for metadata
> ·         any metadata found in the image is prefilled in the dialog fields
>  
> What do people think? Is this the right way to go about it?
> Can you suggest any easier way to implement this?
>  
> Thanks for your attention,
>  
> Richard Unger
> Vienna, Austria
>  
> PS: For those interested, a little background to motivate why I am asking 
> these questions:
>  
> We’re implementing a Magnolia-EE based System for a large government sector 
> customer – the final system will run about 50 Websites, maintained by 150 or 
> so editors in different departments. Very few of our editors have strong 
> computer skills.
> For this reason ease of use for the editors is very important to us – things 
> that might seem trivial to us programmers or to an experienced web-content 
> person can be serious problems for less advanced users.
>  
> Magnolia’s GUI is very intuitive in general, we have already received a lot 
> of positive feedback from our testing editors.
> However, one area that is consistently causing problems is the image and 
> document handling.
>  
> 
> 
> ----------------------------------------------------------------
> For list details see
> http://www.magnolia-cms.com/home/community/mailing-lists.html
> To unsubscribe, E-mail to: <[email protected]>
> ----------------------------------------------------------------



----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------

Reply via email to