- From: Roland Merrick <roland_merrick@uk.ibm.com>
- Date: Fri, 8 Dec 2006 09:00:03 +0000
- To: Adrian Baker <adrian@fastmail.net>
- Cc: www-forms <www-forms@w3.org>
- Message-ID: <OF48C04DBB.956F9ECA-ON8025723E.003036D1-8025723E.0031725B@uk.ibm.com>
Greetings Adrian, I believe that the answer to your question is yes. A long time ago I looked at associating an error explanation with a constraint to provide what you seem to be looking for. This would allow you to associate an alert with each constraint MIP as well as with the type MIP. The biggest weakness in this approach though is the problems of explaining which of potentially many schema restrictions have failed. I did have discussion with the XML Schema folks about indicating in the PSVI precisely which restriction failed but did not get to a conclusion. Regards, Roland Tel/Fax: +44 (0)1926-465440 Mobile: +44 (0)77 2520-0620 Adrian Baker <adrian@fastmail.net> 07/12/2006 23:29 To www-forms <www-forms@w3.org> cc Roland Merrick/UK/IBM@IBMGB Subject Re: Styling based on instance data Could the possibility of having multiple constraints also be used to provide a mechanism to link specific alert texts to particular constraints? One irritation I have is deriving a nice specific alert for fields which can be invalid for mulitple reasons (multiple constraints plus a datatype restriction). Adrian Roland Merrick wrote: Greetings Mark, I acrefully avoided the how in my response I was just describing another use case. However, on the subject of how I tend to agree with the approach you describe. XForms 1.0 had a restriction that there could only be one MIP of a particular types associated with an instance data node. This was reasonable for all the MIPs except @constraint but kept the rule simple. I would like to see the restriction of a single @constraint being lifted and at the same time introduce a new attribute along the lines you suggest that there can also be multiples of. This would allow an author to specify multiple constraints and multiple states that can be used for "styling". <xf:bind id="overdue" nodeset="books/book" state="today() > @due" /> If I then wanted to add another state, for eample hardcover vs softcover I could do that as well without a need to touch the original binding. <xf:bind id="cover" nodeset="books/book" state="@cover = 'hard'" /> The styles would then be linked to the MIP@state of a particular bind ID. Regards, Roland Tel/Fax: +44 (0)1926-465440 Mobile: +44 (0)77 2520-0620 "Mark Birbeck" <mark.birbeck@x-port.net> Sent by: www-forms-request@w3.org 01/12/2006 15:40 Please respond to mark.birbeck@x-port.net To www-forms <www-forms@w3.org> cc www-forms-request@w3.org Subject Re: Styling based on instance data Hi Roland, > I would agree that there are cases where styling dependent > on the value would be useful. A situation I have encountered is the need to style > negative numbers differently to positive numbers. We could still keep this as styling based on 'state' though, with negative and positive being different states. Myself and Paul Butcher (one of my colleagues) tested to see if a generic solution based on state was workable, and found that it probably could be done. I'll try to find the details, but it essentially went like this; if you think of the MIPs, such as relevant, readonly, and so on, they all control a pair of events and a pair of CSS pseudo-classes. To make this generic all we need is a way to describe these two pairs. So lets say that we have a system that has a business rule concerning whether a library book is overdue or not; we know that we'd like a pair of events called "xforms-mip-overdue-on" and "xforms-mip-overdue-off", say, and we'd also like some pseudo classes like ':mip-overdue-on' and ':mip-overdue-off' to allow us to style data that is in this state. By making the names of the events and pseudo-classes follow a clearly defined pattern, we could just use a single attribute to specify the whole thing: <style type="text/css"> :mip-overdue-on { color: red; } </style> <xf:bind nodeset="books/book" overdue="today() > @due" /> It's probably not a good idea to allow any old attribute on 'bind', so one possibility would be to put these 'soft MIP' attributes into a different namespace: <xf:bind nodeset="books/book" mip:overdue="today() > @due" /> Any attribute in this namespace would be treated as a 'soft' MIP, and the events and pseudo-classes created accordingly, with the default names. There are other ways to express the mark-up, but I'd have to dig up some of the (very old) notes that myself and Paul made to recall the ones that we came up with. I do remember that we played with having a new element that defines the names of the events and pseudo-classes, but that may be more powerfull that is needed. Anyway, I thought it worth posting these thoughts since they might spark some ideas amongst others. Regards, Mark -- Mark Birbeck CEO x-port.net Ltd. e: Mark.Birbeck@x-port.net t: +44 (0) 20 7689 9232 w: http://www.formsPlayer.com/ b: http://internet-apps.blogspot.com/ Download our XForms processor from http://www.formsPlayer.com/
Received on Friday, 8 December 2006 09:02:50 UTC