search

oskariorg / oskari-documentation

Repository for versioned documentation
https://oskari.org
1 stars 3 forks source link

Selecting folder for a bundle #43

Open ismogis opened 1 month ago

ismogis commented 1 month ago

I find the guidance on naming when setting up a new bundle to be a bit confusing (https://github.com/oskariorg/oskari-documentation/blob/develop/8%20Developing%20instructions/00120-HowToCreateABundle.md). Initially, it states that folders should be created under '/packages/framework/' and '/bundles/framework'. However, the following sentences seem to suggest that if the bundle is not developed by the Oskari core team, the folders should not be placed under 'framework'.

Would it be clearer if the guidance began by explaining how to select or create a new folder under 'packages' and 'bundles'?

ZakarFin commented 1 month ago

So, if you are doing a bundle in the application context (sample-application based repository) you don't really need to care how you do it. It is your app so you can do whatever you like. On oskari-frontend there is a separation of the bundle.js files (that declare which files implement the bundle) that are under the packages-folder and the actual implementation of the bundle under the bundles-folder. This is for historical reasons. However, we will be migrating the bundle.js files from under packages-folder to under bundles-folder in the future. There's actually a very recent bundle that will be included in the next release: https://github.com/oskariorg/oskari-frontend/tree/744adb421ecacb580376108ae976912067e06ec7/bundles/catalogue/metadata that has the bundle.js under bundles.

I think this will be the way forward, but I'm interested in migrating the content of the bundle.js file a bit as well and I would like for it to be index.js on the folder for the default implementation of a functionality. If there is an alternative implementation of the bundle with the same id, it could have some other name than index.js on the folder and you would select the implementation by selecting which file you import on your application. An example could be the mapmodule with it having index.js that has the usual 2d-map and something like index_3d.js for a 3d-version of the mapmodule.

As for the framework as a namespace. You can just think of it as some kind of a context or common theme for the bundles under it. I know it's not perfect currently as historically everything was under framework. And for what ever reason, at some point we decided to throw toolbar under mapping namespace (there's probably some direct OpenLayers references in the impl as the reason). The toolbar under mapping doesn't really make sense if you are thinking of grouping functionalities by some common theme.

TLDR: yes, we will have to clarify this on the documentation

ZakarFin commented 1 month ago

The bundle.js could be migrated to import statements for most parts (the js/css/scss files). The tricky part about migrating the current bundle.js format is how to do the localization file references. For built/minified js we separate the functional code to one (or several for lazy-loading) min.js files and the localizations to another. However the localizations are gathered by language to a min.js per language using only the bundles that are being packaged in as functionalities for the application (so not all localizations for all bundles).