I have narrowed it down somewhat. I set a breakpoint after the handler(...)
call to view the responses. All .less files that are very simple return this
response (or something like it):
HTTP/1.1 200
Last-Modified: Wed, 15 Jun 2011 18:15:46 GMT
Content-Length: 57
Content-Type: application/octet-stream
Anything that is even slightly more complicated returns as:
HTTP/1.1 200
Last-Modified: Wed, 15 Jun 2011 19:55:23 GMT
Content-Length: 101
Content-Encoding: gzip
Content-Type: application/octet-stream
The latter is not compilable. So this is odd and easily reproducible:
works:
@bgcolor: green;
.rounded {
border-radius: 10px;
}
h1 {
background-color: @bgcolor;
}
doesn't work:
@bgcolor: green;
.rounded {
border-radius: 10px;
}
h1 {
background-color: @bgcolor;
.rounded;
}
It doesn't make sense that Tapestry would get upset due to the CSS not
looking quite "right", but that appears to be the case. I've updated my
project to demonstrate the issue.
On Wed, Jun 15, 2011 at 2:59 PM, Todd Orr <torr0...@gmail.com> wrote:
> The pipeline seems to be created as expected...Perhaps there's something
> else going on...Yes very strange. I've added a few more css/less files to
> try to isolate the problem. It appears as though index.less works as:
>
> @bgcolor: red;
>
>
> .rounded-corners {
>
> border-radius: 5px;
>
> }
>
>
> p {
>
> background: @bgcolor;
>
> }
>
>
> but change it to:
>
> @bgcolor: red;
>
>
> .rounded-corners {
>
> border-radius: 5px;
>
> }
>
>
> p {
>
> background: @bgcolor;
>
> .rounded-corners;
>
> }
>
> and the Tapestry response handler looses it's mind! Less can't compile it
> because the string returned from the response handling is:
> ?sHJO???/?R(JM????+?/?KIM?M?/?K-*V??RPH?/JI-?-JL?,-?R0-?????*?H&&g??uY)8@M
> ????????m
>
> So it seems as though Tapestry is trying to do something with the CSS that
> makes it completely unreadable and this breaks the less filter.
>
> On Wed, Jun 15, 2011 at 1:23 PM, Howard Lewis Ship <hls...@gmail.com>wrote:
>
>> This kind of thing is easier in Tapestry 5.3.
>>
>> On Wed, Jun 15, 2011 at 8:10 AM, Todd Orr <torr0...@gmail.com> wrote:
>> > I am trying to integrate LessCSS into T5 as a request filter. I have an
>> > admittedly naive implementation on GitHub (
>> > https://github.com/redijedi/tapestry-less). It works, kind of. There is
>> a
>> > test app that can be run via maven (mvn clean jetty:run). Hitting
>> > http://localhost:8080/ will cause a stack trace that describes what
>> appears
>> > to be a failed attempt to less-compile non-ascii text. However,
>> strangely,
>> > it seems to work for context assets (.less files), but doesn't work if
>> the
>> > CSS is imported in a component. Both examples are present in the test
>> > project. The latter appears to have been gzipped prior to the point that
>> my
>> > filter gets it and therefore cannot be less-compiled. I have tried
>> adding
>> > this to the configuration with "before:GZIP" with no effect. As I am
>> trying
>> > to create a drop-in library, I don't think it would be nice to require
>> gzip
>> > to be disabled.
>> >
>> > Does anyone have any advice on altering the response in a filter without
>> > having gzip step all over it?
>> >
>> > Thanks!
>> >
>>
>>
>>
>> --
>> Howard M. Lewis Ship
>>
>> Creator of Apache Tapestry
>>
>> The source for Tapestry training, mentoring and support. Contact me to
>> learn how I can get you up and productive in Tapestry fast!
>>
>> (971) 678-5210
>> http://howardlewisship.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>
>>
>
