lkcl@teenymac:~/pyjamas/doc/pyjs_site$ git commit -a -m 'moved public
img files to pyjs_site'
[master 0dd7aaf] moved public img files to pyjs_site
6 files changed, 0 insertions(+), 0 deletions(-)
rename doc/{ => pyjs_site/public}/img/UIClassHierarchy.png (100%)
rename doc/{ => pyjs_site/public}/img/num1.png (100%)
rename doc/{ => pyjs_site/public}/img/num2.png (100%)
rename doc/{ => pyjs_site/public}/img/num3.png (100%)
rename doc/{ => pyjs_site/public}/img/num4.png (100%)
rename doc/{ => pyjs_site/public}/img/overview.png (100%)
On Sat, Feb 25, 2012 at 2:40 AM, Peter Bittner <[email protected]> wrote:
> 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!)
err... errr... what's this doing here? (at all!) - the Makefile
should be what compiles then drops showcase in place (with make
upload): this simply should not be present, at all.
> ├── docroot # favicon.ico, robots.txt
naah - this should be pyjs_site/public/ or at least [having read what
you've written below] accessible without having to go pyjd.setup("../
")
> │ └── img # all images, logos, etc.
.. this should be pyjs_site/public/img
> ├── obsolete # old tutorials, articles, old FAQ
> └── tools # gendocs.py, etc.
ack. *thinks* where the bloody hell did i put that pyjamas-adapted
version of epydoc?? i bet it was in the pyjd.sf.net repository and i
just forgot about it.
> 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.
the question is: how do you then get those applications to work as
pyjamas-desktop applications? running under pyjamas-desktop *has* to
be taken into account.
> 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"
... which is accessible by all applications running as
pyjamas-desktop applications, be it website.py, or the mail front-end,
or the [planned] wiki application etc. etc.
hmmm... symlinks spring to mind.... not ideal.
think of something :)
> 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),
then do it the other way round: the hierarchy suits pyjd as a first
priority, and is "glommed together" for the web site. you can always
change the pyjd.setup argument to reference an alternative location,
btw. you don't *have* to reference the public/ folder.
you'll think of something :)
> I think we should get that straight first. Then I can go into fixing
> the "maximum recursion depth exceeded" bug.
pascal's kindly offered to take care of that one.
> In the end I'll deal with
> bootstrap.js and the loader animation.
good stuff.
l.
