[PAGES-61] DefaultValue does not work for page properties Created: 08/Mar/16  Updated: 26/Mar/20  Resolved: 05/May/16

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

Type: Improvement Priority: Neutral
Reporter: Roman Kovařík Assignee: Roman Kovařík
Resolution: Fixed Votes: 0
Labels: ux
Remaining Estimate: 0d
Time Spent: 20m
Original Estimate: Not Specified

Issue Links:
Cloners
clones MGNLUI-2790 defaultValue does not work in Page Di... Closed
is cloned by PAGES-280 DefaultValue does not work for page p... Closed
Relates
relates to PAGES-60 Page node names that contain ~ (tilde... Closed
relates to MGNLUI-3874 Firing ContentChangeEvent on the root... Closed
relates to PAGES-67 Rename texts in "Create new component... Closed
causality
is causing MGNLCE-28 Adjust tests to PAGES-61 ( MGNLUI-2790) Closed
is causing MGNLCE-36 Adjust UI tests to changes in PAGES-61 Closed
is causing MGNLEE-430 Adjust tests to PAGES-61 (MGNLUI-2790) Closed
is causing MGNLEE-434 Adjust UI tests to changes in PAGES-61 Closed
dependency
depends upon MGNLUI-3868 Allow to provide a custom editor call... Closed
duplicate
is duplicated by MGNLUI-3890 Option group field: selected value is... Closed
relation
is related to MAGNOLIA-6836 Can't preview successfully-published ... 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)
Release notes required:
Yes
Date of First Response:
Sprint: Kromeriz 34, Kromeriz 42
Story Points: 3

 Description   

A "defaultValue" property does not work in Page Dialogs: a field is not displayed with the same value assigned to property 'defaultValue' into the correspondent dialog field.



 Comments   
Comment by Roman Kovařík [ 08/Mar/16 ]

The problem is that the page is created via Add page action. If you edit the page properties, the default values are not taken into account since the item is not an instance of JcrNewItemAdapter anymore so the default values are not used.
A solution is to open page properties dialog immediately after page creation.

Comment by Mikaël Geljić [ 14/Mar/16 ]

This should most likely have gone through ux approval upfront; in the past we took the stance several times to acknowledge the issue and leave it aside (while auto-generation was a solution for areas). Not saying this is necessarily wrong, but it needs to be looked at carefully.

Upon discussion, we could see at least two angles to address this issue:

1. Without impact on user interaction, by means of dialog-based auto-generation

  • more versatile
  • a bit far fetched (dialogs may involve transformers for setting values)

2. By chaining dialogs for the "Add page" action, like you did

  • more consistent with adding components
  • will never work the same for areas, unless we chain again several more dialogs to these; otherwise it's still down to auto-generation in some cases

I think both are fine, so we can generally proceed with 2. but we need to make a few amendments then:

  • Page template dialog's save action should be labelled "Choose", and should not save the new node yet (so that, if you cancel the second dialog, then page is not created; this is also how the component chooser works)
  • The title field in the first dialog becomes redundant; remove it.
    • anything speaking against this? let us know
  • If page has no dialog configured, we should save immediately

Did I miss anything? or more ideas/follow-up for simplification of page models?
Cheers,

Comment by Andreas Weder [ 14/Mar/16 ]

Hi guys,

I've attached a wireframe and have given this more thought. mgeljic, if we actually label that button "Add" instead of "Choose" (it's not just about choosing a template anyway), then we could actually mostly go with the existing solution, don't you think?

So what I would change:

  • remove the page title field from the first dialog
  • relabel the default button to "Add"

Optionally, I would also:

  • change the dialog title to "Add page" (the "Add new" is redundant)
  • change the labels on the "hide navigation" checkbox to make this a bit more self explanatory

To clarify even more that clicking on "Add" does indeed add the page, we could (see second wireframe):

  • show a notif on top of the second dialog informing the user that the page was added.

I'm sure that many users will welcome getting the page properties right away, as getting to them right after adding the page is a bit cumbersome (click on "edit page" first, then "edit page properties"). Should we find that not be the case, this solution will indeed add one more click to get going on a page. I'll add a follow-up issue asking for a mechanism more like solution 1 you sketched, mgeljic, to at least get this researched, to also tackle other "defaultValue" cases.

Comment by Mikaël Geljić [ 17/Mar/16 ]

weder, can't say I'm too fond of it:

  • We're making adding a page and its properties a more combined activity; so it feels odd to stop half-way through:
    • As a user I can't guess what happens to default values when I cancel (basically feels like cancel does a partial saving anyway—because they're not set by the first dialog).
    • In fact, they are currently applied, but this is just owing to a technical hack (i.e. opening 2nd dialog before saving the 1st one)
    • More troubling, user can also cancel and create a page without its required fields
  • If we feel we're too forcibly slowing down the normal "add page" activity, then we can also think about other solutions for the next iteration (wizardry anyone?), assuming the lack of generated default values is a much longer shot.
  • Regardless, I'd like to keep things consistent between adding pages, optional areas and components, be it interaction, labelling, user messaging, or other UI optimizations. They're conceptually similar and part of the same user story.

