Are there any indications that the Valence API would include tie-ins to the competency function? I'm thinking something akin to polling D2L for a competency report of a student indicating completion at various levels (a singular competency, or some hierarchy). Presently there doesn't seem to be anything in the documentation related to the competencies function. Or if it IS there in some form its not jumping out at me where it lies in the shadows.
http://docs.valence.desire2learn.com/reference.html
Awesome competency reporting, including making flexible reporting available via Valence is precisely where we at D2L hope to be hitting in the future, but as you discovered, is not available quite yet. We are initiating a wider cross-product project now to better support competencies & learning outcomes, and this request is noted. That said, I'd also encourage you to ask your LMS admin to send in this feature request via your D2L Account Manager.
Related
at the company where I work, we use OTRS to schedule tickets and such. But the web interface is not very intuitive and easy to use, particularly on mobile...
Is it possible to create my own mobile version of OTRS? I mean, I can create a website that is mobile optimised and easy to use, but is there an API to communicate with OTRS?
I've only seen simple scripts to create tickets via soap or rest interface, I need to create a ticket, show a list of the user tickets and close them, postpone them...
Thank you in advance
It is very much possible, since the OTRS is Open Source and you can basically do whatever you want with it. You might however underestimate the scope of the task you're talking about. I once thought about doing something like this too, but when you look at the functionality the OTRS is providing in the background and all the little details you need for a working interface you will probably come to the conclusion that it requires a LOT of work.
You could use the Generic Interface to create a Webservice that enables you to access ticket information etc. and build your own Frontend that utilizes the Webservice. I can tell you from experience that there is lots of functionality you need to add to the webservice to create a decent API for your Frontend, because the Information the Generic Interface offers by default is very limited.
Since OTRS Version 5 the software includes an interface with responsive design in order to make it better suited for mobile use. Depending on the version you are currently using you might consider upgrading to it. If you want to check it out first you can have a look at the online-demo they feature on their website: https://www.otrs.com/otrs-demo-trial/
If you like the concept of the OTRS but the interface makes it difficult to use for you, the founder of the OTRS released a different kind of ticket system called Zammad. You might want to check it out, it's interface is aimed at being more intuitive.
tl;dr
Yes, it's certainly possible - the OTRS is an open system, but very difficult and probably not worth the effort.
We have an idea to use ADX with MVC 5 and CRM 2013.
Is it possible?
We are doing background research on this whether to use ADX or not.
We have used ASP.NET with ADX previously.
This will help take a decision and will save our time.
Appreciate help if anyone know about this.
Adx portal - http://www.adxstudio.com/products/adxstudio-portals/
ADX offers a great product with an impressive feature list. http://www.adxstudio.com/products/adxstudio-portals/portals-features/
Like any add-on, look to see if there is something it contains that you deem as being vital and valuable enough to justify. Additionally, does your team have the ability/time to create the end product with or without ADX?
This is an opinion based question and in my opinion, none of the features alone justify the price. Especially seeing that ASP.NET + NuGet pretty much covers most of these features already.
Adxstudio Portals delivers managed forms by rendering a form in an Adxstudio Portal based on a particular form or view customization defined on an entity in CRM. Within CRM, entities can be customized and forms and views can be modified or created depending on your requirements.
https://community.adxstudio.com/products/adxstudio-portals/users-guide/managed-forms/
and
https://community.adxstudio.com/products/adxstudio-portals/developers-guide/web-controls/crmentityformview/
Above is the main reason us to consider ADX Studio.
ADX Studio, offers a good tool set to the client that has an internal developing team that will pick it up after you finish to customize it. Basically you provide some page template and the user is able to mess around with the forms to have a tailored experience (this works well when you don't have any logic on the page, just set the page and you are ready to go). Anything that is not in this category is custom made, means that you need to code it, and you will lose all the additional ADX benefits (for what concerns the read/write to CRM). Consider that a CRM developer is not a full asp/mvc developer, so anything that is more complex than change some code behind in a page template will create you problems, also all the jscript on the adx pages needs to be tailored, and you will need developers that are knowing the current web development standards, from Bootstrap to a decent js framework. Personally I'm not a huge fan, but the built-in authentication and some other features are making it a viable product. Consider that to customize it you will need someone that knows responsive design and js.
This may sound like a dumb question on the surface, but why does the Hot Towel SPA Template include Breeze at all?
I've been spending the last few days learning Hot Towel and its dependencies, and as far as I can tell, nothing in the template actually uses Breeze. Perhaps that is going to change with some future release?
Sure, Breeze is a good library. But it's bound to CRUD methodology and requires you design your ApiControllers a particular way. (Metadata, SaveChanges, etc.) see here
It also guides you to Entity Framework. While this is more of a soft-dependency, since Breeze also shows a sample without it, it still guides you down a similar pattern of implementation using a modified repository pattern.
If you are using a NoSQL datastore, or CQRS patterns instead of CRUD, then Breeze becomes very difficult to use. There are alternative libraries for data access that work well in this style, such as AmplifyJS.
But the rest of Hot Towel is excellent! I especially like Durandal. So the question begs, if the template isn't actually doing any data access - why include any data access component at all? It would be better to ship it without Breeze, and if the end-user wants to use Breeze, or Amplify, or whatever - then so be it. The rest of Hot Towel would continue to shine as a great SPA implementation.
Matt - Good question. Since I created it I guess I should answer :)
When I built the template I had a focus on providing enough to get folks going with the right tools, and just enough starter code to guide the way. I did not want anyone ripping out code. I'm not a fan of templates that start you down a path and make you remove tons of files and code and change direction. Those are samples.
Samples are good. In fact, samples can be excellent (like the other templates, which I feel are more like samples). Those serve another purpose: to show how you can do things.
Back to the Hot Towel template ...if I include code that uses Breeze, I would be tempted to add a datacontext.js and a model.js on the client. They would contain data access code and code to extend the models on the client. Then I would be tempted to add a controller, some server side models, an ORM and a database. Once there, I'd want to use the data in multiple screens, which leads me to more Knockout and caching with Breeze. Then I might be tempted to add editing, which would lead to change tracking. Soon I have a full blown app. Or more conservatively, I have a sample again. While these approaches would provide more guidance on how to put these together, they would not help you "get started" with a template where you can just start building and adding your own code. If I stop short of some of these features, it's still walking down a road that requires you to change how I did it.
As it stands today, HotTowel is pretty darn close to a template in the truest sense. You create a new project and you are off and adding your own code.
You could argue (and you may be) that Breeze shouldn't be in there since I don't use it in the template. Nor do I use moment.js, BTW. However, I argue that they are both excellent libraries that I would not want to build a CRUD based SPA without them. Breeze is flexible, as you suggest, so you don't have to walk a specific path.
The best way to understand the value of Breeze is to build an app that has its features but without Breeze. Then you can see how much code that takes and how involved it is. For one such example, see my intermediate level SPA course at Pluralsight where I do exactly this: http://jpapa.me/spaps
So you ask "why Breeze?" ... because I strongly recommend it for building a SPA.
Thanks for asking and good luck !
Thanks for asking the question.
John, as author of HT, has offered an answer. I, as a principal of the Breeze project, am inclined to agree with him :)
HotTowel generates a foundation for you to build upon. It is not the building itself.
It is a foundation intended for a specific kind of application, a CRUD application based on a specific set of cooperating JavaScript and ASP.NET technologies. Breeze is a contributor ... but not the only one. Knockout, with its MVVM design and 2-way data binding, is particularly well-suited to the data-entry tasks typical of CRUD apps.
Of course there are other kinds of SPAs. There's an important class of apps that mostly present information and accept little user input. Such apps don't benefit as much from data binding and the people who write them can get pretty hostile about data binding in general and KO in particular.
My point is that HT targets a particular class of application ... one that happens to be immensely successful at least when measured by sustained popularity. It delivers the goods for people who build those apps. It may not be the right starting place for other kinds of apps.
It is true that the easy road to Breeze runs through Web API, EF, and a relational database. Take those away, and you may writing more code on the server (and a little more on the client). That may be the perfect trade-off for you.
The authors of Breeze would like to make that path easier. I don't think BreezeJS makes it harder. I don't understand your statement "Breeze becomes very difficult to use." Have you tried it?
Your client can communicate with any HTTP resource in any manner you chose. It is pretty easy to use existing Web API controllers (albeit easier with Breeze Web API controllers). You can use amplify.js if you prefer (btw, you can tell Breeze to make AJAX calls with amplify). You don't even have to use the Breeze EntityManager to query and save data if you don't want to.
The rest of BreezeJS may still have value for you. There remains plenty of work to do after you've figured out how you'll retrieve and store data and whether you prefer Entity-ChangeSet style or Command/Query style.
You'll have to find answers to these questions:
How will you shape the raw JSON data into bindable objects?
How will you hold on to these objects and share them across multiple screens without making redundant round-trips to the server?
How will you navigate from one object to a related object as you do when binding an Address to a combobox of StatesAndProvinces?
How will you track changes?
How will you validate them?
How will you store some or all of the data in local storage when the app "tombstones"?
Breeze can help with these chores even if you don't want it to query and save for you.
And if you're answer remains "I'll do all of that myself, thank you" ... well, removing Breeze from your HotTowel project is as easy as:
Uninstall-Package breeze.webapi
I'd like to use WebAPI as my API technology to:
Allow approved companies to enter/retrieve data in my systtem
Create a standard interface for my company's iOS/Android/etc. applications
Does anyone know of best practices for, and mechanisms used to implement, versioning of interfaces. Specifically, I don't want to break backwards compatibility if I make updates to my API. I'd like to know what versioning schemes people use and if WebAPI has any built in mechanisms supporting versioning without the need to set up routes/paths every time a new version is released. Any thoughts would be appreciated.
Update
After performing some research I think I know what I want to do, I'm not sure how to do it. Ideally during content negotiation I would like to use a media type passed by the user to specify which version of the API should be used (rather than hard-coding the URL) and hit the corresponding controller.
If you don't want the version to be included in the Url, the way to go is probably to implement IHttpControllerSelector. This blog post should give you a good starting point: Implementing API versioning in ASP.NET Web API
I recommend you take a look at Peter Williams' series of blog posts on versioning REST services. They explain the what and why. For the how, check out Mike Wasson's tutorial on how to create a custom media formatter.
Basically something that handles the low-level "plumbing" code for a subscription-based service. I see a lot of things dealing with basic membership, but nothing that handles the subscription aspect (recurring billing, automated jobs for setting up billing, notification for billing, etc). This might be the one thing that keeps me from using ASP.NET MVC for my SaaS idea, since it would take a fair amount of development time to write my own; if I go with my other option, Ruby on Rails, I can buy a kit that does all of this for $250. I haven't found anything even remotely close to this for .NET - all of the SaaS sample apps I've seen are more like StackOverflow et all where you have one site that multiple people log on to, not the web application model where you have subscribers who are billed monthly, each of whom has users and other entities (e.g. Customers, Tasks, etc) for their own site.
Is there anything similar for ASP.NET, or some kind of guidelines for writing my own if I have to, so I don't waste too much time? As a startup that means that I'm doing all the coding myself.
I've found this, but it seems to only be for billing and didn't seem to have much (any?) documentation on exactly how to set it up.
Website Spark (Microsoft partner program) just put out Freemium 1.0 which might be a good starting point. I haven't yet played with it, just saw the ad in my inbox today.
http://code.msdn.microsoft.com/WATFreemium
Paul
BrainTree supports recurring billing and offers a (documented) client library for .NET.
Also, they're being used by some big names such as 37signals, github and animoto.
I'm not sure this is entirely helful, but .NET has the built in membership provider that you can ovverride to customize it. If you start with that, it wouldn't be that hard to build in some simple subscription code to handle the authorization. Then you could probably buy a e-commerce library to handle the acual billing code to integrate with a payment gateway and other payment services like paypal.
Personally I would recommend ASP.NET MVC because version 2.0 just came out! Plus your skillset would be much more portable with Win Forms and WPF, and even Mono and the iPhone with Mono Touch! How much of a market is there for ruby right now in your area?