[MGNLDAM-383] Open "edit asset" dialog when uploading a new asset Created: 27/Jan/14  Updated: 14/Sep/15  Resolved: 09/Oct/14

Status: Closed
Project: Magnolia DAM Module
Component/s: DAM App, User Interaction
Affects Version/s: None
Fix Version/s: 2.0.4

Type: New Feature Priority: Critical
Reporter: Andreas Weder Assignee: Mikaël Geljić
Resolution: Fixed Votes: 3
Labels: is-time-consuming, pain-point, support, upload, usability, ux
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Cloners
is cloned by MGNLUI-3195 Enable opening a form-dialog from a c... Closed
relation
Template:
Acceptance criteria:
Empty
Date of First Response:

 Description   

If we would open the "edit asset" (or a very similar dialog) on "upload asset", a user could simultaneously upload a new asset while also edit the meta data. This would put some emphasis on the importance of meta data.

Please research:

  • what are our options?
  • can/should we show the "edit asset" dialog?

See the linked support issue for more infos and the discussion that led to this.



 Comments   
Comment by Andreas Weder [ 03/Feb/14 ]

Assigned this to Sasha: please research, what our options are here.

Comment by Aleksandr Pchelintcev [ 01/Apr/14 ]

After several discussions we have concluded that the easiest way to provide such functionality would be to add an 'edit' button to an asset preview in dialog, clicking on which would take the user to the detail sub-app of a respective asset. There the user could set all the properties of an asset.

Unfortunately, due to harsh workload at the moment I fear the feature will not be squeezed in 5.2.4, but I'm pretty positive we will have it for the next release.

Comment by Aleksandr Pchelintcev [ 16/Jun/14 ]

After a long pause we have tried to resolve this issue in several ways. It looks like the only feasible/reasonable solution is indeed - to open either asset-app detail sub-app or a dialog that looks like it in a sub-app. However, we have encountered troubles with component providers and thus the generation of some form fields in such a component is impossible. This means we would have to invest more time into investigation of this issue and especially of the causes that prevent it from being resolved easily.

Meanwhile the progress is stored on the branch:
https://git.magnolia-cms.com/gitweb/?p=modules/dam.git;a=shortlog;h=refs/heads/MGNLDAM-383

Comment by Mikaël Geljić [ 22/Jul/14 ]

Here's a few more insights on the component provider limitations:

  • The set of parameters (CandidateParameterResolver) is only used by the ComponentProvider to instantiate the selected implementation class itself
    • (ComponentProvider.newInstance(class, params...))
    • There is no way to forward this set of parameters to the dependencies of the implemented class, these are instantiated exclusively "in the Guice world".
  • Any dependency of that class, that itself also has a dependency to ComponentProvider, will get the one where its component mapping is declared (in module descriptor)
    • Not the one which construction is originating from
    • Even for a simple type/implementation config, if we have it once in e.g. admincentral container, we shouldn't have to duplicate it in a lesser container (e.g. subapp) for the sake of getting the right component provider.
    • This might work for one component, but we don't want to redeclare 10 different mappings to keep our dependencies to ComponentProvider under control
    • Then similarly we would end up redefining pretty much all subapp mappings programmatically in the choosedialog container?
      • for us to open a dialog from the "context" of the choose-dialog, e.g. provide the same ImageProvider for an upload field than the one in the choose-dialog (taken from its target app's browser subapp).
Comment by Mikaël Geljić [ 20/Aug/14 ]

Couple options to try out:

  • either add missing bindings in code (might be cumbersome and still incomplete for one case or the other)
  • either "#getSubappWithoutStarting", right now we only get the app level bindings (#getAppWithoutStarting)
    • beware though, choose dialogs are currently bound to apps, not subapps
Comment by Mikaël Geljić [ 11/Sep/14 ]

We're still looking for a more convincing way to solve that, postponing (yet again) by one maintenance release.

Generated at Mon Feb 12 04:59:17 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.