>
> We have been having issues with our CSS image URLs also.
>
> Example:
>
url(/assets/static/dojo/src/widget/templates/DatePicker.cssimages/dpBg.g
> if)
>>if your css is in a css folder in the context, you should use:
>>url( "../assets/...
>>if its direct in the context dir, use
>>url( "./assets/...
>>the url is always realtive to the css file, not the page. The problem
is
>>when using css in the page itself...
>From what I can see, Tapestry 41 is grabbing the contents of the CSS
file from the jar (though we do have our own assets/static/dojo
directory but changes made in there don't seem to be used -- anyone have
any ideas why?).
In DatePicker.js these are defined:
templatePath: dojo.uri.dojoUri("src/widget/templates/DatePicker.html"),
templateCssPath:
dojo.uri.dojoUri("src/widget/templates/DatePicker.css").
Our Shell component is using the default tapestrySource, dojoSource, and
dojoPath of classpath:/tapestry/core.js, etc. The contents of the CSS
file (based off the URI) is sucked in and the css image URLs are
generated at that time.
>
> I've tried adding inline style tags with the correct image paths
> directly into the HTML, but Tapestry renders these styles before it
> renders the dojo ones so I can't seem to ever override the css.
>>I *think* you can, using !important :
>>example:
>>A {
>> color: red !important;
>>}
IE actually ignores !important (at least in ie6, not sure about 7 but we
support both...). Also, these are currently being used in the
DatePicker.css file and since any CSS I try to use to overwrite precedes
dojo's styles I believe the secondary !important overrides the first.
I've also tried adding it in the java file by using renderComponent and
writing it out, but again it writes the style in the head above the dojo
ones. Also does that using a RenderBlock... but these would be hacks
anyway.
>
> After trying to use both context and asset for specifying the
> tapestry/dojo sources to the shell component I just ended up using the
> default ones, which doesn't work for us either.
>>how come? be sure to map /asset/ to the servlet as described in
friendly
>>URLs chapter in the user's guide...
Our autocompleters and other dojo things work, but the CSS paths of
images that come from dojo css files are incorrect. I did doublecheck
hivemodule.xml and web.xml and the configuration seems correct.
Hivemodule.xml
<contribution configuration-id="tapestry.url.ServiceEncoders">
<direct-service-encoder id="direct" stateless-extension="direct"
stateful-extension="sdirect"/>
<page-service-encoder id="page" extension="html"
service="page"/>
<page-service-encoder id="external" extension="external"
service="external"/>
<asset-encoder id="asset" path="/assets"/>
<extension-encoder id="ext" extension="svc" after="*"/>
</contribution>
Web.xml
<servlet-mapping>
<servlet-name>app</servlet-name>
<url-pattern>*.html</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>app</servlet-name>
<url-pattern>*.external</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>app</servlet-name>
<url-pattern>*.direct</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>app</servlet-name>
<url-pattern>*.sdirect</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>app</servlet-name>
<url-pattern>*.svc</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>app</servlet-name>
<url-pattern>/assets/*</url-pattern>
</servlet-mapping>
One thing to note about that is we also had some filter mappings
(NoCacheResponseHeaderFilter) for the above and we also have caching on
/assets/*. I tried commenting out the CacheResponseHeaderFilter for
assets/* in case that was causing issues but the behavior for the css
path didn't change.
>
> We also tried to override AssetService but we must have missed
something
> because the path still got generated incorrectly.
>>there must be another solution.
Most definitely. I mostly was in there just to see how things were being
handled.
>
> If you have the same issue and find anything else, please post.
Thanks!
>
>>generaly, one can use the renderBaseTag parameter of the shell
>>component. this will render a <base> tag in the header, and will
>>determine a base for relative URLs.
>>I am just wondering why the default is false in T41?
>>Cheers,
>>Ron
Thanks for taking time to respond.
Anna
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
