Split built-in.app into several files, e.g. session management, email management, input and outputs by type.

This requires changes in compiler and editor strategies that automatically copy built-in.app into the application. Also the precompile-builtins functionality needs to be updated, so that the new files will be seen as part of the built-ins.

Submitted by Danny Groenewegen on 18 November 2013 at 15:22

Can we not generalize the precompile functionality so that it can be applied to user-defined libraries? Then we could also move the built-in library into user-space where it would be easier to maintain.

I agree that some of the built-in.app functionality should be a seperate user libary. However, the built-in.app is precompiled, which is a huge advantage at the moment.
I think there are some (hidden) dependecies in the built-in.app probably with the compiler as well.

Applying the precompile functionality to user-defined libraries is possible, however, there are some limitations in this feature, e.g. extend entity on something in the library wouldn’t work. Also, additional access control rules on library definitions wouldn’t work. The current standard library contains internal entities and templates that are open anyway, something which we would need to analyze in the case of user libs. Additionally, it is only relevant for clean builds, you also get caching on subsequent builds that does take into account aspecty features. This is another reason for not promoting the ‘broken’ precompile feature to users, and just continue the compile-units-cache path for user-defined libraries. We can probably improve that in the future to also handle the precompilation of the built-ins, and get rid of the current precompile implementation.

I agree that we need to make the library easier to maintain. The WebDSL compiler depends on some of the components in the library, so there would still be a version shipped with the compiler. An option would be to allow users to override this and use their own version, that way enabling them to try changes and contribute. We could make it a submodule in git https://yellowgrass.org/issue/WebDSL/766 to keep the version in sync with the compiler, while still having a separate repository. In general, I think we should ship WebDSL packaged with the best libraries we have available enabled by default (such as styling with bootstrap). That way, we can also make styling consistent for special widgets such as the date picker and list input, which use a generic JQuery style currently.