15 Jan
2010
15 Jan
'10
3:09 p.m.
Hi Lukas,
Apologies for repeating myself, but I'm still not sure how to solve this
problem, or why you don't see it...
Reiterating; does this test assert on your machine?:
| stylesheetFile stylesheetContents rendererResult |
stylesheetContents := '/* a style sheet */'.
stylesheetFile := (PRFile named: 'defaultCss') filename: 'style.css';
mimetype: 'text/css'; contents: stylesheetContents.
rendererResult := WARenderCanvas builder render: [ :html |
html render: stylesheetFile file contents].
self assert: rendererResult = stylesheetContents
To reproduce the problem with Pier, register a Pier instance with:
PRPierFrame registerAsApplication: 'pier' kernel: (PRKernel new root:
(PRPage new title: 'test title'; contents: 'Pier on Seaside 3.0'; name:
'testPage'); name: 'testKernel').
browse to: http://localhost:8080/pier/environment/style.css, results in:
#[47 42 32 98 108 117 101 112 114 105 110 ...
Any more thoughts?
Nick
2010/1/12 Nick Ager <nick.ager(a)gmail.com>
I've tried to encapsulate the problem in a test:
| stylesheetFile stylesheetContents rendererResult |
stylesheetContents := '/* a style sheet */'.
stylesheetFile := (PRFile named: 'defaultCss') filename: 'style.css';
mimetype: 'text/css'; contents: stylesheetContents.
rendererResult := WARenderCanvas builder render: [ :html |
html render: stylesheetFile file contents].
self assert: rendererResult = stylesheetContents
In my image the assertion fails. If I change ByteArray>>greaseString to
return self displayString the assertion succeeds.
Does that help?
2010/1/12 Julian Fitzell <jfitzell(a)gmail.com>
I'm seeing the same as Nick, fwiw. Same if I try to edit the stylesheet.
Julian
On Tue, Jan 12, 2010 at 2:59 AM, Lukas Renggli <renggli(a)gmail.com> wrote:
#[100 101 98 117 103 103 105 110 103], but this
method is never called
when I browse Pier.
Lukas
2010/1/12 Nick Ager <nick.ager(a)gmail.com>om>:
> Hi Lukas,
> Don't think the browse cache is the problem. What do you get with:
> #[100 101 98 117 103 103 105 110 103] greaseString
> on my image the result:
> '#[100 101 98 117 103 103 105 110 103]'
>
> 2010/1/12 Lukas Renggli <renggli(a)gmail.com>
>>
>> > Does your the implementation of
>> > ByteArray>>greaseString match this:
>> > ByteArray>>greaseString
>> > "ByteArrays should not automatically be converted to Strings. You
should
>> > use
>> > a GRCodec for this."
>> > ^ self printString
>>
>> Yes.
>>
>> > or does your image have an implementation of ByteArray>>encodeOn?
>>
>> No.
>>
>> Maybe you should clear your browser caches?
>>
>> Lukas
>>
>> > 2010/1/11 Lukas Renggli <renggli(a)gmail.com>
>> >>
>> >> Has this been fixed, because it works here?
>> >>
>> >> Lukas
>> >>
>> >> 2010/1/11 Julian Fitzell <jfitzell(a)gmail.com>om>:
>> >> > Maybe we need to implement #encodeOn: on ByteArray? Lukas?
>> >> >
>> >> > Julian
>> >> >
15 Jan
15 Jan
3:55 p.m.
New subject: stylesheet edit rendering problem on pier port to seaside 3.0
Apologies for repeating myself, but I'm still not
sure how to solve this
problem, or why you don't see it...
No problem.
Reiterating; does this test assert on your machine?:
| stylesheetFile stylesheetContents rendererResult |
stylesheetContents := '/* a style sheet */'.
stylesheetFile := (PRFile named: 'defaultCss') filename: 'style.css';
mimetype: 'text/css'; contents: stylesheetContents.
rendererResult := WARenderCanvas builder render: [ :html |
html render: stylesheetFile file contents].
self assert: rendererResult = stylesheetContents
This test does not pass in my image either. I don't see where such
code would be used though? File (and thus CSS files) are certainly not
fed through a HTML canvas. If you download a Pier 2 image from my
build server
<http://hudson.lukas-renggli.ch/job/Seaside%203.0/ws/pier2/*zip*/pier2.zip>
you see that the stylesheets are properly served, I don't see any
problems there.
To reproduce the problem with Pier, register a Pier
instance with:
PRPierFrame registerAsApplication: 'pier' kernel: (PRKernel new root:
(PRPage new title: 'test title'; contents: 'Pier on Seaside 3.0'; name:
'testPage'); name: 'testKernel').
browse to: http://localhost:8080/pier/environment/style.css, results in:
#[47 42 32 98 108 117 101 112 114 105 110 ...
Any more thoughts?
Aha, that I can reproduce. I fixed it in the latest commit.
Note that #greaseString should probably not be used everywhere.
#asString is in the ANSI standard defined on Character, String,
ByteArray, and other sequenceable collections; so in some cases that
might be the appropriate choice.
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
4:33 p.m.
New subject: stylesheet edit rendering problem on pier port to seaside 3.0
Fantastic that we've finally got to the bottom of this one, also my test
code no longer asserts when the code is changed to match your changes. So
the rendering code becomes:
html render: stylesheetFile contents
This test does not pass in my image either. I
don't see where such
code would be used though? File (and thus CSS files) are certainly not
fed through a HTML canvas.
The test was my attempt at condensing the pertinent code relating to the
problem. I'm fairly sure the code has a good correspondence with the code
path used when you browse to:
http://localhost:8080/pier/environment/style.css, but as ever I might have
missed something
5:39 p.m.
New subject: stylesheet edit rendering problem on pier port to seaside 3.0
This test does
not pass in my image either. I don't see where such
code would be used though? File (and thus CSS files) are certainly not
fed through a HTML canvas.
The test was my attempt at condensing the pertinent code relating to the
problem. I'm fairly sure the code has a good correspondence with the code
path used when you browse to:
http://localhost:8080/pier/environment/style.css, but as ever I might have
missed something 
16 Jan
16 Jan
8:40 a.m.
New subject: stylesheet edit rendering problem on pier port to seaside 3.0
On Fri, Jan 15, 2010 at 6:55 AM, Lukas Renggli <renggli(a)gmail.com> wrote:
Note that #greaseString should probably not be used
everywhere.
#asString is in the ANSI standard defined on Character, String,
ByteArray, and other sequenceable collections; so in some cases that
might be the appropriate choice.
Sure, though shouldn't we make sure that #greaseString calles
#asString for those classes? Seems more straightforward...
Julian
5221
days inactive
5222
days old
4 comments
3 participants
participants (3)
-
Julian Fitzell -
Lukas Renggli -
Nick Ager