On 26/04/12 15:44, Vsevolod Fedorov wrote:
> On 04/26/12 18:22, Phil Charlesworth wrote:
>
>> First Test: server.py and index.py in same directory, index.html in
>> public sub-directory. No images in public.
>> python server.py from a cmd window. python index.py from a separate cmd
>> window
>> Server output:
>> Deborah - - [26/Apr/2012 14:42:20] "GET /public/index.html HTTP/1.1" 200 -
>> Deborah - - [26/Apr/2012 14:42:20] code 404, message File not found
>> Deborah - - [26/Apr/2012 14:42:20] "GET /public/tree-closed.gif
>> HTTP/1.1" 404 -
>>
>> The application displays as it should with tree-closed images and the
>> the branches can be opened and then display tree-open images.
>>
> I do not see calls for other images (tree_white.gif and tree_closed.gif)
> here. And this single call to tree-closed.gif is also unsuccessful. Yet,
> somehow you can see this images! I can only guess that they are loaded
> directly from file system, not calling to server.py.
> May be this is the difference between our linux and windows - under
> linux pyjd always calls server (with full file system paths).
>
>
>> I took note of your remark about TreeItem.imgSrc possibly being called
>> without a Tree object and traced the calls back to
>> TreeItem.updateState(). In the else: clause in that method imgSrc is
>> called twice for tree_closed.gif without a Tree object (presumably, once
>> for each branch. It seemed to me that these calls were probably
>> unnecessary and also likely to fail, so I inserted a test for the tree
>> object and continued only if the object existed. Somewhere around line
>> 331 of TreeItem.py.
>> if self.tree:
>> DOM.setAttribute(self.imgElem, "src",
>> self.imgSrc("tree_closed.gif"))
>>
>>
>> Third Test: exactly as first test except imgSrc not called on
>> tree_closed.gif if not self.tree
>> Server Output:
>> Deborah - - [26/Apr/2012 5:11:10] "GET /public/index.html HTTP/1.1" 200 -
>>
>> No HTTP for images! The application again behaves as it should.
>>
>> Conclusion: The HTTP GETs for the images are caused by calling
>> TreeItem.imgSrc without a Tree object and are unnecessary. Probably
>> TreeItem.updateState() should test for valid Tree object in all its
>> branches because different initial tree structures might hit different
>> branches before the Tree is constructed.
>>
>> It would be very interesting to hear whether doing that modification to
>> TreeItem.updateState() will fix the problem for you too.
>>
>>
> With your modification it just skips first GET /public/tree_closed.gif,
> then it all the same.
>
> I also noted one more strange thing: my log show that image names are
> "tree_something", with underscores. In your it is "tree-closed.gif",
> with dash.
>
> Seva
>
Seva,
I have it running under Linux now and I think I understand the
problem. Under Linux, when a server is involved, all paths have to be
relative to the web root.
I have put index.py in /home/phil/MyPython/seva/ and that has a public/
sub directory with index.html.
If I run server.py in /home/phil/MyPython/seva/ any path strings are
added to that, so I can access an image in its public/ subdirectory with
a path like /public/tree_closed.gif. I cannot access the pyjamas stuff
at all because it's not under the web root.
If I run server.py in /home/phil/ (and modify the path in index.py
accordingly) then pyjamas becomes potentially accessible because it's in
/home/phil/pyjamas/. I can create a custom path string
/pyjamas/library/pyjamas/ui/public/ and then the images in that
directory are accessible. But pyjd.pyjdinitpth is /home/phil/pyjamas, so
the current code for pyjd in pygwt.py doesn't work even in that situation.
The reason things work in Windows is that it's possible to recognise an
absolute path from its form (e.g. C:/...) and treat it differently from
other paths which are relative to the web root and that is what MSHTML
presumably does.
Without imposing restrictions on where pyjamas is installed and where
the web root for any server should be, there seems to be no clean way
under Linux for an application to gain access to files in the pyjamas
directories.
So, we will have to backtrack and remove the two lines
elif pyjd.is_desktop:
return pyjd.pyjdinitpth + "/library/pyjamas/ui/public/"
from pygwt.py.getImageBaseURL()
and instead, pursue the two options Luke has come up with, either
getting pyjd to copy the image files from
pyjamas/library/pyjamas/ui/public/ into the application's public/
subdirectory, or dispense with image files completely and just create
the images on the fly.
I will post a comment on the issue, summarising my conclusions but pleas
let me know if you disagree with any part of it.
Phil
