Re: Styling based on instance data

Jason,

I don't doubt that we can come up with many other ways of relating the
CSS style to the underlying data model, but I was dealing with
something very specific, which is the styling of underlying *state*.
At the moment XForms allows us to specify style and event handling
based on a number of built-in states, and my suggestion was to allow
an author to define their own 'states'. This is a great way to extend
the declarative model of XForms and makes for very efficient and
compact applications.

But it's also true that you might want some kind of general-purpose
way to get the value of an instance node to be used as the driver for
the value of some CSS property. I can see that being useful, but
speaking for myself I'd almost certainly never use it! :) The reason
is simply that it mixes up the model and view layers too much. On the
other hand, providing information to the UI via events and CSS
pseudo-classes about the state of data in the model keeps the various
layers more distinct.

Best regards,

Mark


On 02/12/06, Jason <jeacott@hardlight.com.au> wrote:
> I'm not sure a simple on/off is powerful enough. If a solution is to be
> found it should be capable of handling as many situations as possible.
> Consider a form as below but where you want the colour to reflect the
> degree of overdueness, and that degree should be expressed as a
> calculated rgb value that directly correlates to the number of hours
> overdue (shading darker or redder or whatever). Its not a great example
> but you get the idea - someone is going to want to use a calculated or
> otherwise broad range of values for this stuff. Is there a way to modify
> the css at runtime?
> maybe something like:
>
>    <style type="text/css">
>      :mip-overdue-on { color: <xf:value-of bind="@due"/> ; }
>    </style>
>
> or maybe relying on css for all the stying options is just asking too much.
>
> Jason.
>
> Mark Birbeck wrote:
> >
> > 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/

Received on Monday, 4 December 2006 20:03:32 UTC