Quoin Developers wrote:
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".
Ok. BTW, what about naming it "inline-hint", to be consistent with the
existing "hint" naming?
- 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?
No magic, just code ;-)
It's in AbstractWidgetDefinitionBuilder.setDisplayData(). It needs some
refactoring though, as the list of elements is fixed when it should
better be defined by the concrete subclass (i.e. an inline-hint makes
sense only for fields).
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.
I often have questions of some people that consider that label, help,
hint, etc don't belong to the definition but to the view. Now it
actually depends on the point of view, as some other people consider
that they are related to the data model and its definition.
And actually, CForms allows these display data to be defined in the form
template too, as you can write:
<ft:widget id="foo">
<fi:help>This help for foo, in the template</fi:help>
</ft:widget>
We could do the same with the inline-hint
- 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.
I meant exactly that.
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.
Great!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
