334937 - Review samples on moz.org

Status: RESOLVED WONTFIX

(Core Graveyard :: XForms, enhancement)

Description

[Allan Beaufour]

I think we should review our sample on moz.org before releasing 0.6. 

1) I have wanted to kill the calculator for quite some time now, and I think this will be a good occasion to do it. But we need another HTML/SVG-skinning example then.

2) The Tax Form is also a bit hacky I think. There are a few commented sections, that should just be removed. And could we not try to use the custom control interface somehow for the graph?

3) We need a XUL example. I think a XUL version of the Hotel Booking Form would be nice. But then we need to fix at least bug 328148 and bug 334503.

Comment 1

[aaronr]

(In reply to comment #0)
> I think we should review our sample on moz.org before releasing 0.6. 
> 
> 1) I have wanted to kill the calculator for quite some time now, and I think
> this will be a good occasion to do it. But we need another HTML/SVG-skinning
> example then.

I'm fine with not linking to the calculator anymore, but like you said, we really need a skinning sample to replace it.  If nothing else, it is a quick test to make sure that we haven't broken skinning before we put out a release.

> 
> 2) The Tax Form is also a bit hacky I think. There are a few commented
> sections, that should just be removed. And could we not try to use the custom
> control interface somehow for the graph?
> 

we can make the graph into a custom control if you want (probably some kind of svg'd xf:output, I guess) but it is also nice to show that you don't have to do the custom control stuff to get xforms and SVG to work together.  I'm guessing that especially for their first forms, most form authors won't bother to learn XBL if they can get around it.

> 3) We need a XUL example. I think a XUL version of the Hotel Booking Form would
> be nice. But then we need to fix at least bug 328148 and bug 334503.
> 

XUL example would be excellent!  Anyway we can tie it into making like a XUL Runner app, too (or document how to do that)?  To show why a form author might want to consider XUL instead of XHTML and still be able to use XForms.

Comment 2

[Allan Beaufour]

(In reply to comment #1)
> (In reply to comment #0)
> > 2) The Tax Form is also a bit hacky I think. There are a few commented
> > sections, that should just be removed. And could we not try to use the custom
> > control interface somehow for the graph?
> > 
> 
> we can make the graph into a custom control if you want (probably some kind of
> svg'd xf:output, I guess) but it is also nice to show that you don't have to do
> the custom control stuff to get xforms and SVG to work together.  I'm guessing
> that especially for their first forms, most form authors won't bother to learn
> XBL if they can get around it.

Fair point.
 
> > 3) We need a XUL example. I think a XUL version of the Hotel Booking Form would
> > be nice. But then we need to fix at least bug 328148 and bug 334503.
> > 
> 
> XUL example would be excellent!  Anyway we can tie it into making like a XUL
> Runner app, too (or document how to do that)?  To show why a form author might
> want to consider XUL instead of XHTML and still be able to use XForms.

A XULRunner example would be very nice too. One problem though, is that the user need to compile XULRunner himself, because there is no default xforms support and because of bug 312970.

Comment 3

[Allan Beaufour]

I'm working on some more samples, and there are also people looking at sample styling in general.

Comment 4

[Steve Speicher]

Attachment: a different US 1040ez TaxForm

Consider this example, problem is that this SVG pie doesn't properly render in Firefox 1.5.x

Comment 5

[aaronr]

Other things to consider before 0.6:

1) tax form currently on moz.org has an error going to the third panel.  I believe that it is SVG's problem and may never show on 1.5.x, but form still doesn't work right now on the trunk.

2) calculator doesn't work with the trunk.  Probably another skinning break.

Comment 6

[Allan Beaufour]

(In reply to comment #5)
> Other things to consider before 0.6:
> 
> 1) tax form currently on moz.org has an error going to the third panel.  I
> believe that it is SVG's problem and may never show on 1.5.x, but form still
> doesn't work right now on the trunk.
> 
> 2) calculator doesn't work with the trunk.  Probably another skinning break.

Both problems smells of SVG problems. Let's hope it is :)

Comment 7

[aaronr]

(In reply to comment #6)
> (In reply to comment #5)
> > Other things to consider before 0.6:
> > 
> > 1) tax form currently on moz.org has an error going to the third panel.  I
> > believe that it is SVG's problem and may never show on 1.5.x, but form still
> > doesn't work right now on the trunk.
> > 
> > 2) calculator doesn't work with the trunk.  Probably another skinning break.
> 
> Both problems smells of SVG problems. Let's hope it is :)
> 

#1 SVG.  Should be fixed by bug 338312 (the patch fixed it on my machine).
#2 appears to be SVG related and only on trunk.  When I isolated a testcase down to just SVG, I could see the svg:rect being filled on 180branch, but on trunk it just stayed white.  I've sent the simplified testcase to tor to see what he thinks.

Comment 8

[Allan Beaufour]

With a sync'ed version of the code, and 1.5.0.4 everything seems to work fine.

* Insurance Form
Styling is wrong for the date pickers. It might be because the css file targets divs, and whatever instead of using .xf-value

* Flickr
Does not trigger submission when image size is changed.

* Tax Form
It think we should change the taxform. It includes a help element on one of the fields with an external reference. That fails security checks (if the user does not allow xd for mozilla.org), and thus opens Firefox Help on pressing F1**.

I'll look into fixing this.

[** Though, since help actually opens in another window, it's no different from clicking a link it is? So why do we security check that? We should be able to open whatever. Or?]

Comment 9

[Allan Beaufour]

I'm still trying to figure out why the flickr example is not working. I'm suspecting some security issue once again, since it's the xpath evaluation that fails again again again.

Comment 10

[Allan Beaufour]

Attachment: Fixes for tax and insurance form

This removes the help and uses .xf-value instead of direct controls

Comment 11

[Allan Beaufour]

If the patch on bug 338451 is ok and attachment 223283 [details] [diff] [review] likewise, the samples should be working for 0.6.

Comment 12

[aaronr]

Attachment: fix for calculator

Here is a patch to fix the calculator for trunk builds.  Please checkin if it is ok.  Thanks.

Comment 13

[aaronr]

Comment on attachment 223283 [details] [diff] [review]
Fixes for tax and insurance form

I kinda like having an example of help on a form.  If nothing else it is a nice regression test before we roll out a preview.  But you are right...we probably shouldn't have it be cross-domain if it won't work 'out of the box' for users.

'Course we could fix this by putting mozilla.org on our whitelist by default.  Mozilla does it for other things. ;-)

Comment 14

[Allan Beaufour]

(In reply to comment #13)
> 'Course we could fix this by putting mozilla.org on our whitelist by default. 
> Mozilla does it for other things. ;-)

It's actually not that bad an idea, but if the only reason is to get a sample to work then maybe not :)

Comment 15

[Allan Beaufour]

I checked in attachment 223283 [details] [diff] [review] and attachment 223353 [details] [diff] [review]

Comment 16

[aaronr]

Flickr sample seems to work for me with the latest 1.8.0 source

Comment 17

[David Bolter [:davidb] (NeedInfo me for attention)]

RIP xforms