-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
include expression/extent in filter_put expression template, include perfDuration in HTML output; fixes #158 #179
Conversation
Hi @peterprovaznik , could you please rebase your branch on develop and force push? There have been some updates to the test dependencies #180 which should fix the failing tests here. |
c162551
to
dc07245
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@daniel-jettka and I were just having a look and found that
-
<extent>
was saved to XML and displayed as HTML properly -
<perfDuration>
was saved to XML and displayed as HTML properly WHEN it was entered on the highest (i.e. work level?) expression -
<perfDuration>
was saved to XML BUT NOT displayed as HTML properly when entered on the component level (e.g.expression/componentList/expression/perfDuration
)
Thanks for reviewing! I have added the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just tested and can confirm that both duration and extent are saved as XML and displayed as HTML properly. Many thanks!
"extent" was not part of the list of apply-templates instructions in the expression template, which resulted in it being removed post-
filter_put.xsl
.Clemens (@gucl-mu) insists (and I tend to agree) that extent should really have both
@quantity
and@unit
(which would require the list of supported units inunit-select.xml
to be extended) to be useful. This, however, would be a non-trivial change in several places which in my opinion would unreasonably widen the scope of this PR (and should have a PR of its own).I have also noticed that "height" is hard-coded in the
xf:setvalue
inunit-select.xml
, which is most likely erroneous (since this is also used for e.g. width); I have, however, since this is not directly related to the issue at hand, decided not to change it here (originally I did, then tests failed, then I reverted it, tests still failed, then I realized it should most likely be handled separately).