Build file/directory layout needs extra HTTP server configuration

[cajus]

If you generate your app with the proposed minimum configuration, it creates this directory structure:

├── app
├── resource
│   ├── leaflet
│   │   └── images
│   ├── nogo
│   │   ├── font
│   │   └── image
│   └── qx
│       ├── decoration
│       │   ├── Indigo
│       │   │   └── font
│       │   └── Simple
│       │       ├── arrows
│       │       ├── checkbox
│       │       ├── colorselector
│       │       ├── cursors
│       │       ├── menu
│       │       ├── splitpane
│       │       ├── table
│       │       ├── tabview
│       │       ├── tree
│       │       ├── treevirtual
│       │       └── window
│       ├── icon
│       │   └── Tango
│       │       └── 16
│       │           ├── actions
│       │           ├── apps
│       │           ├── mimetypes
│       │           └── places
│       └── static

This is something that cannot be served directly, because you normally don't want http://foo.bar/app as a base. The resulting structure should be self containing like it is in current qx applications:

└── app
    └── resource
        ├── leaflet
        │   └── images
        ├── nogo
        │   ├── font
        │   └── image
        └── qx
            ├── decoration
            │   ├── Indigo
            │   │   └── font
            │   └── Simple
            │       ├── arrows
            │       ├── checkbox
            │       ├── colorselector
            │       ├── cursors
            │       ├── menu
            │       ├── splitpane
            │       ├── table
            │       ├── tabview
            │       ├── tree
            │       ├── treevirtual
            │       └── window
            ├── icon
            │   └── Tango
            │       └── 16
            │           ├── actions
            │           ├── apps
            │           ├── mimetypes
            │           └── places
            └── static

[johnspackman]

I'm thinking about how to handle this, but the root directory in the example is the target output directory, ie source-output/ or build-output/ and I've anticipated that it's the entire target output directory that would be published on the web server; eg you'd publish http://foo.bar/build-output as a base and then http://foo.bar/build-output/app/index.html would be the URL for the application. The URIs used by the application are (or should be) all relative, so the build-output can be renamed either by modifying compile.json or by just renaming it as part of deployment (i.e. without a compile step).

FWIW the reason for the layout is that libraries are no longer linked to directly by the app - all code is transpiled so sourceUri is not useful, but actually resources also go though a similar process when image combining/splitting/etc is performed (in generate.py, the convention was to do resource processing in the library and commit the output).

I think it will become increasingly common to have multiple applications - we're proposing that the API viewer and TestRunner become contribs, and that qx is able to automatically add and remove applications for those contribs, so that you then have a custom API viewer app which which is also built automatically. Initially at least, I suspect that many of these contrib apps will be useful in development only, but that could change.

Given that resources and source code have to be transpiled during compilation, moving the resources/ directory to go underneath the application directory means duplicating all of the resources for every application.

Another concern I have is that, at present, any kind of meta data can be output into the target directory (currently this is just sourcemap files and class meta data for API viewer), and allowing the base to be the app directory means that these files would also have to be duplicated app-specific.

My thoughts are that if there is only ever one application then the change appears arbitrary, but if the published base is source-output/ or build-output/, does it really matter? The application's index.html URL changes slightly but that's all.

[cajus]

We don't have a single case with multiple applications in one root. That's done by parts, because you don't want to loose the context when switching between them. That would happen if they're single applications.

[cajus]

It should be possible to have the application entry point on / without having to do any server rewrites, redirects, fs linking, etc.

[johnspackman]

So provided that there is a url http://foo.bar/index.html which loads the application, then the directory structure is irrelevant? EG if an index.html was output into the target output directory, that would be fine?

[cajus]

If the index.html does not just contain a redirect, yes. Currently everything from the source/boot directory is copied over to target/app. I use the source/boot to place additional content like "hey, you've no JS enabled" or "hey, your're browser is so much outdated that it's not wise to use it". They're referenced from index.html.

Moving the index.html implies that I've to adapt the links in there to find the stuff copied over from source/boot, but that's not a problem I guess.

[johnspackman]

yes, without redirects. I was thinking that a specialised version of index.html that loads ./app/boot.js and expects resources to be in ./resources etc; this would work for source and build targets, and just implies that there is a "default" application when there is more than one.

[cajus]

If it respects the content of source/boot/index.html, that would be great!

[hkollmann]

Simple solution: We can move index.html into the root and add an <base _href="appname/"_ />.

What do you think?

[hkollmann]

Fixed with #127

[cajus]

writeIndexHtmlToRoot causes base to be set. Sadly this seems to be misinterpreted by iOS - especially when linking apps to the home screen. It makes them always run into a 404, because it seems to append the base multiple times to the path.

I'm still not convinced why we want to change the original behaviour. It just causes trouble and requires additinonal scripts to make it work again.

[johnspackman]

The reason it works the way it does is so that you can have multiple applications generated as part of a single build process. This is certainly important for me (eg one project has three websites which interact with each other, where each website has it's own theme for its apps - 14 applications in total, including a server app for each website) although I appreciate that's probably an extreme use case, supporting multiple apps like this is useful for adding tools like API viewer and Test Runner to your build.

It's a shame that base doesn't work reliably, although it wouldn't be too hard to output an index.html with absolute URIs so that an index.html can be output in the root for the default application. That would be the ideal solution because then you get the best of both worlds

[cboulanger]

If we can add an index.html with absolute urls to get around the problems reported by @cajus, I am very much for keeping the "multiple apps" approach since this can be an extremely powerful feature for decoupling application logic - for example, loading different parts of the application in independent pop-up windows. Parts are most useful in single-window applications.

[derrell]

I, too, use the multiple applications feature. In my case, only one of them is a web page (the other is the server code), so I have my index.html at the top level. That wouldn't work with more than one website app.

Derrell

On Mon, Aug 13, 2018 at 8:21 AM Christian Boulanger < notifications@github.com> wrote:

If we can add an index.html with absolute urls to get around the problems reported by @cajus https://github.com/cajus, I am very much for keeping the "multiple apps" approach since this can be an extremely powerful feature for decoupling application logic - for example, loading different parts of the application in independent pop-up windows. Parts are most useful in single-window applications.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/qooxdoo/qooxdoo-compiler/issues/57#issuecomment-412499481, or mute the thread https://github.com/notifications/unsubscribe-auth/AAWDHwylNjwpRtArzAmLMNxkE8fv0D9xks5uQW8rgaJpZM4RCjmR .

[hkollmann]

I just did test with https://entw.vzaweb.de linking to the homescreen on my iPhone and it's working with base tag.

Where is the diffference? I am using ios11.4.1.

[cajus]

My application is not on / . If it's on / it works for me, too.

Am 14.08.2018 um 19:36 schrieb Henner Kollmann notifications@github.com:

I just did test with https://entw.vzaweb.de linking to the homescreen on my iPhone and it's working with base tag.

Where is the diffference?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[hkollmann]

Just copied the app to entw.vzaweb.de/test with resource and app dir and it's working...

[cajus]

Well. For me it's just running into a 404, because - according to the webserver logs - it's cascading the stuff defined in "base" multiple times. I didn't change anything in the generated index.html.

That's what I'm doing in the moment to get around it: I've disabled the base feature and copy resrouces, index.html and app to one directory. That seems to work fine in all cases.

[hkollmann]

done with new Default Parameter in compile.json