We are considering integrating Kendo-Angular-UI and using its components. How well supported is Kendo-Angular-UI?
There is a lot of functionality present in Kendo-Angular-UI-Develop, that is not present in Kendo-Angular-UI. While the road-map discusses the plan for introducing newer components, it does not mention if/when newly added functionality for existing components will be available and supported. Does anyone know where I can find this information?
For example, the "collapseChanged" event for a SplitterPane component is only shown as a part of Kendo-Angular-UI-Develop. When will this be available as a part of Kendo-Angular-UI?
I am following/using Kendo UI for Angular from the very beginning. And I use Kendo UI for several years (for jQuery before and for Angular now). There is official release page and there is development page as you already figure it out.
Everything you see in development page will sooner or later be released on release page. From my experience this means from a few days to maybe a week, 2 weeks on rare occasion. You can get version from development with -dev on npm.
Details about your specific example are here.
Road-map is just a helper for developers when we can expect first official release for components mentioned in roadmap. But pre-releases are available much sooner on developement portal.
So in short, development is pre-release, and all features in most cases are officially released in a matter of days.
Related
Yesterday a customer asked me whether there is some kind of javadoc library available for all the extlib control objects, like we have it for the standard Xpage related controls:
http://public.dhe.ibm.com/software/dw/lotus/Domino-Designer/JavaDocs/DesignerAPIs/index.html
All I could say was "have a look at XpagesExt.nsf and see how they did it...". Which is quite a lame answer, I feel. So I spent half this morning googling but couldn't find anything. Anyone having a link for me?
Thanks,
Lothar
I've added it to the OpenNTF XPages Knowledge Base, in the General space, but also cross-linked from the Extension Library space. You can find the XML definitions for components and complex types as well as the JavaDoc for Extension Library. I will endeavour to keep it up to date as releases come out (it's not onerous, so should not be an issue).
I will take forward an action for the next OpenNTF board meeting to see if we can host Javadocs for this online on the OpenNTF site somewhere (as well as other OpenNTF projects). It looks like there's not a way to host them within Confluence (the product used for the Knowledge Base), but that should not be a barrier. We may also be able to add Extension Library into the build process to automate the generation and publishing.
I am planning to upgrade my company's intranet from liferay 6.0.6CE to 6.2CE. I have done some research on it but I am still confused on API part. Will my custom portlets need only recompilation or would they need a complete rewriting. I am also concerned about my Theme and Exts. I have a lot of customization in my exts and my theme. What would be the best way to move ahead?
Also I have a NFS file server and SOLR search server configured with my current deployment. Need suggestions on that too.
I've heard recently, that the Migration Tool (6.1 to 6.2) now also supports themes. It won't be pixel perfect though. Check what it can do for you.
There have been some APIs that changed. Contrary to the comments given to your question, I'd say "It depends": I don't know how much of Liferay's API you use or if you just add functionality on top. You'll have to find out for yourself. The migration tool might help you.
The things that have changed the most are: Themes (using Bootstrap, as of 6.2) and Document Library (now including ImageGallery, which was still available in 6.0). Migration of data should be smooth if you follow the documented upgrade path. Migration of your portlets and plugins will definitely require recompile (within the new plugins sdk or updated maven dependencies) and probably adaptation to some changed API calls. I've seen instances where this was simple, but I've also seen hard cases.
As there have been no more updates for 6.0 CE for quite a while, I'm recommending to upgrade though (other than #FeinesFabi in the comment). If you want to have a long-term stable platform that you don't need to maintain for yourself, EE would be the way to go (supported for ~7 years after release)
For ext changes, you'll have to be aware that there are no guarantees: Ext allows you to change the inner implementation of Liferay, and that's what nobody strives to keep stable, even in minor updates. If you're using ext, you'll always have to be aware of incompatible changes. Ext allows you to keep your changes out of the official sourcecode - so they're well isolated. It doesn't say anything about the underlying implementation to be stable. With great power (ext) comes great responsibility. Keep your ext as small as possible - whatever you can do outside of ext should be done outside and use the public API.
The basic upgrade path (for Liferay itself, not your plugins) is quite well documented in the User's Guide.
What is your approach for creating your own set of controls aka own Extensions Library? After a few years of Xpages development we have a huge set of controls that are general purpose for building UI, some web services etc. (Probably as most other developers.) When we start a new project now we have to copy the entire stuff from one database to new one which involves controls, jars, css, images, JAVA code ... and then you completely loose control to maintain some central version of this controls & codes, everything is scattered among several projects/databases and things get messy fast.
We have thought about creating our own extension library as described here
http://www-10.lotus.com/ldd/ddwiki.nsf/dx/Master_Table_of_Contents_for_XPages_Extensibility_APIs_Developer_Guide but there is not enough documentation for this topic and the entire development process is quite complicated (at least seems to me. I tried two times based on docs above going through eclipse plugin project -> feature project -> update site and still having some bugs around)
What is your experience and approach for creating and maintaining shared Xpages controls in your Domino environment? Is there some hidden feature we miss here that can help us?
Take a look at the XSP Starter Kit on OpenNTF and the XPages SDK to setup an eclipse environment for plugin development. You'll also want Eclipse IDE for RCP and RAP Developers. Install the starter kit and SDK into eclipse and you should be all set.
The starter kit is a sample plugin with all kinds of examples of phase listeners, components, etc. Once you want to deploy your plugin, create an update site from within eclipse and use the Update Site NSF available on your server install to place your update site. Once that's done, you can replicate that NSF to any other servers that may need the plugin.
For more information about the starter kit, take a look at this slide deck. There is also a github project for the starter kit. Documentation for the XPages SDK can be found here. And a video for setting up the SDK is available on youtube. Lastly, here's the documentation for setting up the update site NSF.
While we haven't gotten to that yet in XPages, our model for regular Notes design elements is to have a central template that contains the elements that are shared, with those specific design elements marked to inherit from that template. Sometimes, a database inherits design elements from two different central templates.
That way, those centrally controlled design elements remain the same in all databases.
I would recommend looking at some example's on github for how they have library/components setup. One of the more simpler examples that has just a single component built into a Library is Steve Pridemore's App Layout Extension...https://github.com/DominoDev, Another good one is Nathan Freeman's Starterkit: https://github.com/the-ntf/xspstarterkit. Hopefully these will help you get the file structure down on which files you need and how they work.
I am having trouble finding a NoSQL databases that officially support MonoTouch via a local DB on the device. If their are, could someone provide a list of them here.
According to http://nosql-database.org/ there's siaqodb. Note that others might support MonoTouch without being mentioned in that site.
Edit: a few more clicks shows that HSS Database (from the same list) also supports MonoTouch.
You might also want to look at which ones support iOS (e.g. with Objective C) and see if bindings are available (or write your own).
Take a look on Couchbase Lite xamarin's component
RavenDB supports an embedded mode, and can run on Mono using the "Munin" storage engine option.
Although, there has been talk in the user group lately about dropping Munin, and it's not usually recommended for production, so it may not be a viable option.
I've not heard of someone using it with MonoTouch specifically, but there are some running it on Mono. If you try it, please update comments here with your findings. Thanks.
A bit late, but still relevant:
I'm the author of MarcelloDB, and I just released version 0.3.0 on nuget.
MarcelloDB is a document DB, built specifically for mobile apps (light-weight, low memory usage) and supports Xamarin Android and iOS as well as the windows platform.
I still have some features I want to add before reaching v1, but the file format and existing api are allready quite stable.
I am currently developing an internal application for our company with the following requirements.
Rich GUI but only basic HTML like components will be used. So component list is not a deciding factor.
Fuzzy requirements which might change frequently during the implementation stage, and tight turn around times are the norm. Thus am looking for a Drag-&-Drop design
The application will rarely be used (max once in a month) and the user base will not exceed 20.
Time is a critical factor and thus I do not want to spend time on configuring and troubleshooting the framework. I will go for a easy to integrate solution.
I did a brief research and decided on JSF with IceFaces. But am now confused about the version. If I go with 1.8, I get Drag-&-Drop designing (Netbeans 6.5) but I will be stuck with JSF 1.2
If I choose ICEFaces 2.0 I will have to manually design the UI which might take more time.
Any suggestions on which version to choose?
If you can, go with the newest stable version. There are a lot of reason to use JSF2.
You can have drag&drop with ICEfaces2 too, at least in Eclipse (see the wiki). IDE integration is available for NetBeans, the release note mentions a palette (I'm not familiar with NetBeans, but it may be what you're looking for).