I have an application which is made up of multiple sections of functionality (aren’t they all ), and I’m looking at the various options from a design viewpoint. As an example here’s what I’m considering based on a fictitious app:
Backbone App: Company Details (Name , Address etc)
Function Block 1: Personnel (Details of individuals who work for the company)
Function Block 2: Markets (Details of markets where the company operates and country info etc)
Function Block 3: Products (Details of products the company manufactures and sells etc)
Function Block 4: Financials (Detailed info on the companies business results etc).
The Backbone will be seen and used by all Clients, but additionally each Client will see 1 or more of the Function Blocks based on his access level.
Questions:
Would it be most appropriate to use a Module Set-up (where each module is a Function Block), or have all functionality built into the app and simply show or hide the above in Tabs (one for each Function Block) based on access level?
If the Function Blocks were actually Module solutions, what would be the best way to develop them:
a) Build all functionality into one solution, then save each solution as a new solution (to be re-attached as a Module), having stripped out non-Function Block data? b) Create a new solution for each Module, attach it to the Backbone solution as a Module and then develop the Module (is this possible - to develop the content of a Module whilst attached to a solution?)?
Is it possible to determine if a Module exists in the deployment - in order to show / hide menu selections etc?
What are the advantages and disadvantages of using Modules over built in functionality - specifically where the Modules may not be applicable to any other app?
As you can see I’m a little confused as to how I can develop the Modules as separate entities and yet be fully integrated to the Backbone solution at the same time? I (think) I understand the principles of attaching and using the Modules as a ready built solution, it’s the development of the Modules I’m confused over. But more importantly, I’m not sure if Modules will offer any advantage over built in functionality in this type of app / deployment.
I’d appreciate any feedback on this - I’m sure I’m over thinking it at the moment!
This is certainly a good “best practices” question. I haven’t designed a solution that actually deploys with optional modules. Currently, my thinking on modules on a solution I start from scratch is something like this…
Factor any functionality that isn’t specific to the application into supporting modules. These are things like the mod_js_core and mod_console modules I’ve released publicly that I find useful across numerous solutions.
[solution_name]_media : this module contains any media files for the application (icons, background images, etc.)
[solution_name]_model : this contains the solution data model. All calculations, aggregates, relationship (except perhaps global relations that are only used in the UI), table events and value lists. Separating this into a module lets you reuse the business logic level across different solutions – ie, if you have a separate Web client version of your solution.
[solution_name]_reports : contains the forms that are intended for printing only.
[solution_name] : the main solution, with UI elements, forms, etc.
I’d be interested in hearing other’s approaches to this, because I’m not really sure I’ve got my system perfected. I largely avoided a lot of modules in <=3.5 because it was harder to develop with them. That’s not really true in v4.
agiletortoise:
This is certainly a good “best practices” question. I haven’t designed a solution that actually deploys with optional modules. Currently, my thinking on modules on a solution I start from scratch is something like this…
Factor any functionality that isn’t specific to the application into supporting modules. These are things like the mod_js_core and mod_console modules I’ve released publicly that I find useful across numerous solutions.
[solution_name]_media : this module contains any media files for the application (icons, background images, etc.)
[solution_name]_model : this contains the solution data model. All calculations, aggregates, relationship (except perhaps global relations that are only used in the UI), table events and value lists. Separating this into a module lets you reuse the business logic level across different solutions – ie, if you have a separate Web client version of your solution.
[solution_name]_reports : contains the forms that are intended for printing only.
[solution_name] : the main solution, with UI elements, forms, etc.
I’d be interested in hearing other’s approaches to this, because I’m not really sure I’ve got my system perfected. I largely avoided a lot of modules in <=3.5 because it was harder to develop with them. That’s not really true in v4.
greg.
I see you reasoning Greg - and for re-usability that looks like a sensible separation of aspects of the system. However - would you comment on the method of developing the Modules. i.e. if a Module is attached to a solution - can the development of the module continue through the main solution? Or is it necessary to Open the Module as a separate solution to make changes to it?
In v4, you can edit pretty much anything in a module that is attached to the active solution without actually making the module the active solution, yes.
agiletortoise:
In v4, you can edit pretty much anything in a module that is attached to the active solution without actually making the module the active solution, yes.
greg.
So, editing forms etc in the Module is possible. What about adding forms etc to the Module, is that possible with-out making it the active solution? - How would that work?
BTW - Great Presentation on VUG last evening (PM here in UK) - thanks for the time Greg.
Greg,
are you following the “MVC” paradigm? Model View Control.
Where the VIew is all of the user interface(UI).
Control is the methods some of which are triggered from the UI and some from the MODEL.
Model is the “data” model.
Regards,
Tom
So, editing forms etc in the Module is possible. What about adding forms etc to the Module, is that possible with-out making it the active solution? - How would that work?
BTW - Great Presentation on VUG last evening (PM here in UK) - thanks for the time Greg.
Yes, editing forms is possible. Just try it. The “Modules” node appears under the active solution, you can expand that and right click on the various nodes to create/edit forms, globals, variables on the module level.
So, editing forms etc in the Module is possible. What about adding forms etc to the Module, is that possible with-out making it the active solution? - How would that work?
BTW - Great Presentation on VUG last evening (PM here in UK) - thanks for the time Greg.
Yes, editing forms is possible. Just try it. The “Modules” node appears under the active solution, you can expand that and right click on the various nodes to create/edit forms, globals, variables on the module level.
I guess I’m aiming for that, yes. I’m not sure you can cleanly do full MVC in Servoy. The View and Controller are pretty tightly coupled. It’s still a great goal to separate concerns as much as possible.
Last year, we started converting our product from Visual FoxPro to Servoy 3.5 and had the exact same questions regarding modules. We opted then to use modules to encapsulate functionality, so that customers could pick-and-choose which modules they would like to purchase. Although we initially liked the concept of modules, we found that working in version 3.5 to be limited such that moving/copying forms and methods between modules became…well, frustrating. However, that all changed once we moved to Servoy 4.0, and with form inheritance between modules, we are now finding that our original decision to work with modules to be the correct development path for us. From the description of your needs, I would strongly recommend that you also use the module paradigm.
In Servoy 4.0, with the ‘Team’ concept, we discovered that a newly created module must be ‘checked out’ to be displayed in the ‘All solutions’ menu in the ‘Solution Explorer’ (ie. it is not automatically downloaded in an exisiting/open solution; however, once included in the solution, it and all the other modules will download the first time the solution is ‘checked out’). And, I believe that ‘committing’ changes to the solution (top level) will also commit changes to modules that are attached to it.
kwpsd:
Last year, we started converting our product from Visual FoxPro to Servoy 3.5 and had the exact same questions regarding modules. We opted then to use modules to encapsulate functionality, so that customers could pick-and-choose which modules they would like to purchase. Although we initially liked the concept of modules, we found that working in version 3.5 to be limited such that moving/copying forms and methods between modules became…well, frustrating. However, that all changed once we moved to Servoy 4.0, and with form inheritance between modules, we are now finding that our original decision to work with modules to be the correct development path for us. From the description of your needs, I would strongly recommend that you also use the module paradigm.
In Servoy 4.0, with the ‘Team’ concept, we discovered that a newly created module must be ‘checked out’ to be displayed in the ‘All solutions’ menu in the ‘Solution Explorer’ (ie. it is not automatically downloaded in an exisiting/open solution; however, once included in the solution, it and all the other modules will download the first time the solution is ‘checked out’). And, I believe that ‘committing’ changes to the solution (top level) will also commit changes to modules that are attached to it.
I hope this helps.
Kim
Great feedback thanks Kim - that’s satisfied one of the concerns I’ve had over the Module / Functionality model. Have you defined a good method to determine which solutions are available to which Clients (i.e. does a Module exist in a deployment) so that there can be an automated way for the system to know which Modules ‘should’ be available to which Clients?
Our VFP product already does this, and the re-write in Servoy also has it:
We include all modules in the product distribution and use an encoded table to activate them on a per customer basis. Many years ago, we tried to segregate the modules from the product distribution but found that it caused more problems than not as far as service and maintenance (latent module interdependcies, too!). Tens years ago, we decided to change to our current mehtod, and we (as developers…less work for us) and our customers are much happier. If one of our customers decides they want to purchase a new module, all we do is change the table encoding, and they have immediate access to the new functionality. We do not have to re-distribute the product or bother their IT departments with re-installations. We have also found this method to be a sales tool in that we can let customers demo the new module for 30 days before they purchase it. If they decide not to make the purchase, we can just turn it off again (they always buy, however).
kwpsd:
Our VFP product already does this, and the re-write in Servoy also has it:
We include all modules in the product distribution and use an encoded table to activate them on a per customer basis. Many years ago, we tried to segregate the modules from the product distribution but found that it caused more problems than not as far as service and maintenance (latent module interdependcies, too!). Tens years ago, we decided to change to our current mehtod, and we (as developers…less work for us) and our customers are much happier. If one of our customers decides they want to purchase a new module, all we do is change the table encoding, and they have immediate access to the new functionality. We do not have to re-distribute the product or bother their IT departments with re-installations. We have also found this method to be a sales tool in that we can let customers demo the new module for 30 days before they purchase it. If they decide not to make the purchase, we can just turn it off again (they always buy, however).
I hope this helps!
Kim
Brilliant Kim - that’s a very similar model we use for license distribution in our current app. We use an encrypted key sent by email to upgrade the number of licenses available to the Client (after he has the app installed), is this similar to the way you unlock you Modules? Or do you have a tool you apply after installation (perhaps by getting remote access to the Client Systems) to unlock the functionality?
Currently, only we have access to the table encoding. However, we are considering a mechanism that would allow the customer to enter a key to activate a module. The next paragraph will give you an idea why we are considering this change…
Whether or not we do this remotely depends largely on the customer and their policies for allowing remote access. Some of our customers have such strict access policies that, even if you are sitting at their computer workstations, the USB ports, CD-ROM drives, and other media have been disabled deterring you from making any changes, and someone from their IT department must make the changes for you. Other customers allow us unfettered remote access, or give us access through a controlled mechanism (eg. they send us an electronic RSA security key whereby the key code changes every 30 seconds, and that code must be entered before the next change to gain access). The trend is headed towards the strict model as more and more of our customers are adopting this methodology.