Component Revision: Build Public Folder (WIP)

[klees]

Dear colleagues,

I wanted to share my current state of the art regarding the implementation of the Component Revision. For one, I'm looking for feedback and maybe ideas regarding the stuff I'm working on currently. This is especially true for the build mechanism for the public folder. Second, as the mechanism of the Component Revision will become more important soon, I hope this will allow some insights on how they are intended to work and how they can be used to solve your problems. So please have a look into this and don't hesitate to ask questions or share your observations.

What this already includes:

• This commit shows how we would use the contribute/seek mechanism of the Component Revision to implement the setup. Instead of looking for classes that implement a certain interface, the Setup would now seek for Setup\Agent while the individual components could contribute such an object. Once legacy plugin wiring is gone, we can replace some specific "search and initialize certain implementations" code for the setup (ImplementationOfAgentFinder) with the new integration mechanism. Note the subtleties: While with the old implementation all Setup\Agents had to agree on a common constructor, in the new implementation the constructor for every agent can be different and as required by the component.
• I expanded the build mechanism for bootstraps to support multiple bootstraps. This should allow to replace Services/Context at some point.
• I expanded the build mechanism to fill the public folder with resources from individual components. With that change, components can keep their required public resources in their own folder and declare to the system which resources they need to be served on the web. The Setup will then pick these resources up for the build process and fill the public folder accordingly.

What will happen next:

• We (most probably my colleagues @lukastocker, @daniwe4 and I) will recreate the public folder to contain all the stuff that clients will require. That is, move content from the public folder to some component and add according declarations in Component::init.
• I will bring this to the attention of the JF. I expect all changes to be rather editorial, hence I will not seek approval by every single maintainer. There might be more complicated cases. If so, I will look into it with the responsible persons. If someone wants to have a closer look, feel free to speak up, here, on the JF or in private.
• I'm looking to give a talk about the current state of the Component Revision on the Dev Conf. There's a lot stuff to be presented, but this is some of the material I will want to talk about.
• Added after some questions from @thibsy: The build of the global npm-Packages will be moved outside of the public folder as well. They will be added to the public folder in a similar manner as other files.

I'm looking forward to your reactions and input.

Cheers!

[matthiaskunkel]

Jour Fixe, 19 FEB 2024: Richard asks all developers to read his proposal and to ask question about this improvement.

[matthiaskunkel]

Jour Fixe, 04 MAR 2024: Richard presented his concept to build the public folder as part of the component revision for ILIAS. Questions focused mainly on the handling of JS files. The Component Revision is also a topic on the upcoming DevConf.

[mjansenDatabay]

The following files should be also provided as public asset:

• components/ILIAS/Forum/js/autosave.js
• components/ILIAS/Chatroom/js/chat.js
• components/ILIAS/Chatroom/js/iliaschat.jquery.js
• components/ILIAS/Chatroom/sounds/receive.mp3
• components/ILIAS/Chatroom/sounds/receive.ogg
• components/ILIAS/Chatroom/templates/default/style.css
• public/components/ILIAS/Contact/BuddySystem/js/buddy_system.js

[klees]

@mjansenDatabay: How/where are these sounds included?

[klees]

@mjansenDatabay: I would move these saml endpoints to the resource folder of the component, ok?

[mjansenDatabay]

@klees

How/where are these sounds included?

See public/components/ILIAS/Notifications/templates/default/notifications.js :-) For explanations, check my email reply :-).

I would move these saml endpoints to the resource folder of the component, ok?

Yes, the followings scripts have to be moved to the resource folder:

• metadata.php
• module.php
• saml1-acs.php
• saml2-acs.php
• saml2-logout.php

[klees]

Hi Jour Fixe!

I'm still working on the details of actual change, many public in so many (sometimes hidden) locations.

I still ask for your approval regarding these decisions here:

1. Introduce PublicAsset as a basic interface to put stuff into the web-public directory. The usage can, for example, be examined [here](https://github.com/ILIAS-eLearning/ILIAS/pull/7019/files#diff-108595408280ca626bd1c95229db26b92fd349da5d3262b3d49207e9e10664a8.
2. Put assets into a generalized directory structure in the web-public folder: a) use assets as top directory for files that will be included in web pages b) use assets/js, assets/css etc. for various types of assets c) do not introduce a component-base sub structure in the asset-folders

at 1: This would be a simple consequence of the component integration mechanisms introduced with the Component Revision.

at 2a: A common top directory for all assets will allow for various improvements regarding delivery of the assets. Installations could, e.g., define different caching-rules for assets than for live data delivery from other locations.

at 2b: Splitting up the asset folder with regard to the type of asset we allow installations to implement effective CSP rules.

at 2c: This simply does not seem to be necessary. In the most categories of assets there's either only a small amount of assets or we mostly only have one component that provides these. The one big exception is assets/js, where many components have specialized JS. This could be understood as a hint to pursue the goal to clean up our javascript handling, instead of a general problem with the approach to structure assets. If this decision proves wrong at some point, we should be able to change that approach with a mild effort, thanks to the centralized asset handling introduced here.

Kind regards!

[matthiaskunkel]

Jour Fixe, 15 APR 2024: We approve the two decisions and accept the introduction of a PublicAsset interface and flat directories for the different types of assets (e.g. js, css, ...). We decided against a special handling of plugins and not to introduce specific directories for their JS.

[klees]

@alex40724: I looked into the JS and CSS related to the page editor. Much of dynamically loaded files from unexpected locations, hence it was hard to integrate it into the target structure in public/assets: I decided to leave it in public/components/ILIAS/COPage for the time being. I think we could look into this again once we make some progress regarding JS-bundling.