bug #7223
closedReferenceEditor: disable fields depending on the Reference type
Added by Andreas Kohlbecker about 6 years ago. Updated over 3 years ago.
100%
Description
e.g.: hide authorship if type = journal
The Taxonomic Editor behaves the same but the information which field to show for which ReferenceType
is quite distributed The method void eu.etaxonomy.taxeditor.ui.section.reference.ReferenceDetailElement.createControls(ICdmFormElement formElement, Reference entity, int style)
is a good starting point when you are interested into investigating this implementation.
The needed information can be retrieves from the Reference interface:
IPublicationBase:
- publisher
- placePublished
- doi
IReference:
- URI
- DatePublished
- abbrevTitle
- title
- authorship
- type
IVolumeReference:
- volume
ISection:
- pages
- inReference
IPrintedUnitBase (IPublicationBase, ISection, IVolumeReference):
- inSeries -> inReference
- editor
- seriesPart
IArticle (ISection, IVolumeReference):
- seriesPart
- inJournal -> inReference
- inJournal -> inReference
- doi
IBook (IPrintedUnitBase):
- Edition
- Isbn
IBookSection (ISection):
- inBook --> inReference
InProceedings (ISection):
- InProceedings -> inReference
IJournal (IPublicationBase):
- seriesPart
- inJournal -> inReference
- doi
IPrintSeries (IPublicationBase):
- publisher
- placePublished
- Doi
IThesis:
- school (Institution)
Related issues
Updated by Andreas Müller about 6 years ago
- Target version changed from Release 4.14 to Release 5.0
Updated by Andreas Kohlbecker almost 6 years ago
- Target version changed from Release 5.0 to Release 5.1
Updated by Andreas Kohlbecker almost 6 years ago
- Priority changed from New to Highest
Updated by Andreas Kohlbecker almost 6 years ago
Hi all,
the ReferencePropertyDefinitions
would also be useful for the taxeditor to unclutter ReferenceDetailElement.createControls(...)
and other related code. (see #7479)
Andreas
Updated by Andreas Kohlbecker almost 6 years ago
- Related to task #7479: consider a cleaner implementation of adaptive reference field visibility added
Updated by Andreas Kohlbecker almost 6 years ago
Now that the fields are switched visible and unvisible it turns out that this can cause layout problems. These need to be solved before this issue can be closed.
Updated by Andreas Kohlbecker almost 6 years ago
- Status changed from New to Resolved
- Assignee changed from Andreas Kohlbecker to Wolf-Henning Kusber
- % Done changed from 30 to 50
The layout works again. Even if there is still a lot of potential for improvements I think that this issue is solved and that it can be closed.
@Henning: Could you please do the review of this improvement to the ReferenceEditor?
Updated by Wolf-Henning Kusber over 5 years ago
- Assignee changed from Wolf-Henning Kusber to Andreas Kohlbecker
Reference Editor of Vaadin (2018-11-02) in square brackets: Differences in the TaxEditor
Article
Date published: ok
Title: ok [TaxEditor: also a nomencl. Title is given, in a few cases in TL2 there is an abbreviated title is given]
Authors: ok
In-reference: ok
Series: not sure if needed. Is there a use case? [TaxEditor: also available, ask other projects if needed]
Volume: ok
Uri: ok
MISSING IN VAADIN: DOI [also missing in TaxEditor, this seems to be an issue]
Journal
Date published: needed for the runtime of a journal? E.g. 1945-1990??
Title: ok
Nomenclatural title: ok
Authors: NOT NEEDED [also available in TaxEditor]
In-reference: NOT NEEDED [not in TaxEditor]
Place published: ok (but changes often in the runtime)
Publisher: ok (but changes often in the runtime)
ISSN: ok (nice to have: two fields for print and e-journal, respective)
DOI: In VAADIN NOT NEEDED [not in TaxEditor]
Uri: ok
Book section (Layout in Vaadin narrow)
Date published: just needed, if parts of a book are printed independently
MISSING: Title [available in TaxEditor]
Authors: ok
In-reference: ok
Pages: ok
URI: ok
MISSING: DOI [also missing in TaxEditor, this seems to be an issue]
Book
Date published: ok
Title: okay
Nomenclatural title: ok
Authors: ok
In-reference: ok [in TaxEditor “In Series”]
Series: (Discuss: isn’t In-reference the right place to store and select a series, rather than in a string?) [also available in TaxEditor]
Volume: ok
Pages: ok
Edition: ok
Place published: ok
Publisher: ok
Editor: ok (discuss: person/team atomized?) [same in TaxEditor]
ISBN: ok (nice to have: two fields for print and e-journal, respective)
DOI: ok [MISSING in TaxEditor, this might be an issue in future]
Uri: ok
Inproceedings (might be renamed as Proceedings section)
Date published: just needed, if parts of a book are printed independently
Title: ok
Authors: ok
In-reference: ok
Series: NOT NEEDED [also available in TaxEditor ]
Pages: ok
DOI: ok
URI: ok [MISSING in TaxEditor, this might be an issue in future]
Proceedings
See Book, except for “Edition” but two editions of proceedings cannot be excluded…
ISBN: [MISSING in TaxEditor]
Printseries
Date published: needed for the runtime of a print series? E.g. 1945-1990??
Title: ok
MISSING: Nomenclatural title
Authors: needed? Maybe in a special case
In-reference: Maybe for a print series within a print series?
MISSING Edition: Discuss: this might be useful, if there are editions of print series, such as Adolf Engler’s Syllabus, do not know if we really need this.
Place published: ok
Publisher: ok
Editor: ok (discuss: person/team atomized?)
ISBN: ok (nice to have: two fields for print and e-journal, respective) [MISSING in TaxEditor]
DOI: NEEDED? [not in TaxEditor]
Uri: ok (but changes often in the runtime)
Thesis
Okay, except of MISSING: School [see TaxEditor]
Discuss: A thesis is an effectively published book (see book) or a not effectively published book, an Internet resource, or a microfiche. How to deal with this? Should the Reference type called “Thesis (not effectively published)? If not, we need a “not published” flag, if applicable a text field for the reason. The thing is, that any thesis has a date, a place, sometimes a publisher, even it is not published effectively. This is important, because a lot of novelties have been printed in not effectively published theses. Alternatively we could leave “Thesis” as is, and flag each nomenclatural act as invalid with reference to the respective provisions of the ICN, that this was not effectively published. In Vaadin “School” might be stored under Publisher.
Updated by Andreas Kohlbecker over 5 years ago
- Related to bug #7480: ReferenceEditor misses institution, organization and school fields added
Updated by Andreas Kohlbecker over 5 years ago
except of the institution, organization and school fields which are handled in #7480 all issues named in this ticket should be fixed. There are furthermore some fields which need further discussion, but this is a topic for the cdm in general and should not block us from closing this issue. A new ticket should be opened if needed.
Updated by Andreas Kohlbecker over 5 years ago
- Related to feature request #7655: References Editor: book section offers title field added
Updated by Andreas Müller over 5 years ago
Some notes on the above:
DOIs: are available but just not implemented yet #3767
Date published for Journals and Printseries: Date published is NOT meant for the runtime but for an exact date when a publication was published or a period if this date can not be defined exactly. I do not see the necessity of having a "runtime" attribtue but if needed we should use another attribute due to the different semantics. But as we are not a reference managing tool I think there is no need for this.
The methods will be removed from the according interfaces.
Journals Authors: not needed, I agree, will be removed from the interface
Book Series: (Discuss: isn’t In-reference the right place to store and select a series, rather than in a string?): often you only have information like "ser. 2". The CDM philosophy is that a book should always be a possible endpoint in the reference hierarchy holding all informations needed for correct formatting. PrintSeries might only be an additional possiblity to group books together. This is also for performance reaons as otherwise you may need to initialize up to 4 references to format a single reference.
Editor: ok (discuss: person/team atomized?): this is under discussion in CDM, not yet sure if it will be implemented, but maybe it will
ISBN: correct handling of multiple ISBN definetly needs further discussion as references may have multiple ISBN, and especially the ISBN for the e-Version is an important issue
Print Series - Edition : Not needed, can be handled via title as print series is anyway only meant for grouping publications and not for formatting.
Uri: currently available for most types but will be removed in future except for websites (and maybe databases). Links to online available references should not be stored in URI but in the new "ExternalLink" which will be related as a collection of external links available for this publication. This is because there might be multiple links available for the same reference and it also allows a description what exactly stands the link for. Currently this is already available for the OriginalSource class to link to sources (e.g. single pages in a reference).
InProceedings - Series: Correct, that this is not needed. Also it is not available in the IInProceedings interface so I wonder how it made it's way into the TaxEditor. Please remove.
Proceedings - ISBN: correct, this is missing as proceedings are not inheriting from IBook though they are mostly books, I added ISBN to IProceedings
PrintSeries - Nomenclatural title: not necessarily needed for formatting, but nice to have; it is already available in IPrintSeries via inheritence from IReference, so we should implement it in TaxEditor
PrintSeries - authors: rejected, this is not needed and may lead to confusion, should always be stored with the concrete publication (book, article, ...)
Print-Series: In-reference: no need, leads to confusion
Updated by Andreas Müller over 5 years ago
- Related to bug #7913: Remove authorship from IJournal and IPrintSeries added
Updated by Andreas Müller over 5 years ago
- Related to feature request #7914: Add ISBN to IProceedings added
Updated by Andreas Kohlbecker over 5 years ago
The notes added in comment 19 should go into a separate taxeditor ticket since this ticket here is mainly focused on the vaadin reference editor.
I think it is also worth mentioning the class eu.etaxonomy.cdm.model.reference.ReferencePropertyDefinitions
which has been created to allow UIs to adapt to ReferenceType changes dynamically. The ReferenceType specific interfaces like IJournal
, ... , are not very useful in this context and are actually not used at all except for the methods in the Reference class. Maybe we should consider to remove these interfaces.
Updated by Andreas Müller over 5 years ago
- Related to bug #7915: Remove date published from journals and print series added
Updated by Andreas Müller over 5 years ago
Maybe we should also remove DOI from journal and print series.
Updated by Andreas Müller over 5 years ago
Andreas Kohlbecker wrote:
The notes added in comment 19 should go into a separate taxeditor ticket since this ticket here is mainly focused on the vaadin reference editor.
The comments are not TaxEditor specific. They are general explaining CDM types. Implementation should be the same for Vaadin or TaxEditor. For specific issues seperate CDM tickets have be created.
Updated by Andreas Müller over 5 years ago
Andreas Kohlbecker wrote:
I think it is also worth mentioning the class
eu.etaxonomy.cdm.model.reference.ReferencePropertyDefinitions
which has been created to allow UIs to adapt to ReferenceType changes dynamically. The ReferenceType specific interfaces likeIJournal
, ... , are not very useful in this context and are actually not used at all except for the methods in the Reference class. Maybe we should consider to remove these interfaces.
I don't like the fact that we have this information now at 2 different places. This makes changes like the one I implemented for the interfaces difficult to maintain. ReferencePropertyDefinitions uses hardcoded strings, why do we not use reflection on the interfaces? This way both systems can be easily maintained and are always up-to-date. At least tests are a strict requirement for hardcoded strings which immediately show the requirement to change the code if something changes elsewhere.
In future we may also use the new property path framework, once it is developed.
Interfaces are for both documentation (e.g. https://cybertaxonomy.eu/cdm/latest/index.htm?goto=10:283) and type save programming (e.g. programming an import by using the interfaces prevents the programmer from doing incorrect mappings). Therefore they should not be deleted.
Updated by Andreas Kohlbecker over 5 years ago
Andreas Müller wrote:
Andreas Kohlbecker wrote:
The notes added in comment 19 should go into a separate taxeditor ticket since this ticket here is mainly focused on the vaadin reference editor.
The comments are not TaxEditor specific. They are general explaining CDM types. Implementation should be the same for Vaadin or TaxEditor. For specific issues seperate CDM tickets have be created.
The comments are not TaxEditor specific.
Ok, ok, agreed!!! But this Issue still is dedicated to the vaadin reference editor and it will be closed once the review regarding this editor has been completed.
Updated by Andreas Kohlbecker over 5 years ago
Andreas Müller wrote:
Andreas Kohlbecker wrote:
I think it is also worth mentioning the class
eu.etaxonomy.cdm.model.reference.ReferencePropertyDefinitions
which has been created to allow UIs to adapt to ReferenceType changes dynamically. The ReferenceType specific interfaces likeIJournal
, ... , are not very useful in this context and are actually not used at all except for the methods in the Reference class. Maybe we should consider to remove these interfaces.I don't like the fact that we have this information now at 2 different places. This makes changes like the one I implemented for the interfaces difficult to maintain. ReferencePropertyDefinitions uses hardcoded strings, why do we not use reflection on the interfaces? This way both systems can be easily maintained and are always up-to-date. At least tests are a strict requirement for hardcoded strings which immediately show the requirement to change the code if something changes elsewhere.
In future we may also use the new property path framework, once it is developed.
Interfaces are for both documentation (e.g. https://cybertaxonomy.eu/cdm/latest/index.htm?goto=10:283) and type save programming (e.g. programming an import by using the interfaces prevents the programmer from doing incorrect mappings). Therefore they should not be deleted.
Thank you for mentioning cdmlib-apps
and the UML based documentation on the cdm model. I really thought that these reference interfaces are not used at all. Removing unused code would have reduced the efforts in maintaining code changes. From the broader view on the usage of these interfaces it is clear that we need to keem 'em.
The type level java doc of ReferencePropertyDefinitions
already mentions the need to overcome the duplication if the information provided by the interfaces and by this class. Using pure reflection to obtain the needed information will not be sufficient, though. For example ISection
declares the property inReference
, IInProceedings
which extends ISection
declares the property inProceedings
. From using pure reflection the Sections would have both, inReference
and inProceedings
even if inProceedings
is just a "renaming" of the property inReference
.
For dynamically adapting UIs to reference type changes more information is needed. The information that inProceedings
is referring to the same field just with another "label" is required. So it is obvious that we need an additional source of information. Creating a method level annotation which is evaluated by ReferencePropertyDefinitions
could be one solution to this problem.
=> #8255
Updated by Andreas Kohlbecker over 5 years ago
InProceedings - Series: Correct, that this is not needed.
Also it is not available in the IInProceedings interface so I wonder how it made it's way into the TaxEditor. Please remove.
The inSeries
comes from ISection
which is extended by IInProceedings
Updated by Andreas Kohlbecker over 5 years ago
- Copied to task #7918: Revision of reference type specific properties added
Updated by Andreas Kohlbecker over 5 years ago
I now moved the model discussion to #7918.
Updated by Andreas Kohlbecker over 5 years ago
- Assignee changed from Andreas Kohlbecker to Wolf-Henning Kusber
completed, please review vaadin reference editor
Updated by Andreas Müller over 5 years ago
After discussion with Henning DOI should not be available for journals and print series.
And I guess also for personal communication no DOI should be available.
Updated by Andreas Müller over 5 years ago
- Related to feature request #7982: [Rule] Validate correct usage of reference attributes for reference types. added
Updated by Andreas Müller almost 5 years ago
- Related to bug #7953: Book in BookSeries: incomplete titleCache misses series title added
Updated by Wolf-Henning Kusber almost 5 years ago
"And I guess also for personal communication no DOI should be available." correct.
Updated by Wolf-Henning Kusber almost 5 years ago
- Assignee changed from Wolf-Henning Kusber to Andreas Müller
Updated by Andreas Müller almost 5 years ago
- Status changed from Resolved to Feedback
- Assignee changed from Andreas Müller to Andreas Kohlbecker
Personal Communication has no DOI neither in the interfaces nor in TaxEditor. If this is available in vaadin this is not correct and should be corrected there. One reason why we should unify the property definitions and the reference interfaces (#8255)
Updated by Andreas Müller almost 5 years ago
- Copied to feature request #8255: Unify ReferencePropertyDefinitions and reference interfaces added
Updated by Andreas Kohlbecker over 3 years ago
- Status changed from Feedback to Closed
- % Done changed from 50 to 100
Andreas Müller wrote:
Personal Communication has no DOI neither in the interfaces nor in TaxEditor. If this is available in vaadin this is not correct and should be corrected there. One reason why we should unify the property definitions and the reference interfaces (#8255)
ReferencePropertyDefinition for Personal Communication fixed: 46f7b66dbc
I decided to keep this ticket in the original milestone as Personal Communication is not currently being used, so this change is rather for completeness than for functionality in use.