standardize journal template path

All the journal assets will be moved to under /journals/ at some point for sure. As for your other comments, I believe Steve will be able to answer better. We will not be able to make major code changes for 0.8 now, but if a small change can make it easy we will take a look at it.

In order to minimize file duplication, it was decided to take the approach where a filter set up on Tomcat figures out which resource to return to the client, effectively eliminating apache httpd serving up the static resources. The second two points are already doable, but it means essentially having a duplicate set of templates for all pages. Though more clear, it also means some potential management headaches because let's say you have 10 journals, and they all have a bug in the article display template. It means making that bug fix in 10 different places.

you're telling me that, for 0.8, we won't be serving static assets from apache anymore?

have you tested that under load to make sure it's doable?

there are other ways to avoid unneccesary file duplication no? such as a set of shared templates, or using a variable in the template to determine path to css rather than a filter?

also, i don't think it's impossible under the current scheme to serve static assets with apache (although i still don't have a working site to test), it's just a little convoluted...

Replying to russ:

you're telling me that, for 0.8, we won't be serving static assets from apache anymore?

Yes.

have you tested that under load to make sure it's doable?

Nope.

there are other ways to avoid unneccesary file duplication no? such as a set of shared templates, or using a variable in the template to determine path to css rather than a filter?

There are a number of ways that we talked about and explored. The way you mention is one of them. The approach taken seemed to be the cleanest approach from a variety of perspectives.

also, i don't think it's impossible under the current scheme to serve static assets with apache (although i still don't have a working site to test), it's just a little convoluted...

Well, few things are impossible. It is inadvisable at this time, though. Things were designed with the filter in mind and there is a certain amount of logic and resource availability checking that goes on there.

awesome. thanks for the confirmation. we'll update our vhosts and test.

Replying to amit:

We will not be able to make major code changes for 0.8 now, but if a small change can make it easy we will take a look at it.

yes, this was intended to be a future enhancement request - i understand that we're working with what we've got for 0.8...i can hold off on these kinds of tickets until after the upgrade if you like.

however, given the info gained from steve's comments, i'm quite happy i asked!

reassigning to amit so that it can eventually get added to a milestone

Replying to stevec:

Replying to russ:

you're telling me that, for 0.8, we won't be serving static assets from apache anymore?

Yes.

Actually, I don't think that needs to be true. While plosone does a bunch of request-to-resource mappings, the "static" resources are still static in the sense that for a given request (hostname, path, etc) you'll always get the same response, and hence it's possible to cache those and have apache serve them up. However, since even those "static" resources are generated, you would really have to scrape the running plosone server to get those resources (i.e. you cannot just copy the files from the plosone server).

also, i don't think it's impossible under the current scheme to serve static assets with apache (although i still don't have a working site to test), it's just a little convoluted...

Well, few things are impossible. It is inadvisable at this time, though. Things were designed with the filter in mind and there is a certain amount of logic and resource availability checking that goes on there.

True. But all rules are based on host-name and/or path currently (and probably will stay so even for user-created journals) so all the "static" stuff is still static as an http-client viewing site goes.

So it boils down to how much work you want to do, Russ. ;-)

Replying to ronald:

Replying to stevec:

Replying to russ:

you're telling me that, for 0.8, we won't be serving static assets from apache anymore?

Yes.

Actually, I don't think that needs to be true. While plosone does a bunch of request-to-resource mappings, the "static" resources are still static in the sense that for a given request (hostname, path, etc) you'll always get the same response, and hence it's possible to cache those and have apache serve them up. However, since even those "static" resources are generated, you would really have to scrape the running plosone server to get those resources (i.e. you cannot just copy the files from the plosone server).

Huh? I don't think I understand this. Are you saying the js, css, and images are constructed on the fly? Or are you just saying that the correct file needs to be looked up? Yes we can cache those (and that was my point in an earlier ticket (#444) about how a cache can sit in front of the filter rather than in back), but I thought that wasn't what you wanted to do.

yes, i'd like some more info too

if it's the case that clinicaltrials.ploshubs.org/css/pone_screen.css is always going to correspond to /journals/clinicalTrials/css/pone_screen.css on the filesystem, i can (and will) compensate for that with apache.

if it's more complex, then i probably can't...

oh, it is more complex, isn't it. because some css files are shared - we look in the /journals/clinicalTrials/css folder first, and then in /css. the filter does that.

yeah. the substitution really needs to happen in the template - so that the path in the HTML corresponds to the path on the filesystem - otherwise i have to rewrite on a file by file basis instead of path by path, and ronald is correct - i don't want to do that much work.

Replying to stevec:

Replying to ronald:

Replying to stevec:

Replying to russ:

you're telling me that, for 0.8, we won't be serving static assets from apache anymore?

Yes.

Actually, I don't think that needs to be true. While plosone does a bunch of request-to-resource mappings, the "static" resources are still static in the sense that for a given request (hostname, path, etc) you'll always get the same response, and hence it's possible to cache those and have apache serve them up. However, since even those "static" resources are generated, you would really have to scrape the running plosone server to get those resources (i.e. you cannot just copy the files from the plosone server).

Huh? I don't think I understand this. Are you saying the js, css, and images are constructed on the fly? Or are you just saying that the correct file needs to be looked up? Yes we can cache those (and that was my point in an earlier ticket (#444) about how a cache can sit in front of the filter rather than in back), but I thought that wasn't what you wanted to do.

Sorry for the confusion. Yes, js, css, and images aren't contructed on the fly. What I was thinking of are the "static" pages like submission guidelines etc which used to be perfectly static but which now are "generated" (the links adjusted depending on the journal).

Ok, I think I may be changing my mind on #444 - I need to think about that some more, and will answer there.

Replying to russ:

oh, it is more complex, isn't it. because some css files are shared - we look in the /journals/clinicalTrials/css folder first, and then in /css. the filter does that.

Yup. And in general the rules could be even more complex.

yeah. the substitution really needs to happen in the template - so that the path in the HTML corresponds to the path on the filesystem - otherwise i have to rewrite on a file by file basis instead of path by path, and ronald is correct - i don't want to do that much work.

Actually the paths in the html have to be generic (assuming no virtual-journals), and they then get rewritten to the appropriate journal-specific uris when they get served; those uri's are then mapped to the appropriate resource on the request processing. I.e. the paths in the html are neither to what's on the filesystem nor what's in the uri (though depending on the resource and the journal they may happen to look the same).

So, really, to build the cache you want to scrape/spider the running plosone server.

we should be using a Results cache, e.g. this URI Request yields this Result. the VirtualJournalMappingFilter? should sit behind this cache.

also ticket:518 tells us that we're not maximizing the "free" Internet caching ala REST techniques of setting cache & etag headers.

Actually the paths in the html have to be generic (assuming no virtual-journals),

it seems to me that you've chosen to do a lot of work to make a hard thing easy (cascading lookup), but you've made the easy things hard.

honestly, i don't see a great benefit in cascading look up for css, image, and javascript files. not for templates either. let's have totally separate assets for each virtual journal. if there files that are shared we can use symlinks.

the person making the templates and markup for a journal shouldn't have to learn the intricacies of your filter to make it happen. sometimes the dumb approach is better.

even if we do want cascading lookup, and i'm totally missing the point (likely!) i don't see the reason that the file path HAS to be generic in the html. can't we do the look up before generating the HTML? there's absolutely no way to run a filter at the template level instead of when the asset file is called?

So, really, to build the cache you want to scrape/spider the running plosone server.

forget it! there's no cache btw - we just keep a mirror of the plosone webapp on the webhead and server files from the webhead when possible. knowing which files are overridden in the virtual journal folder i can construct file by file redirects (basically mimicing the filter in apache) but i don't think i'm going to do that.

i've configured the production web heads to stop serving css, images, and javascript. it doesn't look like it's going to be a big problem, but we'll get a week or two of testing to find out.

does the filter interact with feed urls?

i'm sure if i call /article/feed it will get interpreted in a virtual journal context.

however, there's a configuration in plosone.xml that allows you to point the feed links included in the <head> to static files - do i need to worry about those urls getting remapped?