I have an instance of Nuxeo 5.8 installed and running on s3 and I want to extend it so I can add customized metadata to an asset. E.g., say a normal asset has metadata like "title", "description" and "author", I want to be able to add my own fields like "brand" and "SKU" (among others).
From what I understand it's only possible to do this via the front end when you have upgraded to Studio, so what I'm looking at doing is somehow extending the API (and the related XSDs?) to allow extra metadata. Also, once I've extended the API I'm aware that I'll have to provide my own front end that interfaces with my extended API, and will have to bypass the out-of-the-box Nuxeo front end.
What exactly do I need to do to achieve this? I'm guessing I'll need to write a Java app that interfaces with the Nuxeo API somehow?
I'm struggling a bit to find documentation for 5.8 - I did come across Customizing metadata for 5.5, but I'm guessing this is out of date?
Any insight would be much appreciated.
I've also posted this question on Nuxeo's answers site here.
This was answered on the Nuxeo answers site.
Related
I am prototyping a Shopware App right now, where I want to extend the search with our search API. We already have a working plugin in the store for that.
I found those two references for hooks:
https://developer.shopware.com/docs/resources/references/app-reference/webhook-events-reference
https://developer.shopware.com/docs/resources/references/app-reference/script-reference/script-hooks-reference
Seems like there is no webhook for the search at all and just a script-hook for a finished search. In the plugin, we could just extend the ProductSearchRoute and be completely flexible.
Are search extension not planned right now?
Cheers,
Tobias
I assume you want to alter the criteria for fetching the products. As of today this is not yet possible with non-self-hosted apps. You could use the app scripts to enrich or replace the contents of an already loaded page as you already mentioned. Obviously that comes with some drawbacks regarding performance. The capabilities of apps are being enhanced continuously though so there's chance search manipulation might become possible rather soon.
I don't know when this started happening or if things have changed but the _host_Info param is not being passed by the framework to my Excel Add-In in Excel Online.
It passes an empty "et=" parameter which is OK in this case since I'm in dev mode. The Excel desktop client is still passing it.
This is required by my add-ins to switch functionality between Excel Online and Excel for Windows.
I've checked the docs and can't find that anything has changed.
To append to Sudhi's answer: with the official API coming as per the link in Sudhi's answer, we've gone ahead and also added a "shim" for the API in the OfficeJsHelpers library.
The shim still uses the workaround code that Sudhi mentions -- window.sessionStorage['hostInfoValue'] -- but it wraps it in an API very similar to what is coming in the official Office.js. Once the official API is available, we'll switch the shim code to make use of that instead. The beauty of this approach is that if you use OfficeJsHelpers via an NPM package, all you have to do is update your package dependency, and you'll suddenly go from an unofficial and potentially-fragile workaround to an API that relies on 100% officially-exposed properties -- all without changing your own code! Likewise, if at that time you decide to switch back to using the official Office.js version, the similarity of the APIs (essentially just namespace differences) should make it trivial to switch over the implementations.
The helper APIs are OfficeHelpers.Utilities.host (which will return WORD, EXCEL, etc.) and OfficeHelpers.Utilities.platform (which will return IOS, PC, OFFICE_ONLINE, or MAC). The constants are defined in OfficeHelpers.HostType and OfficeHelpers.PlatformType.
You can find the NPM package at https://www.npmjs.com/package/#microsoft/office-js-helpers, and either install it via NPM, or use a CDN like Unpkg to quickly try it out: https://unpkg.com/#microsoft/office-js-helpers#0.4.2/dist/office.helpers.min.js
console.log(OfficeHelpers.Utilities.host);
console.log(OfficeHelpers.Utilities.platform);
if (OfficeHelpers.Utilities.platform === OfficeHelpers.PlatformType.OFFICE_ONLINE) {
console.log("Yep, I'm on the web client");
}
I hope you find the above helpful as an interim measure, and we'll be sure to update this StackOverflow thread (and the OfficeJsHelpers code) once the official API is released.
Jim and others who may be affected by this change: it is unfortunate that an unrelated change meant to improve the add-in experience caused the query string parameter in online platform to be removed. Note that URL query parameters and session storage settings are used to launch and setup the add-in environment and are not meant for developer consumption. However, we understand the importance of this to the developers as described in this thread.
Hence, we are adding formal APIs to make this information available. Please see the specs that describes upcoming APIs: https://github.com/OfficeDev/office-js-docs/tree/ContextAdditions_OpenSpec
Until the APIs become available (should be very soon), you could use the following temporary workaround. The same query host_info_ parameter value is available in the following variable: window.sessionStorage.hostInfoValue. Please note that this should be considered a temporary measure and you should switch to using the formal API as soon as they are made available. I'll update the this thread when the API is released, which should be available for all supported Office versions.
If you have any comments, please leave your comments on the specs directly in Github specification branch using the links provided.
UPDATE:
Please see my answer above, instead (https://stackoverflow.com/a/40963500/678505), as the scenario is now possible.
[Old response:]
Jim, could you describe your scenario more? Why is it that you need to distinguish between Online and Desktop?
For the disappearance of host_info_: you won't find it in the docs, because host_info_ was never in the docs. Anything not documented is an internal API, which might change as needed by the internal workings of Office.js. We take back-compat very seriously, but only for actual official documented APIs.
Without an API, there's not much you can do to tell the two apart (or rather, not without relying on other bits of internal workings which might also change over time). We've discussed this internally before, but found it surprisingly difficult to point to a particular scenario where the platform information was necessary and legitimate ("legitimate" in the sense that if you're using platform information to check whether an API is available, for example, that's precisely what we don't want you to do; we want you to use Office.context.requirements.isSetSupported instead).
If you can share your scenario details, I might be able to advise an alternate way of determining whatever you need, or have a solid scenario to bring back to the team.
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.