If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Support UI bindings for derived datatypes

RESOLVED FIXED

Status

Core Graveyard
XForms
RESOLVED FIXED
12 years ago
a year ago

People

(Reporter: Allan Beaufour, Assigned: aaronr)

Tracking

({fixed1.8.0.8, fixed1.8.1.1})

Trunk
fixed1.8.0.8, fixed1.8.1.1
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments, 1 obsolete attachment)

1.87 KB, application/xhtml+xml
Details
7.65 KB, patch
surkov
: review+
smaug
: review+
Details | Diff | Splinter Review
(Reporter)

Description

12 years ago
As it is now, we need to target each XML Schema type directly in CSS, like we do for f.x. upload:
---- CUT ---
upload {
  -moz-binding: url('chrome://xforms/content/xforms.xml#xformswidget-upload-disabled');
}

upload[mozType|type="http://www.w3.org/2001/XMLSchema#anyURI"] {
  -moz-binding: url('chrome://xforms/content/xforms.xml#xformswidget-upload');
}
---- CUT ---

Problem is that f.x. range has a lot of datatypes that it supports (see bug 316354). So with our current design we would need a specific binding for each (and would still not support user defined types). That's not a good solution.

This means we need a method to find the primitive datatype that a datatype is derived by restrition from. I've tried to stay at a distance from XML Schema, so I do not know 1) if that's possible at all, and 2) how expensive that will be.

Assuming that its possible, I see two solutions:
1) Continue along the same path, and use two attribute to bind via CSS:
A @type (as we do now) and a @baseType. @baseType should then be set to the primitive datatype the @type is derived by restriction from.

2) Have the basetype check in the C++ part of f.x. range
We could then find the basetype, and set the @type attribute to that instead, or "invalid" if it's unsupported. A problem could be if somebody wanted to do a range for an abitrary data type (although this is invalid per the spec).

