I need to design about 20 forms for various business processes.
We have to do this for about 10 countries and need some form of object prietnted approach because each country has different business rules and some different bits of data. However, there is also common data between some of these countries.
For example, we have 5 bits of data, 4 are common to every country, 1 is specific for individual countries.
eg common Name, Address, Telephone, Male/Female
eg Bonus payment
It's a question of how do you manage all the code changes easily in an enterprise application without the code being too unwieldy?
It's not just the languages, that would essentially be driven by a config code that lists the names for the lables...but also each form may have most of it's design from a gloabl form and then less from a local form, local to the specific country.
Isn't there some way to build a dynamic form on the fly so that you have 1 form ProcessBonus for every country, that form inherits fields from MainForm, and then it checks configuration Class in the background to build the form dynamicaly for each country?
I'm trying to avoid having 10 form types and then another 100 local forms for each country, that would be well over 1000 forms and would be unmanageable wouldn't it?
Actually what you need to achieve is Multiple Inheritance. .Net technologies , PHP, FLEX etc some other languages doesn't support multiple inheritance. Thus, Interfaces are used as a hack to achieve multiple inheritance.
You can find the implementation of interfaces in this link.
http://www.codersource.net/MicrosoftNet/CBasicsTutorials/CNetTutorialInterfaces.aspx
Related
I am creating a database in MS-Access to manage product specifications. Some products have overlapping specifications and some are unique.
My initial approach to this problem was to create multiple forms. For Example: an extension cord specification needs copper, compound and plug information. This information is also needed for a power strip specification, as well as other information that is ONLY pertinent to power strips. Currently I have created multiple forms for the different products. Is it possible to save multiple forms into a pdf for the same part number?
I know I can create a long form that is split on different pages, this method could work if I could not save or print certain pages depending on the product too. Any help is greatly appreciated.
I have shown in the picture below a portion of the forms and how some information is relevant only to the product class.
I know I could create forms for a basis of every category of inventory, but then I would have to create a full specification form for over 10 products, I am trying to streamline and reduce the amount of front end work required to generate specs from our database
Please excuse me for bad title. I couldn't think of any better. Feel free to suggest a better one in comments.
I have a case, where I need to have a dynamic number of columns. In my example addresses.
One customer want 1 address and other wants 7 (bill address, deliver address, bid address, bill address, confirmation address ...). I do not want to create all possible columns for all application setups. But provide some sort of mechanism that every user should set (in program) how many and which information's they need.
I know entity framework do not support dynamic tables. But I am sure many had the same problem. Maybe string[] would suite best, but EF Core doesn't support it.
I could store all addresses in JSON, but then I loose options to filter and sort by this columns in SQL (LINQ).
Is there any common pattern to achieve dynamic columns and keep server filtering (maybe ordering)?
I currently have a Web API project which currently has all the system processing in the same solution. I'm breaking this out into separate solutions so that they can be ran independently (e.g. an Azure WebJob) as I don't want to have to redploy the Web project if something in the backend has changed.
My issue with this is that even though I have separated the logic they are tied together by a single context so that if I make a change in one I will have to redeploy all as the migrations won't match up.
So that's why I've been looking at Bounded Context and DDD. I'm looking at how to break this up but having trouble understanding how relationships work.
A lot of the site is administrative (i.e. creating entities, no actual processing) so was going to split contexts around this e.g.:
A user adds and maintains currency conversion rates (this is two entities in
total).
A user adds and maintains details on how to process payments (note that is is not processing payments, it only holds information about paypal account details etc).
So I was splitting the context's up by this, does this sound reasonable to start with (there are a lot more like this such as tax bands, charge structures etc)?
If this is the way to go, how do I handle relationships between those two contexts? As an example:
A payment method requires a link to an 'active' currency conversion. I understand I can just have this as an Id, but I need to check it's state so need access to the model.
A currency conversion can only be set to 'Inactive' if there are no payment methods currently using it. Again this needs access to the other model.
So logically the models need access to each other, how would this be included in the context? Can I add navigation properties to a model in a different context? Or should I add it as a separate DbSet and possibly map using a view?
Thanks
So I was splitting the context's up by this, does this sound
reasonable to start with (there are a lot more like this such as tax
bands, charge structures etc)?
"So that they can be ran and deployed independently" may not be a sufficient heuristic to tell when you should split Bounded Contexts. This addresses one aspect of the solution space, but if you haven't looked well enough at the problem space, you'll suffer from a misalignment between BC's and subdomains that can cause a lot of friction. You might end up always deploying a cluster of seemingly unrelated "independently deployable units" together because you didn't realize they talk about the same thing.
Identifying subdomains is the product of distillating your business - separating the big functional areas and defining which parts are your core domain and which are ancillary activities. Each subdomain has its own specific semantics (Ubiquitous Language). In your case, as has been pointed out in the comments, Currency Conversion and Payment Methods might well be part of the same subdomain (Payment?). It does not automatically mean that they should also be in the same BC but it might be a good idea to keep subdomains aligned 1-to-1 with BC's, as additional BC's come at a cost.
Back to deployability, even if it can be one beneficial effect of Bounded Contexts, they are not always so easily translatable in terms of independent units of deployment. Context mapping patterns (Shared Kernel, Customer Supplier, etc.) and BC communication in general can lead to a model, and therefore a part of a codebase, being shared by multiple BC's. Code and API synchronization issues arise that can question a simplistic "deployable free electron" view.
Just because you're using the Bounded Context approach doesn't mean you have to use DDD's tactical patterns (Aggregate Root, invariants, etc.) inside each BC. Using them should be an educated decision to trade solution space complexity off for problem space manageability. If "Currency Conversion can only be set to inactive..." is the only rule pertaining to payment method and currency management in your business, it might not be worth the bother to give that Bounded Context a full-fledged rich domain model. CRUD could be better suited there.
I'm currently writing automated tests for a GWT application using Selenium and Java. For page elements that are Widgets, this is relatively straightforward, given that unique IDs can be set using the ensureDebugIds() method.
However, some types on the pages I work with are not widgets, but other types, possibly container types (such as Cells or grid rows that are essential HTML tables). Is there a similar method to ensureDebugIds() for this? Or is there a way to create custom IDs for these elements that acts in a similar way compatible with ensureDebugId()?
You would need to closely collaborate with you dev team to set Id's on any element which GWT does not handle in its ensureDebugId. Its straightforward to id as all UIObjects have setId api. If any HTML code is being is injected then ids need to be determined by a simple convention and set up for Selenese test case writing to be easier.
i have a decent understanding of configuring drupal and using modules for basic stuff, but just getting into module development and overriding functions and stuff due to my very basic understanding of php and mysql.
i have a custom content type ('books') and a 3 cck field for genres (primary, secondary, tertiary). i'd like a user to be able to filter a view of all books with one exposed multi-selectable 'genre' filter. that's where i'm stuck-- i understand how to have three exposed filters for the 3 genre 'weights' (primary, secondary, tertiary)--i want one filter that would allow users to select any or all of those weights.
is a custom search form my only option? was there a better way to set things up? would i have been better off using one cck field for 'genres' with multiple entries? i ruled this out because i thought it would be harder to determine the genre 'weight' (primary, secondary, tertiary).
thanks a million.
Think about what the meaning of genres to a book is. Taxonomy is just what you use for this kind of thing. There are several pros using the taxonomy rather than using CCK fields.
Taxonomy is meta data, CCK fields are not. This mean that the way the html is generated for taxonomy terms, it will help SE to understand that these genres are important and it will give you a free SEO
You can setup how genres should be selected in far more detail than a CCK field. Again since taxonomy is made for exactly this kind of thing. You can setup how users are presentated with the genre selection in various ways. You can predefine genres or let users enter their own as they like. You can make child-parent relation ships and more
It's easier and more lightweight to use taxonomy than CCK fields.
If there only is 1 or 2 genre inputted you wont have to have empty CCK fields.
probably more that I can't think of right now
Using taxonomy you can pretty easily make a search with views, where you make it possible for users to select genres using a multiple select list. You can decide if you require all terms or only one of them. Simply put you should really use taxonomy, it should solve all of your problems, if not, you should still use it and try to solve the problems you could get using taxonomy instead of CCK fields.
Jergason has a good point saying that taxonomy would probably be a good fit for your fields. However this wouldn't solve your problem of weighted genres.
A possible (though hacky) solution would be to have a fourth field which combined the values of the other three which is only set when a node is saved. This field could then be used for searching.
The non hacky solution is to write your own views filter but this is very advanced.
There may be a way to do this with views out of the box it is flexible, hopefully someone else knows of an easier non hacky solution.