@danny - I wrote up an example of how to build this yourself.
@danny winbourne I would like the media picker as well - it seems like a better option than page attachments.
I should have a working prototype within the next week or two that I can post on Github.
That said, it would be nice to have official Widget packages/solutions from Kentico for things like this.
Hi, Thank you very much for this idea.
Code/API tweaks like this have to be done with caution and piece by piece. I am wondering what concrete scenarios required the async API in some way. Could you be so kind as to describe what did you implement with a need of async API?
Maybe an async version of ObjectQuery could be just enough.
Platform Product Owner
The lack of this feature is even more noticable now with MVC in Kentico 12. The rest of the ASP.NET / .NET world has moved to async/await for db, filesystem, external web service calls. Kentico's data access layer is still sync in 2019.
It would be great if we could leverage the async model binding for .net 4.6 webforms
I imagine a scenario where I need to pull data from a Kentico custom module class provider, the ShoppingCartInfoProvider and a Tax provider that makes async requests to a remote web service.
Thanks for responding!
At my company we integrate a lot with 3rd party web services which are often REST-like APIs. Sometimes these calls can take some time to complete and if we have to make multiple calls serially that can lead to the thread in IIS being locked for a period of time.
If we could implement async throughout the entire request/response lifecycle then the threads could be used to handle other requests while the API calls are blocking.
Since it is recommended that when implementing async it should be implemented 'all the way down' (http://blogs.msdn.com/b/pfxteam/archive/2012/04/13/10293638.aspx) it would make the adoption easier if Kentico also exposed an async implementation.
I would have to explore a test example to be certain, but I feel as though an async ObjectQuery would possibly be sufficient.
56 votesShare your thoughts · 10 comments · Kentico Product Ideas » Platform · Flag idea as inappropriate… · Admin →
The new Visual Studio installer for 2017 is really nice. The way it provides the idea of Products -> Workloads -> Individual Components is a good separation of granularity.
If Kentico could offer an install that allowed for a high level selection of Workloads I think that would be a great first step.
Imagine I'm going to be building Content only site with no public facing login/registration and no ecommerce. All I want is portal engine, simple webparts (no MyAccount stuff) for adding content in the portal (Repeaters, Static Text / Images / HTML, HTML Head).
If I could select that and everything else would be removed that would be awesome.
Now imagine I'm building an Ecommerce site and I don't want the Forums module but I do want all the Shopping Cart / My Account / Payment Gateway web parts. I would like to have a checkbox so I can install all features and code related to that workload.
This idea is not going to be covered in the upcoming version of Kentico. We are going to gather more information about it.
Platform Product Owner
I also agree this should be standard. The fact is, dates are horribly confusing and there is rarely consensus between development and business on how they should be handled.
The general user of a website doesn't understand dates/times/timezones let alone UTC but the nice thing it doesn't matter as long as the storage of the DateTime into the database is UTC. With that in place the application/frontend can display the date in whatever way is needed.
DateTime is considered to be a poor implementation for dates/time in the first place which is why there are libraries like NodaTime http://nodatime.org/.
At least standardizing Kentico to store in UTC would be a good start.
Please be so kind and leave me a comment.
We use SASS exclusively in our company except for sites where we have a large legacy CSS stylesheet.
I think we would use SASS support in the editor if lib-sass was integrated to do the transpilation but I also think the continuous integration functionality might be a better solution since SASS should be kept in version control and the generated CSS is what should be placed in Kentico.
This idea is not going to be covered in the next version of Kentico. We are going to gather more information about it.
Platform Product Owner
I would like to see Orders & Forms first. Pages, Custom Module UI using Portal Engine templates & extenders and Products would be next on my list.
The new documentation pages about Writing automated tests is public: https://docs.kentico.com/display/K9/Writing+automated+tests
Maybe you will find there something you didn’t know. Right now we are working on the v10 version with some of the new options and enhancements.
Any feedback will be appreciated.
Effective testability, which implies decoupling, which can be solved by interfaces, is the real issue here. So merging this with that issue is fine since 'testing' should really be the focus.
+1 for Gabor
There is some mocking that is now possible, but the way context data is accessed in Kentico the ability to write unit tests for large portions of the site's functionality is limited.
Like "Horizons" mentioned, the e-commerce code, while full of features and customization options, has so many instance dependencies and live-site context dependencies that there is no reasonable way to test a scenario like 'Adding an item to a cart that shouldn't have tax applied" and seeing the result of that test as passing because the total tax for the cart is 0.
Kentico does not rely on interfaces much and developers are required to use a lot of inheritance and accessing static global objects as an API. I understand these are legacy architectural designs but for any sort of testing to be considered a usable feature with Kentico we will need a less coupled design where DI and mock-ability of functionality are available throughout the application.