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 23:32:06 GMT
> Ok. BTW, what about naming it "inline-hint", to be consistent with the
> existing "hint" naming?

Funny, we started with a name like that, but then thought that the
name might be confusing, since it's /not/ displaying the fd:hint.

> >     - 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).

Yes, I was looking for a solution that didn't require patching the
cocoon source and rebuilding the forms block -- keeping my build
process simple and allowing the team to use the latest stable cocoon
build and take advantage of cool things like ajax support.

> > 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
>

Okay, so what is the cforms standard-compliant way?
To add inline-hint to the form definition and allow it in the form template?
Does it show up as fi:inline-hint/text() as output from the forms
generator regardless of whether it's defined in the form definition of
the form template?

Regards,
Eric

Mime
View raw message