Hi I'm in a scenario where I'm thinking about to have several modules, and let modules depends on other modules.
say that we are building a business system while one part is invoicing and we have customers in different branches.
So one industry may want to use some tools and create the invoice in their way, and another industry may want to do it in another way. So I think we can do one module per create invoice method so when the application loads we can see in the configuration what module of the crate invoices module who have to load.
So to my first question, is this the way to solve this problem or are there more better solutions?
My next question is where should I put them in a tree?
Should the modules that depends upon Invoicing module be put under the Invoicing module or the same level?
I would first work on creating a viewengine to load view based on context criteria.
The criteria can be tenant (domain name), device, view size, current theme (all of these interfaces your viewengine depends on)
Maybe using an approach like DataTemplateSelector scattered across your views needing customization. You would probably want to approach it like in asp.net mvc to resolve the views (so you have the ability to override views) based on view search paths.
You would need to be able to load into app resources tenant styles for custom branding.
I would push back in creating your fine grain dependencies until after the above begins to show maintenance problems. For business logic that needs customization you can use a strategy pattern.
I see it costing more upfront to break it out now and having to manage these long dependency chains. The cost to implement later (after a good business feature requires it) will only take a few hours of work using ModuleInfo as explained here:
Silverlight PRISM Creating a custom module catalog
We choosed to go with modules, and I put them under the depending module in the tree.
It worked really great.
Related
So I'm trying to build an app that has two different kind of users, namely customers and sellers. The app is designed in such a way that both of them will have different kind of navigation bars and access to different kind of pages via routes. As such, I'm trying to see what is the best way to achieve this? I'm thinking of either of the following solutions:
1. using compose binding or areas in my shell.html and by having a container and based on a certain condition, the correct specific view (partial view)will be injected and the default binding context will be a common shell.js. However, the nav bar and each navigation panel displayed is determined by the routes that have
nav:true
and both seller and customer will have different routes that are marked nav:true. Is there a way to work around this limitation if we use this approach?
2. using compose binding but having two different views and viewmodels that we bind to our shell.html and shell.js. In other words, there will be two routers. However, I've read a number of posts about having two routers and apparently having multiple main routers in an app is not suggested. Is there another way I should approach this?I was having thinking of having multiple SPAs but I figure that would not be efficient since this is a mobile app. Any help or suggestion is greatly appreciated!
You could simply develop two separate SPAs, but have them share much of the same codebase. With this approach, there's nothing special going on, other than your responsibility to modularize your code for reuse.
This approach would also eliminate the need to incorporate extensive logic throughout to curtail, trim, or augment the web app based on the user currently logged in.
Based on a specific application (bakery ERP), I need to create a new branch as a general purpose ERP with basic functionality (invoices, orders, work orders, customer communications...).
This new branch must be customizable for each client: print formats, application colors and icons/images, and restricted access to some application parts...
I've read about resource files for text/icons/image customization, but I need some help or alternatives, maybe defining an Interface to provide needed resources.
I use DevExpress components, so, print formats, and forms layout can be customized storing formats and layouts in files. However, main form has to be completely redesigned, and i wonder about the best way to do this. ¿this can be done with a little project containing the main form and implementing an interface providing custom images for buttons and other customizations?
Apart from layout customization, I need to restrict access to some parts of ERP for each customer, but behavior customization will be minimal or nonexistent, so, maybe I can personalize behavior with an xml config file for each customer.
Independently of my ideas, I thank you for any idea or comment about mu purpose: interface customization for each client, and minimal behavior customization. Don't need complex solutions like Workflow Foundation or completely pug-in based development.
If it's only format of prints and screen images, just use resource files or database configurations.
If you need functionality to be changed - use interfaces and inject their implementation via some framework, like MEF, for example.
And your English is good, no need to sorry
As often happens, I have a nice solution to one problem, which unfortunately causes another.
We have an app that provides services to members of various organizations, parts of a larger parent. The organizations require custom URLs. So, members of org A access the URL https://server/vdir/OrgA, and members of org B access the URL https://server/vdir/OrgB.
Both of these would map to the exact same area, controller, and action in the app, although they might look different to the end user due to some custom view content.
Because the list of organizations using this app is dynamic, and because not all organizations will start using it at the same time, I started out setting up the route mapping programmatically. In the target Area, I override the RegisterArea method, pull the active organizations from the database, and execute a custom context.MapRoute call for each.
Doing it this way avoids another problem, which was that the the URLs that have the organization sitepath ("OrgA") in them look exactly like those that have a meaningful area name in them, which actually does map to an area. Treating the organization sitepaths as virtual area names and explicitly mapping them to the target Area avoided certain misdirections.
And this works, nicely. But: it's all executed at Application_Start. If we add an organization, it doesn't become active until we restart the app, which would be highly disruptive to anybody who was using it at that time.
So my questions are two:
Is there a better approach than mine for doing this? I did research the problem, but the relevant keywords are so ubiquitous that it was a bit of a needle-and-haystack situation.
If there isn't one, is there a way to refresh the route mappings without restarting the app?
Phil Haack wrote an article dealing with exactly this problem.
The really, really short version of which is that you place your route registrations in a file other than Global.asax and cache the contents of that file. The cache has the file as a dependency and calls a method when the cache is invalidated (read: file is altered) that re-registers your routes.
I'm working on some new software, and I'm trying to make it as modular as possible. I have been coding for a while..but I lack some key principles which I am learning as I go along.
In trying to make my current project modular, I am using the model-view-controller architecture. In designing my application, I have found certain things I am unsure of. So I come to you...
I'll give you some information which may be useful:
I am developing this application in Qt.
It is a desktop application.
Single user, so it is not very complicated
My questions are:
When implementing the various modules(models, views etc..) and all
of the classes associated with them, should I be initializing
modules within modules? Should I create a 'model' instance within a
'controller', or should I create everything in 'MAIN' and simply
pass the modules as references?
My strategy is to separate my application into many MVC bundles.
Each one will follow the basic principles: model gets the data, view
displays it, and controller takes care of all interactions between
model-view, and performs all required logic. Is this correct?
I appreciate all of your help.
Thanks.
Should I create a 'model' instance within a 'controller', or should I create everything in 'MAIN' and simply pass the modules as references?
Pass the modules as references. I don't know if Qt has the concept of packages within a bundle, but in Java, I have separate packages for the model and the view.
My strategy is to separate my application into many MVC bundles. Each one will follow the basic principles: model gets the data, view displays it, and controller takes care of all interactions between model-view, and performs all required logic. Is this correct?
Yes, that's correct MVC principles.
Sometimes in a more complicated application, your application view might consist of the GUI (a view) and a model of the GUI (a model). In this case, the application model, which is probably a database access model, interacts with the GUI model. The controller for both the GUI and the application is driven by the actions of the user.
I just started learning Zend (& OO PHP for that matter), I have spent the last 4-5 weeks learning, tutorials, books etc. I feel good about it but will bog down in the models (thats ok, I'm learning). I am now beginning my first app (for work even); It has at least 5 major sections (including the login + will need ACL), and a couple will have up to 10-12 sub sections like admin: create user, edit user, etc.
I created a single layout, and have made most of the page views with working links, and have a few of the forms complete already.
My major concern now is should I refactor and make modules of the major sections before it gets out of hand, or am I worried about nothing. One thing I think I did wrong is that I have a 'AdminController' that does nothing but bring in the admin 'view' that is nothing more than links to each 'user' action in the 'UserController'. I'm thinking maybe I should have put the user actions in the AdminController. I'm thinking too, that I should make a 'admin' module, 'reports' module, 'auth' module, etc. Or is it normal to end up with 8 controllers and growing? I already have the inclination to make and maintain a developer's sitemap just for my own sanity, not to mention that I want to do the best job possible :)
In principle, I like the idea of a plugin-able module for each set of functionality - News, Users, Galleries, etc. "Plugging in" that module would provide functionality for the back-end admin and the front-end display. It is a self-contained place to put all the functionality - models, action helpers, view helpers, view scripts. etc - that you need for that content area. There might be two controllers per module - News_BackendController and News_FrontendController - dedicated to their specific areas.
But in practice, I find that ZF modules make that hard. I know that smarter guys than me - a low bar, to be sure - can make it all work, but I've never had luck with it.
So I usually end up with two modules - frontend and backend. For news functionality, for example, I'd have a news controller in the backend module for managing the content; another news controller in the frontend module for displaying it.
The sticky point for me in this setup is where to put model functionality that is common to both frontend and admin. One idea is to put it out a separate library and then create module-specific models that extend these for any module-specific functionality. Something like:
MyLibary_Model_News for the common news stuff.
Frontend_Model_News extends MyLibrary_Model_News for any frontend-only news functionality, if any.
Admin_Model_News extends MyLibrary_Model_News for any backend-only news fnctionality, if any.
Just some ideas. As always, YMMV.