Is there any reason not to use "cq/gui/components/authoring/dialog/fileupload"? | Community
Skip to main content
P
prestonModOp
Level 3
March 1, 2018
Question

Is there any reason not to use "cq/gui/components/authoring/dialog/fileupload"?

  • March 1, 2018
  • 3 replies
  • 5323 views

We're in the process of upgrading to AEM 6.3. Up until now we've been using the standard Touch UI foundation fileupload. The one with a sling:resourceType of "granite/ui/components/coral/foundation/form/fileupload".

The way we used this under 6.1 was to omit the uploadUrl attribute. This would prevent authors from actually uploading a file, while still allowing them to drag assets from the DAM. In this way we essentially created an Image component where we had some control over the authoring experience. The dialog code for the form field looks like this. 

Under 6.3 this shows up as disabled and doesn't work any longer. We've spent quite a lot of time looking into Client Libs incompatibilities, bundle incompatibilities, permissions, etc. and we've come up empty. This just doesn't work for us in AEM 6.3

What does work for us, however, is using a cq/gui component, defined by the resourceType "cq/gui/components/authoring/dialog/fileupload". I found this while looking through the code for the WCM Core components. Our modified code looks like this.


Is there any reason not to use this? I'm having trouble finding it documented anywhere on this site. So that worries me a bit. However, nothing else we've tried works.

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

3 replies

smacdonald2008
smacdonald2008
Level 10
March 1, 2018

If the Core Components are using it - then it should be good to use. Core Components typically reflect best practice.

P
prestonModOpAuthor
Level 3
March 1, 2018

The main problem I'm having is that the tooltip behaves different from other fields. I think because it's a different type of thing. The tooltip for this field render's as a coral-tooltip and not a div.

So I'm worried I'm going to be opening a whole other can of worms. See below where the top tooltip (for the new new fileupload component) scrolls off the page.

P
prestonModOpAuthor
Level 3
March 3, 2018

A follow up to this. While the core component worked, it came with some difficulties. Mainly that the tooltip was a different style from the other tooltips in the dialog and so it scrolled off the page. Eventually I was able to get the standard granite fileupload component (granite/ui/components/foundation/form/fileupload) to work. This is what a fileupload entity looks like in my code now.

<file
   jcr:primaryType="nt:unstructured"
   sling:resourceType="granite/ui/components/foundation/form/fileupload"
   class="cq-droptarget"
   fieldLabel="Image Asset"
   fieldDescription="Drag and drop an image asset from the asset finder here. If asset is shown, press 'Clear' to remove the reference."
   fileNameParameter="./fileName"
   mimeTypes="[image]"
   name="./file"
   useHTML5="{Boolean}true"
   autoStart="{Boolean}false"
   allowUpload="{Boolean}false"
   uploadUrl="${suffix.path}"
   title="Drag and Drop Image"/>

What I changed was adding the useHTML5, autoStart and uploadUrl attributes. I think the key part was the uploadUrl attribute. Without this the component was showing up as disabled. It used to be a standard trick to remove the "uploadUrl" attribute in order to prevent uploads from the filesystem. It looks like this attribute is required under AEM 6.3. To offset this, though, the "allowUpload" attribute now works to disable uploads, even with the "uploadUrl" attribute there.

As far as I can tell this isn't documented. It just changed from 6.1 to 6.3.     

    Terms & ConditionsAccessibility statement

    Loading footer...