Skip to content
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

Per-form/global settings for minimal Calculated Value field #4008

Closed
ebruchez opened this issue Mar 28, 2019 · 13 comments
Closed

Per-form/global settings for minimal Calculated Value field #4008

ebruchez opened this issue Mar 28, 2019 · 13 comments

Comments

@ebruchez
Copy link
Collaborator

@ebruchez ebruchez commented Mar 28, 2019

Following #4004.

@ebruchez ebruchez self-assigned this Mar 28, 2019
@ebruchez ebruchez added this to To review in Orbeon Forms 2019.1 via automation Mar 28, 2019
@avernet

This comment has been minimized.

Copy link
Collaborator

@avernet avernet commented Apr 18, 2019

@avernet

This comment has been minimized.

Copy link
Collaborator

@avernet avernet commented Apr 18, 2019

@avernet

This comment has been minimized.

Copy link
Collaborator

@avernet avernet commented May 27, 2019

@ebruchez ebruchez moved this from To review to To do in Orbeon Forms 2019.1 May 30, 2019
@ahenket

This comment has been minimized.

Copy link
Contributor

@ahenket ahenket commented Jun 17, 2019

I've managed to circumvent the issue by eliminating xf:label under xf:output elements.

@ebruchez ebruchez moved this from To do to In progress in Orbeon Forms 2019.1 Jun 17, 2019
@ebruchez

This comment has been minimized.

Copy link
Collaborator Author

@ebruchez ebruchez commented Jun 18, 2019

To recapitulate, following #3804 and #4004. We now (2018.2.3 and 2019.1) have an option in Form Builder. But we'd like an option which is per form.

To render the field without borders, we use appearance="mimimal", which is implemented partially in CSS, but also partially natively to place the xforms-field vs. the xforms-output-output class.

If the user selected "Calculated Value Without Border" for a given field, it makes sense that this is final. So we are concerned about the case where there is no minimal appearance present.

@ahenket

This comment has been minimized.

Copy link
Contributor

@ahenket ahenket commented Jun 19, 2019

I'm not sure anymore we are talking about the same thing. This fragment causes the issue:

    <xforms:output ref="$resources/Is-private" class="padinline" style="margin-left: 5px;">
        <xforms:label ref="$resources/Is-private-hint" class="hidden"/>
        <xforms:help ref="$resources/Is-private-hint"/>
    </xforms:output>

Adding appearance="minimal" in either the xforms:output or the xforms:label does not make any difference. Removing the forms:label altogether restores normal behavior. Note how the text "Is private?" has very different markup from "Contains reusable content?". The latter has the xforms:label disabled.

image

@ebruchez

This comment has been minimized.

Copy link
Collaborator Author

@ebruchez ebruchez commented Jun 19, 2019

This is probably explained because the minimal appearance was introduced with #4004, which was done after Orbeon Forms 2018.2.1 CE. You can see it in action here.

@ahenket

This comment has been minimized.

Copy link
Contributor

@ahenket ahenket commented Jun 20, 2019

But 2018.2.1 broke xf:output+xf:label for us and there is no CE version after 2018.2.1 yet. Is that bug (can't see it otherwise) still on the list to fix? I.e. to the best of my knowledge, I don't have calculated fields, but nonetheless it is displayed as such.

@ebruchez

This comment has been minimized.

Copy link
Collaborator Author

@ebruchez ebruchez commented Jun 20, 2019

What we call a "calculated field" is an <xf:output> with an <xf:label>. Most uses of <xf:output> are just to produce some content dynamically. But once you add an <xf:label> to an <xf:output>, conceptually it becomes something different, more like a form field. This is similar to the HTML 5 <output> element, which was also designed to show the result of calculations - and which we use in the resulting markup too.

The above is the whole rationale for changing the appearance and behavior of <xf:output> with <xf:label> in the first place.

In your case, in the fragement you show above, what is the purpose of the nested <xforms:label>? Maybe that <xforms:label> shouldn't be there in the first place.

But even with it, the problem for you, in the end, is one of CSS layout, isn't it? If so, a few lines of CSS should be enough to remove the border and background.

@ahenket

This comment has been minimized.

Copy link
Contributor

@ahenket ahenket commented Jun 20, 2019

Thank you for that much appreciated explanation.

We added xforms:label because the nvdl was complaining without it, about xforms:hint/xforms:help. We really don't want to see those labels, hence class=hidden. So given that we should probably just live with the nvdl complaints that impose no real world error in Orbeon. I've already removed xforms:label from all our forms.

As a side note: we also hide almost all (xforms:output|xforms:input|xforms:textarea)/xforms:label by default. Somehow they never render the way we want them to render. They serve a purpose in allowing the error-summary to bind to something, and in preventing nvdl errors, but are otherwise superfluous code.

@ebruchez

This comment has been minimized.

Copy link
Collaborator Author

@ebruchez ebruchez commented Jun 28, 2019

If the user selected "Calculated Value Without Border" for a given field, it makes sense that this is final. So we are concerned about the case where there is no minimal appearance present

For settings at the form level, we have:

  • properties
  • form-level

For controls like fr:number:

  • properties
  • form-level
  • control-level

The recent "Simplified appearance" for sections and grids has:

  • properties
  • form-level

In fact, it should also be:

  • properties
  • form-level
  • section/grid-level

Now ideally, for the appearance of output, we would also have:

  • properties
  • form-level
  • control level

For controls, we implement the multi-level setting by using the fr:component-param-value() function. However, we don't have yet a mechanism to handle appearances this way as they are static.

We could do this by having Form Runner place the appearances at runtime when needed. We already do this, in fact, to handle section/grid appearances via oxf.xforms.xbl.fr.(section|grid).appearance.

So we would add something like this and support:

  • property oxf.xforms.xbl.fr.output.appearance
  • form-level
  • control-level

Issues:

  • at the control level, we don't have default/full/minimal and we only have a checkbox to say minimal
    • Q: Could we create two more XBL entries, one for full, one for default?
  • ideally we would support fr:created-with-or-newer('2018.2'), but since this has to run in XSLT, we probably cannot do it this way
@ebruchez

This comment has been minimized.

Copy link
Collaborator Author

@ebruchez ebruchez commented Jun 28, 2019

Issues:

  • In section-and-grid.xsl I can try out that logic. It works at runtime, but not at design-time. We need another mechanism to handle the design-time.
  • To edit the appearances, we might need a custom editor as we can't use the appearance selector in the form settings. That is, unless we build a general mechanism to pick a default appearance for controls, which might not be a bad idea, except that it's tight for 2019.1.
@ebruchez

This comment has been minimized.

Copy link
Collaborator Author

@ebruchez ebruchez commented Jun 28, 2019

For 2019.1, we can do just the first step:

  • handle form-level properties and defaults based on form creation version
  • have the appearance selector at the control level for minimal, full, and default
  • push the UI for the setting at the form level to a later version (2019.2)
ebruchez added a commit that referenced this issue Jun 28, 2019
…full`, and default at control level
@ebruchez ebruchez closed this Jun 28, 2019
Orbeon Forms 2019.1 automation moved this from In progress to Done Jun 28, 2019
@ebruchez ebruchez added this to To do in Orbeon Forms 2018.2.4 via automation Jun 28, 2019
@ebruchez ebruchez moved this from To do to Done in Orbeon Forms 2018.2.4 Jun 28, 2019
ebruchez added a commit that referenced this issue Aug 2, 2019
ebruchez added a commit that referenced this issue Aug 2, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
3 participants
You can’t perform that action at this time.