This is a mostly unordered list of suggestions for improving the Virtual Journal feature of the pub-app.

Default VJ

  • Having a default journal that all other journals inherit from is not ideal
  • It would be better if all journals were siblings with equal rights
  • There should still be a set of default css, javascript, etc. files that ALL journals inherit if no override is defined in the journal subdirectory.

Types of VJs

  • Current PLoS use case has two types of journals
    • Journals
      • Automatic collections based on eISSN
    • Hubs
      • Hubs republish articles from other journals
      • Hubs have no original content
  • Other types of journals have been discussed
    • Subject area journals with automatic collections based on category, discipline or tags
    • User or group journals aggregating articles of interested to a specific institution or lab, manually curated collections without automation.
  • Currently Journals and Hubs are treated the same way in admin - even though we will never publish a PLoS ONE article in PLoS Genetics, I have that option in admin (which can only lead to trouble)
  • It would be great to come up with an extensible way to characterize VJ types and use that to determine which journals you can publish into, how collections are formed on ingest, etc.

Struts and Template configuration is monolithic and verbose

  • Only one set of default css and javascript includes can be defined
  • Every page that isn't default needs to be declared separately
  • All journals have their template configuration in the same file
  • This leads to a huge freemarker section in plosone.xml
  • It would be great if we could declare various sets of includes, and add files or paths to those sets, so that, for example, all static files get the same includes.
  • It would be great to have separate config for each virtual journal - if it was possible to migrate freemarker config into the struts-*.xml files, that would be great

  • It's a little odd that freemarker config from defaults.xml and global-config.xml are imported even when they don't match any of the virtual journals declared in plosone.xml

  • It would reduce the size of the config files, and make life a little easier for end users, if we didn't need to define a separate action for each static file.
    • What if we defined a single static.action
    • And a path like static/about would remap to static.action?template=about, pulling in the static/about.ftl template from the filesystem?

Templates don't use the VJ file filter

  • When the pub-app is asked for css/pone_screen.css, it first looks in journals/vjournals/css/pone_screen.css, and if that does not exist it returns the default css/pone_screen.css instead
  • The templates are not so smart about included .ftl files
    • this is a limitation in (our version?) of Struts. it may be possible to override the Struts template loader so it is cascade aware.
  • Thus we have ugly #if switches in the templates, that do not allow for dynamic overrides
  • It would be wonderful if we could override included template files on a per-journal basis without any need for extra code in the template

Admin/Production Issues

  • To avoid human error in the publication process, we should have separate ingest queues for each VJ
    • We could add a config setting to define queue paths per journal
    • We could apply a regex (specified in config) to the article.zip files so that only article zips with matching file names are displayed for a given VJ

  • Many bad things happen if one tries to ingest, or delete, or otherwise handle an article in the wrong VJ context. There's a total lack of good error checking/reporting for these situations. Often articles are left in a semi-ingested state requiring manual deletion of mulgara triples or fedora objects, which is scary.

Filters and Caching

  • The current article filter system - designed to deny access to articles from the wrong journal context - has never worked right, and every attempt to fix bugginess has introduced more bugs.
    • Can you clarify this a bit? Which bugs are you referring to here? Why hasn't it worked: because the filter-application is buggy, because the filters are properly specified, because some calls circumvent the filters, or something else?
  • These errors are compounded by an equally buggy caching system that doesn't handle VJs or the filter system well, especially in the PLoS use case of two pub-apps sharing synchronized caches.
  • In any case, filtering and caching need to be substantially refactored, or rebuilt from scratch.
  • Whoever is working on this area needs to consider the PLoS use case when testing, either by reproducing that use case when testing, or by collaborating with someone who can reproduce a multi-server install for testing purposes (ie, Russ)
  • In the PLoS use case - many journals, each containing many articles - I suspect that the filter is inefficient in some situations (for example, the need to check each article against the filter when returning search results, presumably part of the poor performance of the feeds)
    • one area of inefficiency is being addressed in #898.

Genericizing the pub-app

  • Default CSS files should not be prefixed pone_