The idea is not new, like Wordpress, Oxwall : a platform created by some guru guy that allowing other dev guys to add new apps (like forum, blog, market-place, whatever) into the platform easily. By easy, we mean either just install new plugin by upload or less user friendly coding new plugin without changing the core code.
Actually, we have a working solution with angular1 but quite clumsy, that's it, multiple stand-alone ng-app within a website, like:
domain.com/forum-spa
domain.com/dating-app-spa
..etc..
Good thing about it is quite straightforward to implement, not much to worry about lazy-loading. But we are not happy with that approach for many reasons.
Angular2 is really close. We hope it can bring a better solution for building a large web platform
iframe
custom components that are added at build time that are added depending on user data like explained in Angular 2 dynamic tabs with user-click chosen components
This approach is compatible with the offline template compiler
There is also a more flexible way that supports user-provided component templates How to realize website with hundreds of pages in Angular2
This approach is not compatible with the offline template compiler and requires the Angular parser and compiler to be included in the build output.
Related
Since I basically can get the same info with both approaches, I'm wondering which is the preferred one and what are the advantages using one over the other?
$cordovaGeolocation is angular wrapper over plain javascript plugin, developed by ionic. Now question is why ngCordova was introduced,in simple words to deal it as plugin service as module and inject plugin wrapper as dependency to only particular controller or service.
On Pratical level, cordova developers were having issues with plugins on angular project. One simple issue was that $scope does not get updated sometimes in simple plugins callback.
Quoting from ionic blog post :
The services support promises to make it easier to deal with their
asynchronous nature and ensure scope data is properly updated.
So my conclusion is, you should go with $cordovaGeolocation.
As far as I remember, on Android that plugin does not do anything at all, and on iOS it prevents the OS asking for access to location over and over.
Overall the plugin totally conforms the html5 specs, so you shouldn't change anything in your calling code (in js) if you use the plugin.
And the plugin has a good documentation here: https://github.com/apache/cordova-plugin-geolocation/blob/master/doc/index.md
It is worth noting that according to the current and oficial documentation (see cordova geolocation doc), there is no need to use $cordovaGeolocation, but rather the global object navigator.geolocation.
Hopefully someone can help me, I'm new to EPiServer and have been given a data migration task. We are using the latest version 8.5. I need to migrate content from a clients home grown CMS (that luckily is in a tree like structure) to EPiServer. There doesn't seem to be a whole lot of information about this on the web - perhaps I just don't know the right thing to search for.
It looks like using the EPiServer.ServiceApi might be the route to go but again locating useful documentation is proving difficult.
I was thinking of setting up the client CMS in SQL Server and writing a simple console application to call the EPiServer.ServiceApi inserting the content. If anyone has any information on this or better still and example i would be very grateful.
Thanks,
Dan
If you are just importing content from another CMS I would write a scheduled job in EPiServer:
http://world.episerver.com/code/dannymurphy/Stoppable-Scheduled-Job-with-feedback/
That job then uses the standard IContentRepository to create content:
http://world.episerver.com/documentation/Items/Developers-Guide/EPiServer-CMS/8/Content/Persisting-IContent-instances/
That way you can run it whenever you want and have access to EPiServers complete API. Also you can see progress of the import through the job status.
In the job you can read the content as a file in any format you like or directly from the source CMS database or some xml or RSS feed perhaps.
I have moved content from PHP, Java and .NET CMS this way. In .NET you could even access the source CMS via WCF or SOAP if available.
The ServiceApi is relatively new and more focused on Commerce products and media assets rather than CMS page and block content so I wouldn't use that.
There is complete documentation below for the ServiceApi by the way, did you not find it?
http://world.episerver.com/documentation/Items/EPiServer-Service-API/
Regarding language management you can read more in the below links:
http://cjsharp.com/blog/2013/04/11/working-with-localization-and-language-branches-in-episerver-7-mvc/
http://tedgustaf.com/blog/2010/5/create-a-new-page-language-branch-programmatically-in-episerver/
Basically you have two options for multiple languages. If the content is just straight translations you should create nine different language versions (branches) of the same page. You can also have multiple sites in an EPiServer installation but that requires 9 separate licenses (and the associated costs).
I've done a lot of EpiServer content migration projects. The easiest way if it's possible is to export your current sites tree in Json and then import that into EpiServer. I've had to do it on a recent project and mixed with Json.net it's pretty easy.
If you want to go that route you can find all the code to do it here: EpiServer Content Migration With Json.Net/
As a Joomla (novice) developer, I'm concerned about why we really need modules to create our own forms. I'm definitely not an authority on the subject when it comes to Joomla but here's my issue.
I understand (through hands-on discovery) that we can create forms using two ways (without additional custom modules).
By writing the form content straight in the index.php page, then checking for submit using PHP.
By inserting the HTML content for the form as a CustomHTML article using the admin back-end. Then have a separate PHP page to do the processing and return back to a specific landing page.
First I'm not sure if the above methods are considered sane in the joomla world but I do think they're workable.
If so, why do we need to run through rough seas trying to download and install form-builder plug-ins and write code that looks pretty absurd with so many files.
The first solution you mentioned is the worst that could be done. Editing the index.php should never be done. If an update for the template is bought out and you install it, it will override your changes.
The second point you mentioned is also a bad idea. There is no point in using separate PHP pages if you're using the Joomla CMS.
Stick to Joomla standards and create a custom module (not custom HTML module) either by coding it yourself or getting started with a Module Generator.
The whole point of using a CMS is to make life easier. A Joomla site is built of of Components, Modules and Plugins.
Components are like applications such as a Forum, e-commerce system etc. Modules are like widgets such as a twitter feed, shoutbox etc.
Plugins change the behavior of something.
why do we need to run through rough seas trying to download and
install form-builder plug-in?
Trying to download and install a form builder is not difficult at all. Simple go to the Joomla Extensions Directory, go the the necessary category, click on an extension that suits your needs, download and install it and voilà.
I saw a tweet today referring to the MVCHTML5 helpers on Codeplex. I'm wondering if
Anybody has tried this out yet?
Does it add any real significant benefit over the default HTML helpers?
What are the actual HTML5 aspects of this library?
I would definitely recommend checking it (I am a little biased as I wrote it!).
But it's just a simple DLL that you include in your MVC project and it will give you all the benefits of HTML5 input types. If the browser doesn't support it - it will just fall back to a normal textbox.
To answer your questions though, it only adds a benefit if you are looking to add HTML5 functionality to your application or website. It uses the exact same syntax and the normal HTML helpers that ASP.net MVC comes with, but this just makes life easier if you are looking to add HTML5 functionality to your site.
Here is another link regarding HTML5 and the input types: http://diveintohtml5.ep.io/
I've just been trying it out, it doesn't seem to support the Required DataAnnotations for unobtrusive client side validation
I've been trying to get pretty charts to work in GWT on our internal network.
Playing around with GWT-Ext's charts is nice, but it requires flash and is really messy to control (it seems buggy, in general).
I'd like to hear about something that works with the least amount of dependencies and it also must work without a connection to the web (so, Google' charts API isn't a solution).
Edit: Indeed, I would rather a library that is all client-side.
I'm building a GWT chart library based on Flot: http://gflot.googlecode.com
I hope you find it useful. Contact me if you have any questions.
Googling for "GWT +sparklines" has gotten me to gchart, which seems like what I need.
From what I understand - it's all client side and requires nothing more than their JAR file.
Google's charts actually come in two flavours, and one of them does not require interaction with Google's servers - so should satisfy your needs.
Google Image Charts is the API you are thinking of, which is an API on Google's servers that returns images.
Google Interactive Charts is a client side javascript API that renders entirely within the browser: Google Interactive Charts
Google provides a GWT wrapper for the interactive charts: GWT Visualization API
It's not all rainbows and unicorns and you can find chart libs out there that make nicer charts, but it's pretty solid, works on all major browsers and we've been using it successfully for quite a while.
http://code.google.com/p/ext-ux-ofcgxt/ is a nice option if you're using ext-gwt
Do you want something that has a server side component or entirely client driven? The best ones I have seen are all flash, alas. I have done little tricks with JS and GWT before, but there is only sophisticated I will get before I go hunting for a library to do it for me.
There is also "sparklines" - they are available in lots of flavours (very simple charts though).
gchart looks seriously awesome. Go with it !
If you're looking for client-side check out flotr which is based on prototype javascript library or flot which is based on jQuery. Both work well, though flot seems like its got a bigger backing.
If you are willing to go with flash, XML/SWF is a wonderful tool
+1 flot, requires jQuery though, so might not play well with GWT, I haven't used that.
Another flash option, with a pre-built GWT integration - Open Flash Chart / ofcgwt.
I think that gwt-chart is a better framework for you.
well.. i've used yahoo ui chart library (which GWT-Ext uses internally). Pretty neat solution, in the beta stage though.
Let us know the conclusion you arrive at..
There is one open source api for charts in GWT hosted on http://code.google.com/p/gwt-rcharts/ . The API works on SVG/VML specification. You may find it quite easy to implement and use. You may find the demo at http://gwt-rcharts.appspot.com/