+ Frontend Development Proposal Modern Single Page Application frontends may be awkward to maintain in the application repo itself. This proposal is about how to deal with it, without being too specific on the toolchain to use. ++ Patterns as of Horde 5 In the past, Horde Javascript would be stored uncompressed alongside the PHP source code and would be bundled and compressed (and cached) at runtime. Depending on the selected view type (Dynamic, Basic, Smartmobile), the framework would dish out some boilerplate HTML alongside with a backend-generated topbar, some runtime-generated "live data" javascript blobs like translation strings, user keys etc, and a bundled version of the relevant javascript and css. Some Javascript would be auto-included by choice of the view type without a good way to opt-out. This is all driven by some "page_output" class which is optimized for directly generating output to the browser or to output buffers rather than dealing with strings or streams. Some of Horde's default boilerplate would be based on prototypejs and scriptaculous for the dynamic view or jquery-mobile and jquery for the basic view. While jquery is somewhat alive, query-mobile and prototypejs/scriptaculous must all be considered dead as of 2021. ++ Proposed pattern for Horde 6. Roles and responsibilities should be redistributed as technology evolves. There have been some experiments with alternative frontend technologies like ReactJs. As an application suite, Horde strives for some consistent look and feel between its different parts and views, leaving some limited choice of colors, icons and styling to the actual application. As a framework, horde should define communication between the backend and the consuming frontend and maybe some default implementation, but should not get into the way of developers doing something entirely different. This would enable reuse of the same API for alternative frontends or mobile apps. * horde-components should have some developer support for frontend development. The raw frontend code should be a separate repo from the Horde app. The name of that repo should default to $app + underscore + "frontend" like "passwd_frontend" and be in the same path or organisation as the backend code. It may bundle or include any libraries it needs. The default location to checkout that build is /frontend inside the backend app checkout and that path should be .gitignored. The frontend technology should include a "make-horde" executable that would build a production optimized version of the code and deliver it to /themes/default and to /js dirs. An optional make-horde-dev version with source maps and less optimization overhead may exist. The frontend technology may have a self-refreshing development version delivered by some server. TODO: How to facilitate injecting a proper session and environment into that scenario? * the frontend source code may be javascript, typescript, or any other language and would be transpiled and bundled into a build in the js/ and themes/default/ folders. This build may still be bundled, cached or otherwise processed by horde. ++ TODO * reusable UI parts which may be leveraged by portals or UIs of other apps * themeing and translation definitions