(another solution could be to push the responsability to the UI control, but I'm not keen on that)

Assuming that we can figure out the basetype, I'm for solution 1).
(Reporter)

Comment 1

12 years ago
(In reply to comment #0)
> Assuming that its possible, I see two solutions:
> 1) Continue along the same path, and use two attribute to bind via CSS:
> A @type (as we do now) and a @baseType. @baseType should then be set to the
> primitive datatype the @type is derived by restriction from.

So Doron, how hard would this be to support?
(Reporter)

Comment 2

12 years ago
Created attachment 218799 [details]
Testcase
(Reporter)

Updated

12 years ago
Assignee: aaronr → xforms
(Reporter)

Comment 3

11 years ago
*** Bug 340894 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 4

11 years ago
after bug 313313 goes in, we should be able to do this using that mechanism, right?  Just have to pick a place (like refresh) to determine if the builtin type is acceptable and then change the .css to look for mozType:supportedtype="yes".
(Assignee)

Updated

11 years ago
Depends on: 313313
(Assignee)

Updated

11 years ago
Blocks: 331984

Comment 5

11 years ago
*** Bug 339660 has been marked as a duplicate of this bug. ***

Comment 6

11 years ago
Now we can use @typelist attribute to add binding to xforms controls. The approach I guess  will work fine for controls like upload since it can be bound to xsd:anyURI, xsd:base64Binary or xsd:hexBinary types only. But I don't see how we can use @typelist approach for controls like input since it can be bound to any type excepting xsd:base64Binary, xsd:hexBinary types.
(Assignee)

Comment 7

11 years ago
(In reply to comment #6)
> Now we can use @typelist attribute to add binding to xforms controls. The
> approach I guess  will work fine for controls like upload since it can be bound
> to xsd:anyURI, xsd:base64Binary or xsd:hexBinary types only. But I don't see
> how we can use @typelist approach for controls like input since it can be bound
> to any type excepting xsd:base64Binary, xsd:hexBinary types.
> 

I've already handled the case of xf:input by creating a styling rule for xf:input that will match xsd:base64Binary and xsd:hexBinary (using mozType:typeList) and made it display:none;

Comment 8

11 years ago
(In reply to comment #7)
> (In reply to comment #6)
> > Now we can use @typelist attribute to add binding to xforms controls. The
> > approach I guess  will work fine for controls like upload since it can be bound
> > to xsd:anyURI, xsd:base64Binary or xsd:hexBinary types only. But I don't see
> > how we can use @typelist approach for controls like input since it can be bound
> > to any type excepting xsd:base64Binary, xsd:hexBinary types.
> > 
> 
> I've already handled the case of xf:input by creating a styling rule for
> xf:input that will match xsd:base64Binary and xsd:hexBinary (using
> mozType:typeList) and made it display:none;
> 

The problem is I guess we should not have any binding for those elements.
(Assignee)

Comment 9

11 years ago
(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
> > > Now we can use @typelist attribute to add binding to xforms controls. The
> > > approach I guess  will work fine for controls like upload since it can be bound
> > > to xsd:anyURI, xsd:base64Binary or xsd:hexBinary types only. But I don't see
> > > how we can use @typelist approach for controls like input since it can be bound
> > > to any type excepting xsd:base64Binary, xsd:hexBinary types.
> > > 
> > 
> > I've already handled the case of xf:input by creating a styling rule for
> > xf:input that will match xsd:base64Binary and xsd:hexBinary (using
> > mozType:typeList) and made it display:none;
> > 
> 
> The problem is I guess we should not have any binding for those elements.
> 

Then you are saying we need to back out 313313 and stop using mozType:typeList, right?

Comment 10

11 years ago
(In reply to comment #9)
> 
> Then you are saying we need to back out 313313 and stop using mozType:typeList,
> right?
> 

In no circumstances. @typelist is necessary thing. I'd like to see them both. So @typelist we should use to add binding for certain type, @supportedtype="false" we should use to hide control and remove binding. With @supportedtype xforms.css will be much cleaner.

xf|*:not([moztype|supportedtype]) {
  -moz-binding: url('');
  display: none;
}

Lines above will replace huge count of lines that you use for example in patch of bug 331984.

Though, probably we should use @allowedtype or something else?
(Assignee)

Comment 11

11 years ago
(In reply to comment #10)
> (In reply to comment #9)
> > 
> > Then you are saying we need to back out 313313 and stop using mozType:typeList,
> > right?
> > 
> 
> In no circumstances. @typelist is necessary thing. I'd like to see them both.
> So @typelist we should use to add binding for certain type,
> @supportedtype="false" we should use to hide control and remove binding. With
> @supportedtype xforms.css will be much cleaner.
> 
> xf|*:not([moztype|supportedtype]) {
>   -moz-binding: url('');
>   display: none;
> }
> 
> Lines above will replace huge count of lines that you use for example in patch
> of bug 331984.
> 
> Though, probably we should use @allowedtype or something else?
> 

Made a patch for bug 331984 that uses this approach, though using @rejectedtype instead.  I thought it was easier to just have this attribute on the controls that were bound to the bad type rather than putting @allowedtype on all of the controls that have a 'good' type.
Assignee: xforms → aaronr
(Assignee)

Updated

11 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 12

11 years ago
I've checked in bug 331984 that implements @rejectedtype.  Allan/Alex, does that fulfill the requirements of this bug?  Can we close this bug?
No longer blocks: 331984
Depends on: 331984

Comment 13

11 years ago
(In reply to comment #12)
> I've checked in bug 331984 that implements @rejectedtype.  Allan/Alex, does
> that fulfill the requirements of this bug?  Can we close this bug?
> 

I guess no. Many bindings use @type attribute instead @typelist. I can assume this bug should fix it.

Updated

11 years ago
Blocks: 334603
(Assignee)

Comment 14

11 years ago
Created attachment 241847 [details] [diff] [review]
patch 1

This patch changes every binding we have to use mozType|typelist rather than mozType|type.  In this way we'll apply the correct binding even if the bound type is derived from the builtin type that we are basing our binding on.
Attachment #241847 - Flags: review?(surkov.alexander)
(Assignee)

Updated

11 years ago
Attachment #241847 - Flags: review?(Olli.Pettay)

Comment 15

11 years ago
Looks good but you should remove XXX comment:
XXX: We should support controls for derived types too (bug 316691).
(Assignee)

Comment 16

11 years ago
Created attachment 241852 [details] [diff] [review]
patch 2

fixes Alex's comment
Attachment #241847 - Attachment is obsolete: true
Attachment #241852 - Flags: review?(surkov.alexander)
Attachment #241847 - Flags: review?(surkov.alexander)
Attachment #241847 - Flags: review?(Olli.Pettay)
(Assignee)

Updated

11 years ago
Attachment #241852 - Flags: review?(Olli.Pettay)

Updated

11 years ago
Attachment #241852 - Flags: review?(surkov.alexander) → review+

Updated

11 years ago
Attachment #241852 - Flags: review?(Olli.Pettay) → review+
(Assignee)

Comment 17

11 years ago
checked into trunk on 10/11
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Whiteboard: xf-to-branch
(Assignee)

Comment 18

11 years ago
checked into 1.8.0 branch on 2006/10/11
Keywords: fixed1.8.0.8
(Assignee)

Comment 19

11 years ago
checked into 1.8 branch on 2006/11/21
Keywords: fixed1.8.1.1
Whiteboard: xf-to-branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.