This fuss about default values is old enough, and didn't become critical all of a sudden, so we have choice

Comment by Roman Kovařík [ 21/Mar/16 ]

This ticket is about page properties. The default values for components work without problems when adding a component by a dialog.

Default values for autogenerated components/areas are different topic. You can provide all required values for an auto generated component https://documentation.magnolia-cms.com/display/DOCS/Component+autogeneration#Componentautogeneration-Autogenerationbehavior or you can create your own CopyGenerator to meet your needs (and e.g. hijack the dialog default values)...

I don't know where did the myth about problems with areas/components default values come from but I see problems only with page properties .
Can we have some final decision here? cc mgeljic weder

Comment by Mikaël Geljić [ 21/Mar/16 ]

the myth about problems with areas/components default values

Did I mention any? I'm only calling for consistency, whatever we go for.

Comment by Andreas Weder [ 01/Apr/16 ]

I've discussed this again with mgeljic. I have switched views, since I've learned that the proposed solution you've developed, rkovarik, actually explicitly saves a newly created page before showing the page properties. I was under the impression that we have less control over when we save the page.

Under this changed conditions, I'm more in favor of mgeljic's proposal: I'd only create the new page once the user presses "save changes" on the second dialog, also because it aligns this behavior aligned with the one when adding a new component.

Here's the flow I'd like to see realized:
1) We show the "Add page" dialog.

  • It features "page name" and "page template". We no longer show "page title" here.
  • Its default button is called "next" (not "add", "choose" or "save changes").

2) We show the "page properties" dialog

  • It features "page title", "window title", "navigation title", etc.
  • All default values are filled in.
  • Its default button is called "save changes".

3) If I press "save changes", the page is created. If I press "cancel", the page is not created.

For now, we ignore cases where no page properties dialog has been configured. Such technically possible cases would ask for a different button label instead of "next".


Apart from these changes related to the flow and behavior, I'd also like to make additional changes to both dialogs, but I've factored them out into a follow-up issue PAGES-66 to not mix too many things at once. When implementing this change, however, you might want to consider tackling both issues at once.

Comment by Roman Kovařík [ 11/Apr/16 ]

Reopened since it was reverted until MGNLCE-36 is solved.

Comment by Roman Kovařík [ 21/Apr/16 ]

Blocked till M5.4.6 is released.

Comment by Philip Mundt [ 22/Apr/16 ]

This solution is flawed: it will not fire ContentChangedEvent s for the newly created page resulting in

  1. No refresh of the tree and therefore
  2. non-selected new item

Until further notice I will revert the efforts put into the UI tests (I might integrate a similar refactoring of the #addNewPage(...) method though; I had done something similar previously which was not integrated).

Comment by Roman Kovařík [ 25/Apr/16 ]

pmundt Do you have the current branch? It seems that focus/selection works as expected.

Comment by Philip Mundt [ 26/Apr/16 ]

rkovarik yes I can verify, it works on the respective branch. What I had done last week was reverting the reverts which didn't do the trick IIRC.

Comment by Philip Mundt [ 27/Apr/16 ]

Unfortunately, I still believe there a two (minor) issues with this PR:

  1. The second dialog cannot be confirmed by hitting ENTER; instead the preview page action of the currently selected page will be opened.
  2. Due to removal of the title property from the createPage dialog, we end up with scenarios where it is not possible to actually edit the title of a page (see template section in STK demo).
Comment by Roman Kovařík [ 27/Apr/16 ]
  1. https://git.magnolia-cms.com/projects/MODULES/repos/pages/commits/6fde3496de49da5c115f0dbef674e5af233fad8e
  2. You should be able to do this by the rename page dialog.
Comment by Milan Divilek [ 29/Apr/16 ]

Reopen: Following warn is logged after clicking on next button in add page dialog when adding page under the root.

2016-04-29 09:43:21,969 WARN  agnolia.ui.workbench.tree.HierarchicalJcrContainer: Cannot determine parent for itemId: info.magnolia.ui.vaadin.integration.jcr.JcrNewNodeItemId@303012d2: javax.jcr.ItemNotFoundException: Root node doesn't have a parent
Comment by Antonín Juran [ 05/May/16 ]

Isn't updated configuration for create page dialog.

Comment by Roman Kovařík [ 30/May/16 ]

For release notes:
The page dialog is immediately opened when creating the page so the default values are taken into account.

Generated at Mon Feb 12 06:15:14 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.