You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Paudi Moriarty <pm...@annadaletech.com> on 2007/02/05 13:05:58 UTC
Re: Re: T41: Are there any known problems with BASE tag?
Hi,
I'm still seeing this issue in 4.1.2-20070131.111650-11.
Any news on when the fix will be ready?
Thanks,
Paudi
> Re: Re: T41: Are there any known problems with BASE tag?
>
> Anna Vo
> Mon, 22 Jan 2007 07:48:19 -0800
> Jesse-
>
> You're awesome! :)
>
>
> -----Original Message-----
> From: Jesse Kuhnert [mailto:[EMAIL PROTECTED]
> Sent: Sunday, January 21, 2007 11:02 AM
> To: Tapestry users
> Subject: Re: Re: T41: Are there any known problems with BASE tag?
>
> I did finally track down the root cause of all this image css path
> nonsense finally yesterday. It'll require a new dojo build in the
> tapestry source, probably will happen today in the 4.1.2-SNAPSHOT
> version.
>
> On 1/18/07, Anna Vo <[EMAIL PROTECTED]> wrote:
> >
> > >
> > > 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]
> >
> >
>
>
> --
> Jesse Kuhnert
> Tapestry/Dojo team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org