cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Quoin Developers <quoin...@gmail.com>
Subject Re: fi:styling/@in-place-tip
Date Sun, 06 Nov 2005 22:08:34 GMT
>
> Cool stuff!

Thank you.

A few questions though:
> - is the "inline-tip" different from the <fd:hint>?

 It might often be the same, but it could also be different. In the example
I give, the fd:hint might be "The date that you plan on arriving", while the
in-place-tip is "mm/dd/yyyy".

- if yes, what about adding it besides <fd:hint> and <fd:help> in the
> form definition?

 I recall running into the issue that simply adding a new fd element didn't
mean that you could actually access in the xslt for the forms
transformation. Is there some magic to ensure that the new element makes it
out of the forms generator? I think that's part of why we put it in the form
template. The other reason - it is more display/rendering specific than the
more general concept of a hint. I did have the thought that if you want to
display the hint text as the the in-place-tip that the in-place-tip could be
some magic value such as "fd:hint/text()". That's not implemented, but easy
enough to do.

- how does "onchange" behave when an event listener is attached to the
> input? I mean we must be sure the tip isn't submitted in that case.

 Good point. Do you mean a server-side fd:on-value-changed, or something
else. The tip text will be remove when the form is submitted for any reason.
We're currently migrating to the latest cocoon RC and
forms-field-styling.xsl seems to be out of sync with the formslib.js on the
naming of forms_submitForm(element). I fixed that locally, and yep, the tip
is remove on submission.
 --
Eric

Mime
View raw message