W3C home > Mailing lists > Public > www-forms@w3.org > December 2006

Re: Styling based on instance data

From: Roland Merrick <roland_merrick@uk.ibm.com>
Date: Fri, 8 Dec 2006 11:43:21 +0000
To: mark.birbeck@x-port.net
Cc: mark.birbeck@gmail.com, www-forms <www-forms@w3.org>, www-forms-request@w3.org
Message-ID: <OF94386FBF.9CE78BFE-ON8025723E.003F0322-8025723E.004065DE@uk.ibm.com>
Greetings Mark, I'm a little confused. In what way doesn't it fail to meet 
your needs? It doesn't seem that different to your original suggestion. If 
I understand correctly, you suggested a "state" in :

<xf:bind nodeset="books/book" overdue="today() &gt; @due" />

with a name of xf:overdue which is of style boolean. With a variation to 
allow any attribute such as mip:overdue.

The CSS would then be bound to the state of those variables.

I thought I was suggesting something similar but the state would be 
qualified by the ID of the bind, so the style would be more like:

    <style type="text/css">
      #overdue:state-on { color: red; }
    </style>

So I do not see any intrinsic difference or why it would not fit within "a 
very powerful and efficient declarative programming model". As you know, 
declarative programming is something I strongly believe in!

Regards, Roland



"Mark Birbeck" <mark.birbeck@x-port.net> 
Sent by: mark.birbeck@gmail.com
08/12/2006 10:20
Please respond to
mark.birbeck@x-port.net


To
Roland Merrick/UK/IBM@IBMGB
cc
www-forms <www-forms@w3.org>, www-forms-request@w3.org
Subject
Re: Styling based on instance data






Hi Roland,

That's a neat idea, but it doesn't create reusable 'states', which is
what I'd like to see, and which I think would make for a very powerful
and efficient declarative programming model.

Regards,

Mark

On 07/12/06, Roland Merrick <roland_merrick@uk.ibm.com> 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() &gt; @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() &gt; @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() &gt; @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/
>
>
>



-- 
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 11:46:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:08 GMT