cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Knecht <>
Subject Re: Customization of cform styling (dojo)
Date Fri, 25 May 2007 07:00:36 GMT
Grzegorz Kossakowski schrieb:
> Felix Knecht pisze:
>> Hash: SHA1
>> I want to customize the calendar gif from the
>> forms-calendar-styling.xsl. In former cocoons I could do this via my
>> own forms-sample-styling by overwriting the specific part in it (e.g.
>> the calendar icon).
>> It seems that for various parts this doesn't works anymore in c2.2
>> because of the newer dojo implementation we use. The image paths are
>> hardcoded.
>> e.g. in the
>> cocoon-forms/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/js/DropdownDateTimePicker.js:
>> <snip>
>> dateIconURL: cocoon.formsResourcesUri +
>> "/js/templates/images/dateIcon.gif"
>> </snip>
>> Is there an easy way do do this like it was done before?
>> If not how can it be done?
>> InfoPopup.js
>> MultivalueEditor.js
>> MultivalueEditorWithSuggestion.js
>> and probably some more are lacking of the same.
> Just out of cursity, can you explain how it could be achieved with
> earlier versions?

In erlier version we didn't had a dojo widget. The images were set in
the stylesheet (which could be customize). Nowadays the images are et in
the dojowidget.

        match="fi:field[fi:styling/@type='date'] |
        <xsl:variable name="id" select="concat(@id, ':cal')" />

        <xsl:variable name="format">
select="fi:datatype[@type='date']/fi:convertor/@pattern" />

        <span id="{@id}">
                <xsl:when test="@state = 'output'">
                    <xsl:value-of select="fi:value" />
                    <!-- regular input -->
                    <input id="{@id}:input" name="{@id}"
value="{fi:value}" title="{normalize-space(fi:hint)}" type="text">
                        <xsl:apply-templates select="." mode="styling" />

                    <!-- calendar popup -->
                        <xsl:when test="@state = 'disabled'">
                            <img src="images/diary_blue.gif"
alt="forms:calendar.alt" />
                            <a href="#" name="{$id}" id="{$id}"
return false;" onmouseover="icondown('{$id}', 'diary')"
onmouseout="iconup('{$id}', 'diary')">
                                <img src="images/diary_blue.gif"
name="{$id}" alt="forms:calendar.alt" />

                    <!-- common stuff -->
                    <xsl:apply-templates select="." mode="common" />

> formsResourcesUri variable is set in forms-field-styling.xsl[1]:
> <xsl:value-of select="concat('cocoon.formsResourcesUri = ',
> $doubleQuote, $forms-resources, $doubleQuote, ';')"/>
> $forms-resources is set in the sitemap[2]:
> <map:transform src="resources/forms-samples-styling.xsl">
>   <map:parameter name="dojo-resources"
> value="{servlet:ajax:/resource/external/dojo}" />
>   <map:parameter name="forms-resources"
> value="{servlet:forms:/resource/external/forms}" />
> </map:transform>
> As you see, servlet:forms:/ is used. Now if you want to change some
> resources from the form block you need to "override method" serving
> forms resources. What's that method and how you should override? The
> method is a sitemap matcher that matches requested resource and serves
> it. How to override it? Steps are pretty simple, you must extend forms
> block by creating new one and declaring standard forms block as a
> super in the connections of newly created block. Then in the sitemap
> you can declare matcher that will will match resource you need to
> replace.
> In your case matcher would look like this:
> <map:match
> pattern="resource/external/forms/js/templates/images/dateIcon.gif">
>   <map:read ...> <!-- you serve your own icon here -->
> </map:match>

I think I see what you mean. So you have e.g. forms-resources pointing
to your custom block where you have a matcher for all stuff you want to
customize and all the rest you redirect to {servlet:forms:/...}

> Then in another block, where you actually use forms you must connect
> to your extended block instead of standard one.
> Description above gives you idea how it _should_ be done in new setup
> thanks to conecpts like block/servlet polymorphism and extension. The
> trick is that it will not work currently due to issue COCOON-2038[3].

> For now, I cannot implement functionality mentioned there myself
> because I'm badly lacking free time. I offer my help if you want to do
> it yourself, though. It shouldn't be that much difficult.
> Hope that helps.


> [1]
> [2]
> [3]

View raw message