I should model a system that clients can apply some configuration on separated entities.
Let me explain with an example:
We have users that have a config tab in their dashboards.
We have a feature to send notifications on their browsers and we have a feature which we can send an email to them.
We also have a feature as a pop-up.
The user should be able to modify our default notification message, modify our default email template, modify our default text on email or elements.
For the pop-up, The user should be able to modify the width and height of the pop-up, change the default texts, modify background color, change the button location on the pop-up.
And when I want to send an email to the user I should apply these settings on the template then send the email. Also when the front-end wants to show those pop-ups, wants to get these configs from my API and apply them.
These settings will be more and more in the future. So I can not specify a settings table with some fields. I think it is not a good idea.
What can I do? How to design and model this scenario? What are the best practices?
Can I use a NoSQL like MongoDB instead of a relational database?
Thanks a lot.
PS:
I am using Django to develop this system.
I have built similar sub-systems before, by hand.
I don't know much about Django, but do some research to see if it has any "out of the box" or community developed / open source add-ons that do what you want.
If you have to do it yourself...
A key-value pair is not going to be enough, but it's close. You only need a simple data structure:
ID (how your code recognizes this property), e.g. UserPopupBackgroundColor.
Property name (what the user see's / how they recognize this property in the UI), e.g. "Popup Background Color".
Optional - Data type. This is essential if you want to do any sensible input validation. E.g. pop up height should probably expect an integer, and have a sensible min/max value on it, where as an email address is totally different.
Optional, some kind of flag to identify valid properties.
That last flag is bit of an edge case, but it's useful if you use the subsystem to hold more properties than you want users to have access to. E.g. imagine you want to get a list of all properties and display the list to the user - are there any 'special' ones you need to filter out that they should not see?
You then need somewhere to put the values, and link them to the user:
Row ID / GUID. You can use a unique constraint across the User and PropertyID if you wanted to instead, but personally I find a unique row ID is a reliable and flexible approach for most scenarios.
UserID.
PropertyID - refers to ID mentioned above.
PropertyValue
Depending on how serious you need to get, you can dump all the values into the one PropertyValue column (assuming you're persisting this in a database) - which means that column needs to be a string, or, you can add a column per data type.
If you want to add a column per data type, don't kill yourself. The most I have ever done is:
PropertyValue_text (text/varchar)
PropertyValue_int (or double)
PropertyValue_DateTime (date/time - surprise!!)
So when I say 'column per data type' I mean per data type your stack needs/wants to handle - not the 'optional' data types you define in the logic - since that data type is partially just about input validation.
Obviously if you use different logical data types, you can map those to data type columns in the database. The reasons for doing this (using the different data types in the database are:
To reduce the amount of casting you need to do (code to database, and vis-a-versa).
To leverage database level query features, which can be useful. E.g. find emails values and verify them; find expired date values; etc.
It takes a bit of work to build all this, but it's powerful once you get set-up because you can add any number of properties. If you are using the 'full' solution with explicit data types then adding new logical data types isn't too painful if you already have a few set-up.
Before you design and build this, think about future reuse, and anyway you can package it up for later - or community use. Remember it impact all layers (UI, logic and data).
Final tip - when coming up with the property ID's (that the code uses) make them human readable, and use some sort of naming convention so that adding new ones later is easy and follows a predictable path.
Update - Defining Property and PropertyValue in database tables is an obvious way to go. Depending on the situation you can also define Property in code - especially if you don't add new ones or change existing ones very frequently. Another bonus is that if you're in an MVP situation you can use the code effectively as a stub, and build out the database/persistence part for that later.
Related
We have a WPF desktop application that uses MVVM pattern and DDD (well, let's say that at least my model classes that store data named by entities taken from the real world). APP uses several microservices through REST API. And it worked perfectly. Until we thought that it's time to use some facade for back-end part to unite all those microservices and get only data that we need for particular screen.
BUT. The question is, how to make them live together.
On the one hand, we have dynamically returned data from graphql. It
means that, for example, if we have list of people on the one screen,
we will request id, name, surname and role of the person. On the
different screen for dropdown of people we will request the same data
but without role.
On the other hand we have class Person that has static set of fields Name, Surname, Role and Id, which person has in "real life"
If we use the same Person class with graphql, converting data from JSON to model Person, both screens will work fine, but behind the scene one screen that doesn't need Role wouldn't request it from graphQL. And we will have a situation when model class Person will have field Role but it will be just empty (which is i believe is kind of smells. At least I don't feel like it would be easy to maintain such a code. Developer needs to add some information to the screen, opens model, sees that Role is there, bind the field to the screen and goes to drink cofee. And then oops, there is the fields but there was no data assigned ).
Two variants I have on my mind are:
either to not use models and DDD and map data directly to ViewModel
(which personally feels like ruining everything we had before).
or we map that dynamic data to our existing models and different field for different screens (for the same class Person e.g.) will be
empty (because not requested).
Maybe somebody has already used such a combination. How do you use it and what pros and cons are?
It's a fairly common situation where you have a data layer returns many columns but only some are used in a given view.
There is no absolute "best" solution independent of how much impact the full set of columns will have on performance. Which might in turn be linked to things like caching.
You could write services that return subsets of data and then you only use the necessary bandwidth. Sort of a CQRS pattern but with maybe more models than just read + write.
Often this is unnecessary and the complications introduced do not compensate for the increased cost of maintenance.
What is often done is just to map from model to viewmodel (and back). The viewmodel that needs just 4 columns just has 4 properties and any more returned by the model are not copied. The viewmodel that needs 5 has 5 properties and they are copied from the model.
As the subject reads, I have several use cases where it would be really useful to change the values in a picklist to only include certain values when data in another object changes, is this possible to do from within a trigger?
e.g. Update a picklist of active employees when people leave or join the company.
Out of the box - no.
Picklists can be controlled with Metadata API (and in future maybe Tooling API too) - but from Apex point of view you need a callout. Either to external system that'll leverage the Metadata API or have a look at Adding Columns dynamically to Salesforce Reports - there's an interesting "mdapi" plugin that you might decide to use. Bear in mind destructive changes (like removal of values) are pretty annoying to execute...
In this particular example it's very tempting to say "you're doing it wrong" :(
A lookup to User will out of the box hide users that aren't active. Problem solved.
What are you going to do when the organisation will grow (through acquisitions?) and you'll hit the limit of max 1000 picklist values? http://help.salesforce.com/apex/HTViewHelpDoc?id=picklist_limitations.htm (probably even sooner depending how much of the 15K limit you've used already)
Personally I consider a picklist with anything more than 50 entries a crappy UI / user experience. Well, unless there's some kind of autocomplete paired with it. Scroll, scroll, scroll...
I was wondering if someone could point me in the right direction.
Here is my problem: I have a large form/checklist that I would like to make digital for ease of use.
Thoughts: I would like to use existing tools that would be easy to integrate. My first option is Access 2010.
My question: I would like to enter the questions into a database and then use those entries to auto generate a form that can be used to allow the user to input the actual data into the database. An example would be I have 11 Sections of questions and under each section I have sub-sections that can contain anywhere from 1-... how many every questions we need.
Is it possible to use data stored in an Access database to generate a form with Checkboxes that can be used to input data?
Please point me in the right direction. Obviously there is the option of just creating multiple forms or one big form, but I would like this form to easily be changed etc... Less work more automation.
Thanks,
Alex
Depending on the requirements of your project, this may be quite possible. If you want to use Access as both the back-end and front-end, then you'll need to work within a few limitations:
Because Access combines the user interface and design interface into the same screen, it requires a certain amount of trust that the user can't or won't try to get too creative with changing the data, seeing everyone else's data, changing the design of your form because they are bored, etc. There are ways around these problems, but they can get complicated.
Will all your users be using Window's machines with Access 2010 installed and with the original default settings? If so, good. If not, there may be ways that this could still work.
(There's more, but that's all I can think of right now)
To get started, here's a broad outline:
Make a table for your questions. This table would just have the questions.
Make a form using that question table as the source. Leave the checkboxes and other answer fields unbounded. Include a 'submit' button at the bottom.
The submit button will create a sql query to insert the user's answers into a 2nd table.
If you have any specific questions, we here at SO will be glad to answer them.
In order to dynamically and easily change the number of questions in the sections, what I would do is:
In the main Questions table, add a field called Section to allocate the questions into diffferent ones, and another one Yes/No field to select those that are included (you may also exclude them by leaving the section field empty, as you wish). This will solve the problem of changing the design easily. you probaly will need an admin form in order to do this changes, to avoid touching the tables directly, but this is your decision.
Secondly, in order to allow the users to efectively answer the generated form, you have to ask yourself if you want to accumulate the answer sets, and if you are going to control who answers
I know you can set client permissions for a whole dataset like so:
<dataset name="foo" databroker="bar" client-permissions="view"/>
Is there a way to set client-permissions on just one field (similar to how other metadata like "valid" can be set for one field)?
Note: this is in Aviarc 3.5.0, so data bindings are not available.
Update: The use case I have in mind is a search parameters dataset. If I arrive at the search screen from a certain location then one parameter should be locked, because the search results should be filtered by that parameter.
Creating a new databroker for what amounts to a scratch search parameters dataset, just so I can set the read-only property on a single field, is really looking like overkill.
Update: Just to clarify, the dataset doesn't currently have any databroker bound to it, it is just used like a hash to store search parameters.
There isn't currently a way to set client-permissions on a single column/field.
It should be possible to set a datarule on a column which prevents the column being writable by anything other than dataset refreshes.
When I have individual pieces of data which should be read-only but are included in client-writable datasets, I keep copies of the data in non-client writable datasets and overwrite the client-writable ones when they get back.
As mentioned, data rules have the facility to set read-only on individual fields. They can be set on a given field for all rows, or on a field of a single row.
Adam has mentioned that creating a separate databroker for this case would be overkill, which is correct. The DataBinding layer is intended to provide this kind of specialization for certain use cases within your application.
So, you would create a DataBinding, pointing at your search DataBroker, that adds the rule you require to either an existing operation, or a new one that you define. The Dataset is then bound to the DataBinding instead of the DataBroker and from then on is used in the normal way.
The intention is that rules bound by DataBrokers apply to all data of the type supplied through that broker, so would be rules focusing on data integrity, formatting etc.
The DataBindings on the other hand are a layer within the application allowing you to bind rules relating to user interaction with the data, as in your example. It is expected that there might be multiple databindings for a given broker, each for a different application path or user task to interact with that data in a different way.
It should be possible to work around this by isolating the parameter I want to be read-only into its own dataset, and setting client-permissions to 'view' just for that parameter/dataset.
This does add the overhead of having to add a special case for that parameter, but I shouldn't need to extend it to any more special cases.
I've run into reoccuring problem for which I haven't found any good examples or patterns.
I have one core service that performs all heavy datasbase operations and that sends results to different front ends (html, silverlight/flash, web services etc).
One of the service operation is "GetDocuments", which provides a list of documents based on different filter criterias. If I only had one front-end, I would like to package the result in a list of Document DTOs (Data transfer objects) that just contains the data. However, different front-ends needs different amounts of "metadata". The simples client just needs the document headline and a link reference. Other clients wants a short text snippet of the document, another one also wants a thumbnail and a third wants the name of the author. Its basically all up to the implementation of the GUI what needs to be displayed.
Whats the best way to model this:
As a lot of different DTOs (Document, DocumentWithThumbnail, DocumentWithTextSnippet)
tends to become a lot of classes
As one DTO containing all the data, where the client choose what to display
Lots of unnecessary data sent
As one DTO where certain fields are populated based on what the client requested
Tends to become a very large class that needs to be extended over time
One DTO but with some kind of generic "Metadata" field containing requested metadata.
Or are there other options?
Since I want a high performance service, I need to think about both network load and caching strategies.
Does anyone have any good patterns or practices that might help me?
What I would do is give the front end the ability to request the presence of the wanted metadata ( say getDocument( WITH_THUMBNAILS | WITH_TEXT_SNIPPET ) )
Then this DTO is built with only this requested information.
Adding all the possible metadata is as you said, unacceptable.
I will surely stay with one class defining all the possible methods (getTitle(), getThumbnail()) and if possible it will return a placeholder when the thumbnail was not requested. Something like "Image not available".
If you want to model this like a pattern, take a look at the factory patterns.
Hope this helps you.
Is there any noticable cost to creating a DTO that has all the data any of your views could need and using it everywhere? I would do that, especially since it insulates you from a requirement change down the line to have one of the views incorporate data one of the other views uses
ex. Maybe your silverlight/flash view doesn't show the title itself b/c it's in the thumb now, but they decide they want to sort by it later.
To clarify, I do not necesarily think you need to pass down all of the data every time, but I think your DTO class should define all of them. Just don't fall into the pits of premature optimization or analysis paralysis. Do the simplest thing first, then justify added complexity. Throw it all in and profile it. If the perf is unacceptable, optimize and try again.