Want to use the OpenNTF Domino API for a XPages web application, but where I work I'm not allowed to have anything installed on the Domino servers.
Is it possible to use the OpenNTF Domino API for a browser xpages application without the server side install? Can it be loaded in the WEB-INF folder?
Check out the update site way to deploy extensions. You put the update site database on your server, add a notes.ini variable and then add the projects (Ext Lib, OpenNTF API, etc) to the update site. They get deployed to the server with no need to copy files. Many customers allow this but don't allow copying files to the server.
Related
We have a solution with an app extender (mega menu and some look n feel jquery teicks) and a web part.
We are trying to deploy it. It's pretty easy getting the dev version in the App Catalog and running it with local scripts. The extender doesn't seem to show up l, however the web part is working.
We want to know if we can deploy a shipping or production version without deploying Scripts to an o365 CDN. This part is not clear since we thought we could just package all and throw it into the App Catalog...
Any guidelines if we don't want to use the CDN?
If you don't want to use CDN, as a workaround, we can create SharePoint Library as CDN.
1.Create a document library(named "SPFxDeploy") in your SharePoint Site, and give read permission to all users.
2.Configure SPFx Solution for SharePoint Library, open package-solution.json file from config folder and set includeClientSideAssets value as false.
3.Update CDN Path, open write-manifests.json file from config folder and update CDN base path as SharePoint library URL.
4.Prepare the package using "gulp bundle --ship", then upload the files from "temp\deploy" folder to SharePoint library.
5.Upload package to the app catalog.
Reference: SharePoint Framework - Deploy SPFx WebParts to SharePoint Library
I have a XPages app that contains some notes:// links to documents. The app is used in Internet Explorer which have IBM Notes Browser Plugin installed and we are not allowed to uninstall it.
Is there any option to prepare the notes:// url to enforce opening a target document in a standalone IBM Notes client instead of the plugin?
Do you want to change it for yourself? Or for all users of the app. For just your notes:// links, or for all?
It's controlled by a registry setting: HKEY_CLASSES_ROOT\Notes\shell\open\command. If you have the rights, changing that setting will change it for all Notes links. The normal binding (without the plugin) would look something like this: C:\Program Files (x86)\IBM\Notes\notes.exe" -defini "%1".
If you want to change the behavior for all users, but for just your app's links, I think you're going to have to use a different prefix instead of notes:// and create a script to install the appropriate registry entries for that prefix on your users' machines. See here for more info,
We're in the process of converting a legacy desktop application into a web enabled equivalent.
However one feature is causing difficulty, editing MS Word documents.
Current proposed solution is publishing the DOC and DOCX files via WebDAV and using a custom ActiveX component to launch WinWord and pointing it at a file via a URL.
This works but it's limited in scope and the worlds moved on since it was conceived.
Is is possible to use the new Office Web Apps to do this completely in-browser?
So, still publish DOC files via WebDAV, but only to a web server hosting the Office Web Apps and redirecting the user to a URL rather than launching a local windows exe via activex.
Can you do this with the new Office Web Apps?
Where is the documentation on how to achieve this?
Yes, you can launch editing of MS Office documents from a web browser, using the sharepoint dll available in IE:
Eg
Set EditDocumentButton = CreateObject("SharePoint.OpenDocuments.3")
strDocument = 'http://localhost:8080' + strDocument;
EditDocumentButton.EditDocument(strDocument)
If your server is running java you can use Milton (http://milton.io) to integrate directly into your business app and edit the document in place.
Is it possible to convert a .nsf Domino Web Application to HTML? I need the application making available offline without the use of a Domino server. To elaborate on this, we have an external company that host a domino application for us, a document management system. They are soon going to pull the plug on the server and have sent us a .nsf file. If we had a domino server it would be great, we could just place the file on the server. But the problem is that we don't. That is why I was hoping if there was a way to extract all the content so that it could run without a domino server, just as a bunch of HTML files, we don't need the functionality of the DMS, we just need to be able to view the content.
Thanks
If it is an application with logic and actions built on Domino's programming framework, and not just a set of static pages, then the answer is no. First of all, because HTML is just a markup language, not a programming language or framework. And secondly, because the various attempts that have been made to build tools to migrate Domino applications to other frameworks have generally not been very successful. GBS has tools to migrate traditional Domino applications to XPages, but that's probably not what you want.
If the site is static you could copy it using a web site copy tool like HTTrack: http://www.httrack.com/
The tool crawls the entire site and generates HTML pages.
Using the Notes client, create a local replica of the database. With that database open in Notes, click on Actions in the top-line menu, then Preview in Web Browser, and choose Internet Explorer. You may need to change the ACL to allow Anonymous to have Reader access. If the data needs to be secure, create a local copy instead so that you can modify the ACL without putting the production copy at risk.
You can download the Notes designer client from IBM with no restrictions as well as the Notes and administrator clients with a 90-day evaluation period.
I am using WSS 3.0 in a hosted/shared (read: can make no server-side changes) environment. Unfortunately, between SP and IIS, almost nothing is getting cached, so page loads can be terribly slow.
We have a bunch of custom image, JS, CSS, etc files that are currently just in a /img, /js, and /css directories, all of which are grabbed each and every time the page loads (server is returning "Cache-Control private,max-age=0").
Since I can't do anything with IIS, and can't enable any caching server-side on SP, do I have any other options? I've read in a few places that if your files are located in the layouts directory that they will be cached, but using SP Designer I don't seem to have access to the /___layouts directory, unless I'm missing something....
Thoughts?? Thank you!
Since you are running in a hosted/shared environment I would work directly with the ISP on this one. There are many ways to cache things and the ISP could very well prevent you from doing most of them.
Ask them the following questions...
Have you set output caching on the Page Layouts directory for anon and or authenticated profiles, or at the Site level or at the Site Collection level (overview on how to here)? If not, can you?
Do you have IIS set to compress static files (its not caching, but, will help)?
How much RAM is available to me in this shared environment?
If you have enough RAM, look into caching your custom web parts.
You could also host your custom images, css, javascript etc on a 3rd party CDN (Akami, Amazon Web Services), that doesn't help with your theme and core js/css files.
_layouts is the "repository" for application pages, i.e. pages deployed by sharepoint for performing maintenance etc. through the web UI. It is very well possilbe you don't have access to that folder, it will also not show up in SharePoint designer. You have a couple of options:
If you have a Publishing site, you can enable caching through the site settings.
What you could also do is add the #OutputCache directive to a page you create through SharePoint Designer (Outputcache on MSDN
deploy your site through a solution, which does allow deploying in the _layouts folder