[PAGES-40] Default values do not work when editing optional areas Created: 14/Nov/13  Updated: 15/Apr/16  Resolved: 13/Oct/15

Status: Closed
Project: Magnolia pages module
Component/s: None
Affects Version/s: None
Fix Version/s: 5.4.2

Type: Bug Priority: Neutral
Reporter: Tom Wespi Assignee: Espen Jervidalo
Resolution: Fixed Votes: 1
Labels: backlog, support, ux
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to MGNLUI-2396 defaultValue does not work in Area Di... Closed
causality
dependency
depends upon MGNLUI-3325 LinkToSetTransformer is not setting n... Closed
depends upon MGNLUI-3570 Investigation for MGNLUI-2397 (defaul... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:
Sprint: Basel 17
Story Points: 13

 Description   

UPDATE: The scope of this ticket was reduced to optional areas only. Please see the comment for the reason why and a work-around.


Unlike components, page and area nodes are created and edited in two distinct steps, so at the moment we don't know when they are actually new, and thus don't apply default values (regardless of field-type).

This may be a custom behavior to implement specifically in the pages app.

e.g. using an OptionGroupFieldDefinition and setting default option with the "selected" property:

If dialog is called from component, it is working. To reproduce: Copy a OptionGroup e.g. from Form Module to a Area Dialog. No Value is selected.



 Comments   
Comment by Markus Koller [ 13/May/14 ]

Still affected version: 5.2.4
Reproduced: Working area dialog (ConfiguredFormDialogDefinition) assigned to a page dialog: In the area dialog, radio is preselected according to selected() (OptionBuilder), in the page dialog using the same dialog, the radio is not preselected.

Comment by Adrian Andermatt [ 27/Nov/14 ]

hey guys
still affected in version 5.3.5, what's the schedule for this?

thanks and regards,

Adrian

Comment by Richard Gange [ 17/Dec/14 ]

Hi Adrian-

Hopefully this will be part of 5.3.7. It seems to be of very common interest.

Hope this helps
Rich

Comment by Mikaël Geljić [ 20/Jan/15 ]

Reopened:

Current fix affects option-groups configured as multiselect (checkboxes). In particular, if someone unselects all options, next time dialog is opened default option is wrongly selected again.

The underlying explanation for the behavior in this ticket is that you're never getting a "new node" with auto-created areas, so you never get default values.
As such, it's not a generic flaw in the field but rather in how areas are being created/edited. Maybe it even works for optional areas by the way?

Another option could be to introduce a nullable property in the definition, and only then set default value for non-multiselect option-groups.

Comment by Evzen Fochr [ 21/Jan/15 ]

Imo preselection works correctly. It should work only for newly created Areas/Components. If OptionGroup is added to a dialog and dialog iss opened on already created Area/Component, it correctly shows that nothing was yet selected.

Comment by Mikaël Geljić [ 22/Jan/15 ]

Reopening and rephrasing this issue.

Unlike components, page and area nodes are created and edited in two distinct steps, so at the moment we don't know when they are actually new, and thus don't apply default values (regardless of field-type).
This may be a custom behavior to implement specifically in the pages app.

We have to think about what options we have there. So chances are that we postpone it once again.

Cheers,
Mika

Comment by Espen Jervidalo [ 13/Oct/15 ]

This ticket has been partly resolved by opening the configured area dialog directly when creating optional areas, instead of creating the area and re-render the page.

For auto-generated areas we already have a mechanism in place, which takes care of creating default-content for an area.

  • Define an ‘autoGeneration’-node on your areaDefinition
  • add a ‘generatorClass’ property to it with ‘info.magnolia.rendering.generator.CopyGenerator’ as value
  • add a ‘content’-node on the same level and add key-value pairs to it.

Details can be found in:

info.magnolia.templating.elements.AreaElement#tryToCreateAreaNode
info.magnolia.rendering.generator.CopyGenerator#generate

I can imagine that this is a bit cumbersome compared to defining them directly in the dialog definition and we tried to find an acceptable solution for auto-generated areas as well. One solution we have implemented is to trick the form framework to treat auto-generated areas as if it was a ‘new’ node and hence setting the default properties.
This actually works, but the dialog won’t display the actual state. So a user opening a dialog to verify some properties will see the default values set, but in fact they aren’t until he hits ‘save’ at least once. Now, you can take this further and override the ‘cancel’ action to save it, instead of cancelling.. but ...

One other approach we considered was to replace to CopyGenerator by a much more sophisticated one and let it lend concepts from our form framework and read out the dialog-definition and the configured defaultValues. But in the end, we would have to take Transformers and Converters into account. And for this the framework really wasn’t designed in the first place. Forms, Transformers and Converters are built around Vaadin’s Item and must be kept away from the rendering.

Comment by Aleksandr Pchelintcev [ 15/Oct/15 ]
  • 	.addTask(new NodeExistsDelegateTask("", contentConnectorPath,
            new PropertyExistsDelegateTask("Install pages detail content connector.", "contentConnectorPath", "implementationClass",
                    new ArrayDelegateTask("Overriding existing, custom content-connector",
                            new WarnTask("", "You have a custom contentConnector installed in the pages detail sub-app. You will have to adapt it to extend the new one."),
    	

    content-connector/contentConnector -> content connector

  • EditElementAction - make injected fields 'final'
  • PagesActionExecutor, JavaDoc wording: If an AbstractElement is passed to the this ....
  • PagesContentConnector, couldn't the following
    int index = element.getPath().lastIndexOf("/");
    String parentPath = element.getPath().substring(0, index);
    String relPath = element.getPath().substring(index + 1);
    

    be done simpler via StringUtils#beforeLast/afterLast?

  • PagesActionExecutorTest
    • typo: testExecutorInstantiatesItemAdapt_o_r
    • if the purpose of the test is just to test that the item gets injected into action (which any action executor should be able to do =)) - then maybe MgnlTestCase extension could be dropped in favor of simple unit test? Unless or course more tests are anticipated.
  • CreateAreaAction
    • eventBus.fireEvent(new ContentChangedEvent(item.getItemId())); - do it conditionally
Generated at Mon Feb 12 06:15:01 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.