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
|