Luke, > yep - i know :) that's why i ran it: bugs are encountered that are > not encountered via pyjs.
Fine. For the layout, at least, just copy the 3 pyjamas.*.png images to ./public and run 'python website.py', it will display fine. To me, those images are in the wrong place in the repository; they most probably have been copied over to the DocumentRoot on the webspace only, otherwise the pyjs_site wouldn't show any logos today. > *sigh* yes, i know. *thinksthinksthinks*... i think it's important > to have the doc/pyjs_site be the authoritative place to maintain the > files related to the web site. can you put the images into there, > even if they're copies? I don't like the idea of redundancy, especially when it's just for some lack of a concept of a clear directory structure. It looks like the problem is that we have different Pyjamas apps in the ./doc folder. Each of them has its own ./public folder (and the resulting ./output folder is meant to be a ./<name_of_app> folder inside of the pyjs_site DocumentRoot (./doc/pyjs_site/output). In addition---and that's the issue---they usually need some common resources from the DocumentRoot (e.g. the logo images). The image folder ./doc/img obviously is an attempt already to move common files into a place outside of the single apps' ./public folders. Unfortunately, this attempt of moving content out of the "authoritative" place makes things even worse: Not only can't we combine the different apps under a common DocumentRoot, we will be missing the files moved out for the single apps as they are not covered by the "verbatim copying" made by pyjs. The question must be: How can we allow the different apps in the ./doc folder share a common home when we say that the "common home" actually should be ./doc/pyjs_site, which is one of those apps? -- I guess solving this issue is not as straight forward as we'd love it to be. Simply because we have the actual public place of an app (./public or ./output) nested into the actual application root holding the Python/Pyjamas files---it should somewhat be the other way round. As it stands, I believe it's impossible to solve this without some additional directory structure and a build script that moves it all together, the single apps and the common resources. For pyjd based developing we should have a script create symlinks to avoid the danger of committing the common files---something that won't work on Windows platforms. So we must have a script that prepares the projects for local (pyjd-based) development _copying_ all common files to each of the apps' ./public folders! ... and clean the public folders from the redundant common resources after development, before committing, etc. The current directory tree is: doc ├── articles ├── book ├── controls ├── controls02 ├── img ├── pyjs_site └── showcase What it maybe should look like in future is: doc # (contains Makefile and dirs only!) ├── apps # all Pyjamas apps │ ├── book # Pyjamas book │ ├── controls │ ├── controls02 │ ├── pyjs_site # pyjs.org website │ └── showcase # broken Showcase (*.py missing!) ├── docroot # favicon.ico, robots.txt │ └── img # all images, logos, etc. ├── obsolete # old tutorials, articles, old FAQ └── tools # gendocs.py, etc. We probably should add an "other" folder for misc resources, such as the "new logo" tarball from issue #443. > assume that the images on the actual site, whatever location they > happen to come from, are *not* as authoritative as what's in > pyjs_site/public, and that what's in pyjs_site/public will end up in > the output folder and that's what i will end up uploading, thus what's > in pyjs_site/public becomes the authoritative location for images etc. I see the point. But as the website.py is just one of the applications and "common" stuff in pyjs_site/public is needed by other apps, such as Bookreader, etc., it may be less confusing (and cleaner by principle) to copy the generated files all together in a place that contains the common resources already. For development on the single apps we would have to duplicate the resources 'locally' for each app being worked on. Therefore, we need a common "docroot" and a copying/cleanup script. I've started to describe this here: (could go as a README file into doc/apps later) ------------->snip!<---------------- PYJAMAS APPLICATIONS FOR PYJS.ORG WEBSITE This directory contains Pyjamas applications that are online with the pyjs.org website. The pyjs.org website's DocumentRoot is ./doc/docroot, which contains a few common static files needed by most of the Pyjamas applications here. For developing/testing the applications you must prepare this directory: $ make develop (-> common files and directories will be copied to the ./doc/apps folder) Other make commands: $ make clean (-> common files and directories will be removed from ./doc/apps folder) $ make buildall (-> all apps will be built and their ./output content moved to ./doc/docroot) (-> in addition the ./examples will be built and copied to ./doc/docroot) (-> in addition the API documentation will be generated and copied to docroot) $ make upload (-> everything in ./doc/docroot will be copied/synced with the webspace) ------------->snap!<---------------- Does that sound okay? -- There doesn't seem to be a way of nicely nesting Pyjamas apps for (pyjd-based) development (mimic'ing the final folder hierarchy on the webspace), because the container files always resides in a ./<app_name>/public folder instead of simply ./<app_name> (where the app's Python/Pyjamas source files are). I think we should get that straight first. Then I can go into fixing the "maximum recursion depth exceeded" bug. In the end I'll deal with bootstrap.js and the loader animation. Peter
