Refactoring modules to make FoBo even more flexible

Question

Refactoring modules to make FoBo even more flexible

Closed this issue 9 years ago · 0 comments

Composing ToolKit

Today FoBo have the notion of adding toolkit's to your Lift project.

For example:

FoBo.InitParam.ToolKit=FoBo.Bootstrap336
FoBo.InitParam.ToolKit=FoBo.FontAwesome430

The toolkit brings in (loads) two distinctly different things namely the referenced toolkits resources and the associated FoBo Lift API functions.
As thus two things is (in most if not all cases) separable the ToolKit init could be composed (in a relaxed sense of the word) into two distinct parts, resouces and api.

The goal

The goal of this issue is to increase the usability of the FoBo module for users with more granular requirements than is available today. For instance a user may want to rule there own resources via npm, bower or the likes but would like to take advantage of FoBo's toolkit API(s) or the vice versa a user may want to take advantage of FoBo's easy and uniform resource upgrade/downgrade and development debug-able, production minifcation handling but are not interested in the FoBo provided toolkit API(s).
Related to this the user may also want to just depend on (in there build system) the granular part of FoBo they use. This issue intend to address these concerns without affecting current usage in a abrupt way thus only bring more options to the user.

In this issue, connected to PR #61, 3 new ways to initiate a FoBo toolkit will be introduced namely

Using the FoBo meta module:

FoBo.ToolKit.Init=FoBo.ToolKit.[ObjName] //for example AngularJS148,Bootstrap336
FoBo.Resouce.Init=FoBo.Resouce.[ObjName] //for example AngularJS148,Bootstrap336
FoBo.API.Init=FoBo.API.[ObjName]   //for example AngularJS1,Bootstrap2,Bootstrap3

Note: The FoBo meta module is FoBo's top level module and the module you are most likely to import in bootstrap.liftweb.Boot boot if you decide add a dependency to all of FoBo's sub-modules in you project dependences.

Using one or more FoBo toolkit module (here denoted with XX)

FoBoXX.ToolKit.Init=FoBoXX.ToolKit.[ObjName]
FoBoXX.Resouce.Init=FoBoXX.Resouce.[ObjName]
FoBoXX.API.Init=FoBoXX.API.[ObjName]

Note: You are likely to use one or more of FoBo's toolkit-modules (instead of the meta module) if you import the toolkit-module into your bootstrap.liftweb.Boot boot and optionally (for size reasons) instead of depending on all of FoBo's toolkit-modules (via the meta module) you only add dependences to the specific toolkit module(s) you are actually using in you project.

Using one or more FoBo resource module (new)

FoBoXXRes.Resource.Init=FoBoXXRes.Resource.[ObjName]

Using one or more FoBo API module (new)

FoBoXXAPI.API.Init=FoBoXXAPI.API.[ObjName]

Note: By using FoBo Resouce and/or API module(s) you will be able to narrow your projects FoBo dependences to just using a FoBo/Lift API for a toolkit or just using FoBo's resource handling mecanis by just using the Resource module. This will future reduce the footprint of the FoBo module in your Lift project and narrow your projects FoBo dependences to just the parts you are interested in.

Benefits

Some of the benefits of composing ToolKit into two parts would be:

The user could continue to use the FoBo.InitParam.ToolKit init param as before and nothing changes. It is just internally now built up of two things. The FoBo.InitParam.ToolKit will however be deprecated (and eventually removed) this is easily fixed by switching to use the new syntax FoBo.ToolKit.Init that will do exactly the same. This syntax is added as it is more in-line with the initiation syntax that will be added for the more granular initiation (Resouce and API) that is FoBo.Resouce.Init respective FoBo.API.Init.
The user could chose to just bring in the toolkit resources with something (new) as for example

FoBo.Resouce.Init=FoBo.Resouce.Bootstrap336

to load the scripts and css files for in this case bootstrap v3.3.6 (but not load the FoBo/Lift API stuff)
As FoBo already is modular in the way that the user can chose to include a FoBo sub module artefact as a dependency to just add the things (toolkit) they need from FoBo in there application.

By composing it future the user will now also be able to get a even smaller footprint (assuming the new components can be split into separate sub modules) and then switching from using (for example)

FoBo.InitParam.ToolKit=FoBo.Bootstrap336

or (just using the corresponding sub module)

FoBoBs.InitParam.ToolKit=FoBoBs.Bootstrap336

to instead use (or initialize in this case just the resources)

FoBo.Resource.Init=FoBo.Resouce.Bootstrap336

or (just using the resources provided by the sub-module)

FoBoBs.Resource.Init=FoBoBs.Resouce.Bootstrap336

Note: To make FoBo init uniform the current use of

FoBo.InitParam.ToolKit=FoBo.[ToolKitName]

will be deprecated and replaced by

FoBo.ToolKit.Init=Fobo.ToolKit.[ToolKitName]

To minimize the application footprint each module will be available as a separate dependency artefact. This will also mean that FoBo will have 3 "initialization" levels (instead of currently 2) with the FoBo (meta) module at the top then the Toolkit modules (current sub-modules) and then at the third level its corresponding Resource and ev. FoBoAPI modules.

The user could chose to just bring in the FoBo/Lift API stuff for a toolkit (but not the associated resources) with something like this

FoBo.API.Init=FoBo.API.Bootstrap336

to load the toolkits associated FoBo/Lift API stuff.
So in the same way as in (2) above the use could switch from using

FoBoBs.InitParam.ToolKit=FoBoBs.Bootstrap336

to instead use

FoBoBs.API.Init=FoBoBs.API.Bootstrap336

This will make it more clear for users that would want to rule and load the toolkit's resources themselves that it is possible.
The reason the user may want to be abler to do this could be that they are used to use Bower or npm or maybe they are using lift-ng but finds FoBo's (emerging) front end angular material design api stuff interesting in the late case and the implementation and usage of (3) above it "signals" a cleaner separation of concern between the FoBo and lift-ng modules.

So far this is just thought that (as it dose not seem to break anything) could be implemented in the FoBo v1.x series but the changes in the build system may merit a v.2.x switch it is however also possible to do this in a sub module by sub module fashion so a minor version bump may suffice.