As an opensource .Net ECMS, Sensenet seems to have a lot of features, anyway in their developer blog, it seems they are working for an SN7 version with more goodlooking UI.
Do you have any info, when it will be released?
Yes, we are working on SN7 for some time now. Part of that work is to partition this huge product into smaller components. The plan is to release the core layer, the Content Repository (without UI) on github soon. After that the rest will follow gradually, as optional packages. The main focus now is on the platform with an easy-to-use client api.
Related
We are working in an environment where the overall web application is maintained by a core team, but developers internal and external use the frameworks and tool to develop on the application.
If the frameworks used are not backward compatible, overtime it will be impossible to upgrade the systems as other developers used frameworks to develop (old versions for example).
We would like to choose a modern JS framework, thinking a bit more serious about Vue.js.
Can anyone share thoughts about Vue.js roadmap and upgradability of the framework as it goes to V3, V4, etc?
Is the core team's mission to keep it the new versions backward compatible? not to break any APIs offered in the previous versions, etc?
I and my team have been using Vue.js for quite some time for almost 2 years. Before that, we used Angular for 4 years.
I can surely say that future Vue.js will not be fully backward compatible with past Vue. This was true when v2 was released. In fact, this applies to any major JS framework out there. Most of them will not be backward compatible. Look at Angular, Hapi, Koa, Rx.js, etc.
There is a good reason for that. JS is evolving in ways you or me as a single person cannot comprehend in one go. Not all browsers support all features. Web components are coming since 2015 and still a way for them to reach a general consensus. For example, in case of Vue 3.0, the idea is to use ES proxies that will probably be backward incompatible. As web components get adopted by browsers, the idea of Vue.js component will change and it will again be backward incompatible.
Having said this, Vue.js is unlike any other framework out there. The core team is trying its best to preserve core framework compatibility. What happened with Angular 1 -> 2 or Vue 1 -> 2, there is a least likely chance of that happening
As long as you are using Vue public API, you should be good. The transition if any will definitely be smooth, less head-spinning and you will have a clear upgrade (read as - temporarily compatible) path.
Graceful evolution is one of the reasons why we are using Vue as our large-scale application framework.
Is there a tutorial somewhere that shows you how to install & build Aurelia MANUALLY in Visual Studio 2017?
Why do this?
Ideally I'd like to use bundleconfig.json for as much as I can and
use gulp for those things I can't do in bundleconfig.json.
I'll learn every aspect of the build/bundle/package process as possible instead of having a tool set that up for me. (Makes things
easier to troubleshoot if I know how it is all setup.)
I won't be dependent on CLIs and packages that are not kept up to date. (Several that I've looked at are based on VS 2017 RCs).
I've tried several CLIs and "skeleton" projects but they all have their issues. Some haven't been updated to use the latest csproj.
Aurelia CLI: Project/Folder structure doesn't mirror any standard way of building SPAs that I've seen. Also doesn't mirror what you get when using Aurelia's own "Skeleton Project."
dotnew new spa templates: Though the most promising it's typescript only and not ES6. (Maybe there is a way to switch it easily?)
Aurelia's Skeleton Projects It adds dependencies that I do not need. It also does not work out of the box.
So here is what I've determined since originally writing this question.
My original thoughts with lessons learned:
Why do this?
Ideally I'd like to use bundleconfig.json for as much as I can and
use gulp for those things I can't do in bundleconfig.json.
Answer: I was only doing this because I was trying to embed Aurelia inside of a web api project in Visual Studio. I recommend you don't do this and instead keep it as a separate project. (Separation of concerns)
I'll learn every aspect of the build/bundle/package process as possible
instead of having a tool set that up for me. (Makes things easier to
troubleshoot if I know how it is all setup.)
Answer: Though building from scratch would help me learn about this more it isn't a major roadblock. I was just inexperienced with more modern UI frameworks and their corresponding build processes. (RTFM)
I won't be dependent on CLIs and packages that are not kept up to date. (Several that I've looked at are based on VS 2017 RCs).
Answer: - That happens no matter what route you go. You can wait for a library to mature more if this is a big concern.
The bottom line is my question was based on some incorrect thinking. If you are trying to go this route you really need to ask yourself why and determine if it is worth it. To me it was not. Just go with what works, learn and move on. Oh and don't resist Typescript!
npm install aurelia-cli#0.30.1 --global
create new vs solution in 2017 (ASP.NET Core Web App)
with command prompt, cd into the solution root dir (not wwwroot)
au new --here
select RequireJS or SystemJS (my personal preference)
select option 2, asp.net core
select the remaining options.
Run f5 in VS2017.
I want to have Meteor as a server and Ionic2 as a client. I currently have a headache with authentifiacation. It seems that there are two different approaches:
First is use of Meteor server and Meteor client with ionic-angular library. This approach described here
https://angular-meteor.com/tutorials/socially/angular2/ionic2
I guess the advantage of this method is use of Meteor native architecture, on the other hand I guess we're using Ionic2 just like a subframework and maybe loosing some stuff from native Ionic2.
The second is using separate Meteor server ('client' folder deleted completely) and native Ionic2. This approach described here
https://angular-meteor.com/tutorials/whatsapp2/ionic/authentication
This option is vice versa: use of native Ionic2, but it has to use libraries like meteor-client-side, accounts-base-client-side, accounts-password-client-side etc, which I'm not sure are native for Meteor.
The first approach looks better, because there is a ready-to-use UI component for authentification. But I wonder what issues I would have, when I come to the step of completing my applications for different types of devices.
Thank you in advance for your help.
These approaches are essentially the same for the authentication itself.
What you are pointing out is more about what mobile platform to choose to develop and run mobile projects.
In the first case, you use Meteor's built-in Cordova platform to run the app and Meteor's compiler and bundler plugins (like TypeScript package or Meteor core packages for Babel and UglifyJS etc) to develop the app. In the second case, you develop and run the app solely on Ionic 2 CLI.
But from the app logic point of view these approaches are absolutely same: you import the same Ionic 2 components and use the same Meteor packages with the only difference in the second case is that these packages are now NPMs not Atmosphere ones (essentially though they contain the same scripts since these NPMs are built from Atmosphere packages).
The reason why What’sApp clone is built in that way that differs from the Socially’s one is simply described in the README of
the What’sApp repo (see https://github.com/Urigo/Ionic2CLI-Meteor-WhatsApp). If to repeat: since Ionic is a one of the best Web frameworks that specializes solely in building mobile apps, it’s reasonable to guess that it’ll be (and likely it is) much more powerful in building them than Meteor itself. From that point of view the second approach seems more future-proof, I would say. You could think even of building your project in some way that will allow you to substitute Meteor easily with some another framework if you decide to use it at some point in the future.
If you are though concerned about using those NPMs mentioned in the second case (e.g., if the process of building them doesn’t look transparent to you), you could try this project https://github.com/Urigo/meteor-client-bundler to bundle Atmosphere packages you need into separate scripts and use them after.
I have an MVC App which uses Azure AD, it works very well using the WindowsAzure.AD.Graph.2013_04_05 helper project that Microsoft made available. This project is now outdated, but looking at the new Nuget Package, the two require code changes.
I have two questions, How long can I use the old one before I find myself locked out of my own app. Second, has anyone migrated between them?
What I have is very simple, its just an Auth Filter which checks if a user is in one or more groups.
You should have at least a year from the announcement of a REST version being deprecated; a REST version is not the same as a NuGet package version, so you'll need to understand the underlying version in use.
Please refer to this Microsoft support policy on Azure-related REST APIs and libraries: http://support.microsoft.com/gp/azure-cloud-lifecycle-faq
WHere can I get a XD version of dojo source like the one hosted on google? What I want to do is to host dojo source from my local CDN, and my custom dojo module in my web application. Is this a good practice? or I might as well just include the dojo source in my web app, and run the custom build?
Thanks,
You can build an xd version of dojo from the source code
Here are instructions on how to do it:
http://dojotoolkit.org/reference-guide/1.7/quickstart/custom-builds.html
See the section on "doing xdomain builds"
In our organization (a large one), we do have a CDN version of dojo deployed on internal CDN mainly since some of our webapps are not allowed to access extranet (firewall issues).
For performance, though, a custom build gives biggest boost since it is customized to the modules you need/use - once the custom build is done, you only need to ship a single compressed js output file and a small number of supporting files
When doing your custom build, you can use the xdDojoPath and loader=xdomain if you wish to use cross domain dojo to load your optimized js - see http://osdir.com/ml/cometd-users/2011-08/msg00050.html for some notes on this
Also see related SO question: Dojo on a CDN vs own install
The good news is that with Dojo 1.7+ and the new loader, you don't have to do anything special for a cross domain build (good answer above from #Vijay Agrawal, but I think that reference guide link may need some updating for 1.7) Just write your code to the new AMD format, use asynch:true, run the build tools to create layers, and deploy them on any server. AMD makes use of callbacks and many of the tricks the old Dojo xd builder used to employ, but in a much simpler way.
To support older code, there is a legacy cross domain mode mentioned in the loader docs.