- From: Roland Merrick <roland_merrick@uk.ibm.com>
- Date: Fri, 8 Dec 2006 13:21:18 +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: <OF495FBEBC.C826C301-ON8025723E.0048C712-8025723E.00495D56@uk.ibm.com>
Greetings Mark, OK I see where you are coming from and headed.
The difficulty with going too far down the track you are headed is that
the kind of state you envisage should really be part of the "data model"
and manifest itself a a formal part of the schema. Unfortunately, as we
know XML Schema does not support this kind of derived property.
Ideally, the notion that a book is overdue should not be just a form
consideration.
Regards, Roland
"Mark Birbeck" <mark.birbeck@x-port.net>
Sent by: mark.birbeck@gmail.com
08/12/2006 12:30
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,
:)
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() > @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() > @due" />
<xf:bind id="read-overdue" nodeset="books/read/book" state="today()
> @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() > @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() >
@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/
> >
> >
> >
>
>
>
> --
> 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 13:24:05 UTC