I need to implement data sharing feature for my app. The data type that I need to share is very specific and is not available on schema.org. This is an enterprise app and we have no need to share this data with any outside apps. I couldn't find any example or samples about how this type of data could be shared. I will really appreciate if someone can provide code sample on how this could be done.
The custom data format string you supply is really up to you. Schema.org is mentioned because it provides an agreed-upon format for many types of data making your app more discoverable and interoperable, but in the end the schema.org url you provide as part of the sharing contract in your application manifest is just a string. You can name your format whatever you want, and as long as you make the share source and share target aware of that specific format (via the manifest) and are consistent with how you create/parse the payload it should just work.
For instance, I took the share source and share target examples from dev.windows.com and changed the custom data format id to "gggggg" and it works fine. Now, of course, any applications that originally knew how to deal with "http://schema.org/Book" (the original type used in those samples) no longer are share targets, but that's precisely what you'd want.
Related
Disclaimer: I know that DDD/CQRS might not be a perfect choice for below use case, but it was working great so far for other tasks in the project and I want to stick with it for learning purposes (eg. learn the hard way where not to use it ;).
Let's assume I'm building a Blogging Platform and have 3 types of posts: LifestylePost, RecipePost and ReviewPost. They have the same abstract base class PostBase which is an Aggregate Root and all of them share some properties like Author or implement methods like Publish, Delete etc. which change their Status and verify whether the state is valid. Each created post starts as a Draft which barely requires any validation, but switching to Published verifies nearly all properties.
Implementing commands/handlers like PublishPost or DeletePost was a breeze, but the problem starts when I'm thinking about CreatePost or UpdatePost. These are some dilemmas I'm currently facing:
Create/update commands/handlers for each post types or one for all
Having them separately for each post types gives me more control over the logic, allows to tailor each command model precisely, but makes my API more complex for the client. With the second option I can resolve the post type by some discriminator in the command and check whether all necessary properties for that particular type were provided.
Create empty post draft first or already filled with the data
When a user creates a new post (draft with an initial state) I can already call the API and add an empty post to the database, which would then be updated or I can wait until user inputs any data and clicks save. It's basically a matter of the arguments in the constructors of the posts.
Handling post updates in general
This is the point where I'm having the biggest issues now. Since there are quite many properties that could or could not be changed by the user, it's hard to split them to particular methods inside the Aggregate Root different than just Update with huge amount of nullable arguments where null would mean that the property has not been provided by the client and therefore not changed. Also adding Status property here would mean that the proper method for validating the state would have to be resolved. This solution somehow doesn't feel like a proper DDD design...
Which decisions would you make in each points and why?
Create/update commands/handlers for each post types or one for all
Depends on whether the difference in post types has influence over the API or not. If your clients have differentiated interactions with your API depending on the post type, then I would have specific commands for each type. If your API is post type agnostic, then this is internal business concerns. You should then ensure that domain implementation is sufficiently different from type to type, because polymorphic domain is a lot more work than a simple "category" property.
Create empty post draft first or already filled with the data
Depends on whether knowing a user has started working on a draft has any value for your system. If it's like a personal blog, probably not. If you're writing software for a newspaper, then it could be insightful to anyone. Ask your domain experts.
Handling post updates in general
This is an interface design question rather than a business logic one in my opinion. If your users want to do a lot of small changes, you should consider providing PATCH routes in your API, with a standard like JsonPatch. Depending on your implementation technology, you could benefit from libraries that does the object patching for you, saving a lot of code writing.
Is there really a difference in behaviour between the post types? Don't they all have Draft(), Publish(), Cancel() behaviours?
Given that inheritance means X is a Y, then you're basically saying they are all the same. This feels to me like a single Post aggregate with the possibility of a "PostType" value somewhere that might be part of an invariant (e.g. if you had a business rule that says "Review Posts cannot be published until a cooling-off period has elapsed).
This would mean a single set of application services to invoke those methods (and validate the invariants they implement).
I have a CRM system. I need to implement grabbing Contacts’/Accounts’ data from third party APIs by user provided IDs and loading details into CRM. The problem is that API responses may differ e.g. by Accounts’ legal form or something like that. Moreover I need to check received responses against other corporate internal information systems. I understand OOP and all that stuff rather well. But everything still looks very tangled and tedious. And I wonder if there are any methodology(ies) of working with external data. Any books to read or videos to watch? Any well-known design patterns for such tasks? Any ideas appreciated!
Look into adding an anti-corruption layer to your application. In short it is a layer of code that consumes your 3rd party APIs and maps the results into objects defined by your own app, stripping out useless information and allowing you to dictate what the integration should look like. You will have some messy mappers inside this layer. But any data escaping this layer should be easy to use for the rest of your app.
This answer will explain in more detail.
I'm building an API and I have modeled the entities I need inside it. By example
User
Name
Email
City
Company
Name
Website
I'm using Blueprint to specify the API itself and I need to create endpoints for CRUD operations in pretty much every entity. The task seems very redundant to me - besides some tuning that is needed in some specific entities, most of the basic skeleton looks like the same.
I wonder if there is any tool that allows me to write down my entities, its fields and types and generates this basic skeleton.
I was about to start creating one and then I stopped to look around if there already is one but I did not find anything yet...
API Blueprint contains a tool to write, use, reuse, compose, inherit your data structures, and it's MSON.
Basically it's a way to describe your data structures within an API Blueprint. We do also provide an html renderer for that, and it's the Attributes Kit. Try also to have a look to its Playground.
You can find an useful tutorial on official website, as well more information.
Hopefully it should be enough to get started.
Cheers,
V.
I got a DDS-system(OMG DDS) who's communicating with a ROS-node over radio. The information being received is a struct with velocity, state, longitude, latitude etc. This works well, and my DDS-client has no problem printing the information being transmitted from the node over the radio. Now, I've got a GUI-application written in Qt, who creates models and puts them on a predefined map. These modelse have defined set-information functions, which when triggered updates the map to give a smooth visualisation of the information it receives.
Now here is problem, I've no idea how to make the GUI application communicate with my DDS-client. I would rather not intertwine these two, since I've had enough trouble just making the DDS-client and sender work and compile with ROS. Ive though about a separate queue system, which can be included in the DDS-client and the GUI application, but I dont know if this could work. Ive also though about writing a SQL database, and then push new data, and pull new data when it is detected in my GUI application. Some sort of on_data_available function which triggers the pull-function. Ive heard the last one is a bad idea, since I'm working with only one set of data which is being continuously updated (the model represents one USV), and a database is then considered overkill, but I would love to get inputs here.
Im sorry if this isn't sufficient information, I can't really provide code examples for different reasons. If anyone have any inputs, shout out, would love to hear them. And if I'm not being specific enough, ill try to rewrite it as best as i can.
I've no idea how to make the GUI application communicate with my
DDS-client
Your question is not specific to DDS or your GUI application -- you essentially ask for a simple and convenient inter-process communication (IPC) mechanism. As you can see when you follow the link, there are loads of different options.
Given that you already have your data as well as the associated type definitions available in DDS, I suspect that using DDS for this task would still be the easiest way to go. You could set it up to communicate over shared memory or local loopback. DDS will do all discovery and communication under the hood, including (cross-language) de/serialization. If you choose a different mechanism, you might end up doing more work yourself.
As an alternative, some DDS implementations (commercially) support native integration with SQL databases. Those will introspect the DDS data definitions and create all required tables for you. Updates from DDS are automatically forwarded to the database, and vice-versa. You could feed your GUI off of that database.
I am doing Objective C programming and I want send and receive requests(Login/data fetching) over the client/server.
Now the problem is Should I do it using XML or any other Method.
Also I know nothing how to write XML for any particular website.
I am hassling for many days.Can anybody help?
XML particularly SOAP is very bloated and the support in Objective-C is severely lacking. I would recommend JSON for lightweight use and in fact Apple use it for their Push Notification server.
If you DO want SOAP then check sudzc.com for an online objective-c generator from a WSDL.
There's no such animal as "any particular website." Some return data in HTML, RSS, ATOM, or JSON format, others may use a custom XML schema all their own. Likewise with the data you send; they may expect requests via SOAP or HTTP, with any type and number of inputs the creators chose.
In short, you need to find out exactly what is expected by the one particular site with which you're trying to communicate, and give it what it wants. That's why programmers get paid the big bucks, because there's no easy "do what I mean" button. :-)
Your question is whether you should use xml or any other method of communication.
XML has been designed to standardize communication, which is especially handy for communicating between several parties, as the structure of the document can be formally written down in a document and can be validated, so there is no discussion afterwards about the syntax of the document.
Although that is a noble idea, XML is relatively complex and not as light weight as, for example, json.
As long as you are writing your own client that communicates to your own server, the protocol used between those 2 can be anything, and do not need to be XML.
Therefore I would suggest using a lightweight and easy to understand protocol. Json is gaining popularity due to its simplicity.
If you have control over the output of the data on your server, I'd suggest you output the data directly as a plist. Plists are native dictionary objects that can be directly instantiated with [NSDictionary dictionaryWithContentsofURL:].
Take a look at the PList programming guide for proper formatting.