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

Re: Styling based on instance data

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Fri, 8 Dec 2006 12:30:00 +0000
Message-ID: <640dd5060612080430o28b1f0dcv2fa27c3de3db9eb9@mail.gmail.com>
To: "Roland Merrick" <roland_merrick@uk.ibm.com>
Cc: www-forms <www-forms@w3.org>, www-forms-request@w3.org

Hi Roland,

:)

I was only saying that I was searching for a solution that allowed
states to be re-used, and should we find one, it would be "a very
powerful and efficient declarative programming model". So, I wasn't
suggesting that your solution _wasn't_ declarative.

I'll explain though, with your examples. You say that we can indicate
that some books are 'overdue' with this:

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

It's true that we've now indicated that the set of books identified by
"books/book" have a state of 'overdue'. But what if we add some other
books to our application:

  <books>
    <toread>
      <book />
    </toread>
    <read>
      <book />
      <book />
    </read>
  </books>

In the model I'm suggesting, I would like to say that "a book is
overdue" in just the same way that currently we can say "a person is
readonly" or "a company is required". But if we use IDs to name the
states in the way that you suggest, we'd need to create a new state
for each data collection:

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

And so on.

The way I was thinking about 'state' was that if some organisation had
a concept of 'overdue' that they applied across many applications,
then it would be great to be able to capture that. So, perhaps we
could do something like this:

  <xf:state id="overdue" />

  <xf:bind nodeset="books/toread/book" mip:overdue="..." />
  <xf:bind nodeset="books/read/book" mip:overdue="..." />

Now that the concept is nailed down and named, everyone can converse
about it; for example the designers can use a well-know CSS style when
laying out the site or applications, the business analysts can say
what the expressions should be for each type of data, and so on. The
latter is interesting since now we could say that some books are not
overdue if the person has a gold pass, whilst others are always
overdue, no matter what.

Anyway, I'm not saying that's the answer--only that it's the notion of
a 'named state' that I'm trying to capture, just like we already have
'named states' like readonly, out-of-range, required, and so on.

Regards,

Mark

On 08/12/06, Roland Merrick <roland_merrick@uk.ibm.com> wrote:
>
> 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/
>
>



-- 
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 12:30:23 GMT

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