cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: fi:styling/@in-place-tip
Date Sun, 06 Nov 2005 22:38:22 GMT
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


Mime
View raw message