[MGNLDATA-126] SaveHandler is ignored for subtypes. Created: 04/Jul/11  Updated: 04/Nov/15  Resolved: 04/Nov/15

Status: Closed
Project: Magnolia Data Module (closed)
Component/s: None
Affects Version/s: 1.6.3
Fix Version/s: None

Type: Bug Priority: Neutral
Reporter: Danilo Ghirardelli Assignee: Philipp Bärfuss
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
relation
is related to MGNLDATA-144 Validation does not work for subtype ... Closed
Template:
Acceptance criteria:
Empty
Date of First Response:

 Description   

Each type or subtype has its own dialog definition. If you customize the saveHandler for a type, everything is working correctly, but if you customize the saveHandler for a subtype, the definition is ignored and only the parent type saveHandler is used.
Steps to reproduce:

  • create a new type x, with a subtype y.
  • in the dialog definition, customize the saveHandler for x with a class (Save1 extends DataSaveHandler)
  • in the dialog definition, customize the saveHandler for y with a different class (Save2 extends DataSaveHandler)
  • create a x object using the admin interface, and the called saveHandler is Save1 (which is correct)
  • create a y object under x using the admin interface, the dialog displayed is the right one for the y type, but when you save, the saveHandler called is the x one (Save1) and not the y one (Save2)

I would expect that the saveHandler used when saving y is Save2, not Save1 of x.

The fastest workaround (which I'm using now) is to define a single savehandler for both, and simply check the saving node type to get the right behaviour depending on the type. Not the best but at least works.



 Comments   
Comment by Danilo Ghirardelli [ 04/Jul/11 ]

The workaround I posted does not work when inserting a new element. In that case the type of the new node (obtained with ".getNodeTypeName()") is not set, and defaults to a generic "mgnl:contentNode".

Comment by Michael Mühlebach [ 04/Nov/15 ]

Given the thousands of other issues we have open that are more highly requested, we won't be able to address this issue in the foreseeable future. Instead we will focus on issues with a higher impact, and more votes.
Thanks for taking the time to raise this issue. As you are no doubt aware this issue has been on our backlog for some time now with very little movement.
I'm going to close this to set expectations so the issue doesn't stay open for years with few updates. If the issue is still relevant please feel free to reopen it or create a new issue.

Generated at Mon Feb 12 05:11:37 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.