At the moment NimWC is full featured website package. We defined the main routes (/frontpage, /blog) and html pages (login, etc.), but we allow for plugins, where the user can add additional features. If the user only wants to use NimWC backend and customize everything else, we are currently blocking it. So, it's a kind of a framework (many definitions..).
Scenario
A user does not want to do the programming of user administration, managing files, server monitoring, routes to check loginforms etc. But they want full control of all routes and the HTML for the end user. This is not possible at the moment.
Idea
A compile-flag is introduced: framework
This flag will:
- Remove all default routes
- Remove all include of end-user nimf-files
- Add all routes in
/framework/routes
- Include all nimf in
/framework/nimf
- Give access to framework proc's - such as
proc checkLoginDetails(xxx)
At the moment NimWC is full featured website package. We defined the main routes (/frontpage, /blog) and html pages (login, etc.), but we allow for plugins, where the user can add additional features. If the user only wants to use NimWC backend and customize everything else, we are currently blocking it. So, it's a kind of a framework (many definitions..).
Scenario
A user does not want to do the programming of user administration, managing files, server monitoring, routes to check loginforms etc. But they want full control of all routes and the HTML for the end user. This is not possible at the moment.
Idea
A compile-flag is introduced:
frameworkThis flag will:
/framework/routes/framework/nimfproc checkLoginDetails(xxx)