I'm creating and app which adds text field with custom JSLink.
Everything works fine when I store js files in sharepoint library, but when I reference files which are store in the "app web" (site where the app has it services and sites), this .js files are not loaded. No error, just nothing happens.
How can I reference JSLink file which is out side of sharepoint library?
You can not to do it. Because SharePoint App has isolated architecture. Same situation with host web. You cannot set JSLink property on host web to link of JS file from App web.
Related
I've built a gridsome website, but when I try to use it offline (by directly loading index.html into my browser), it fails to load the files in the assets folder, and links to other pages fails
running in windows:
after installing gridsome, I did the following:
gridsome create sample
cd sample
gridsome build
then I went to file explorer and opened the sample/dist directory and double clicked on index.html (Chrome is my default browser, but IE behaves the same)
the result is a half-loaded webpage that is missing the style sheets, javascript, images, and links are broken.
For instance, the "about" link on the first page points to "D:/about" vs. ".\about.html".
Is there anyway to make gridsome work to create a truly off-line website?
A website needs a webserver. When you are running in dev mode Gridsome provides that for you, when you build out the site you need something to serve it to your browser.
I used the CN1 Webservice Wizard to add a the webservice proxy to my mobile app and to generate all the server side code. I have a local XAMPP installation with a tomcat linked within my Eclipse IDE. Also, I imported the server generated code as a new Java Project and added the "Dynamic Web Module" project facet to it so that I could launch it not as a local Java application but rather on the Tomcat server.
When starting my client, I noted that I get HTTP 404, resource not found errors. I traced the error back to the URL, where the server is hosted to.
I know I have to adapt the urlPatterns parameter in the generated class CN1WebServiceServlet, which I did. Also, I checked the context of my app in the Web project settings and defined the value for context root. So, in my client app, the URL to call the service should be
http://localhost:8080/< context root>/< urlPattern>
However, even when calling that in the browser, I should get the result of the doGet method of the server generated code, showing the message "Webservice access only". Instead, I get 404 errors all the time.
Is there some problem to importing the server generated code as a plain Java project and adding the web parts to it afterwards? How would that be done in the ideal case?
And what other problems might be hindering the URL from properly being published on the server side?
Thanks and best regards
EDIT
I stripped everything from the project to limit the options and I found the cause: when using the web service wizard to dump the source files into a new directory, adding that with the Eclipse import wizard, it will be looked at as a plain java project without any web components. Using the project settings to add the dynamic web piece to it (Eclipse calls those project facets), the CN1 webservice will NOT work.
If instead you create a "Dynamic Web Project" first and then use the CN1 Webservice Wizard to dump the server source files into the "src" folder of that project, it works without any issues.
We have an on-premise SharePoint 2013 farm, and we have a few .mpp files stored in a library.
.xls and .doc files in the library were opening in the respective Web Apps, but the .mpp files were not.
I was getting an alert asking if I wanted to allow the website to open an app on the computer.
On selecting Allow, it was showing a prompt for getting an app for ms-project from the Store.
I changed the library to open all files in client applications, but the behavior for .mpp files persist.
Curious case is that if I open 'View properties' and click on the link, it opens in the client application.
How can I force the .mpp files to always open in the client?
We fixed this with a very simple change in the view.
We unchecked the default Name (linked to document with edit menu) column and replaced it with Name (linked to document).
Now we are able to open the .mpp file in the client application.
I was just wondering if it's at all possible to create a SharePoint-Hosted App and call code in a class library?
The idea is the class library will do all the leg work and the .aspx pages in the app will simply call the functions and pass in parameters and ultimately retrieve a string return value for me to display.
Edit -
The app will be written in Visual Studio 2013 and the idea was I could add a class library to the solution and (within the aspx pages in the app) call the class library I have in the solution. The class library will be written in C#.
You cannot deploy or call any back end code from SharePoint hosted app. You have access only to client side code - javascript, html, css. Check this link.
Sharepoint 2013 has three types of apps.
1 Provided - Hosted App
2 Auto - hosted APP
This two kinda are cloud based apps
It is prefereed hosting model for almost all types of apps
Sharepoint - Hosted app
It is good only for smaller apps & resource app.
It is sharepoint based, no server side code
Automatically hosted in sharepoint
I'm searching a SharePoint server through web services. When the web services return Word/Excel/PowerPoint documents, they contain links to the actual files, e.g. http://server/site/mydoc.doc. When the web services return PDF documents, they contain links to pages that link to the PDF document, e.g. http://server/site/DispForm.aspx?ID=1 which would contain a link to http://server/site/mydoc.pdf. I've tried _vti_bin/search.asmx with actions Query and QueryEx with no luck. What is the best way to get a link to the actual document so my app can download it?
Unfortunately, I'm using a large, shared SharePoint installation, and it's very unlikely that the server configuration can be changed.
You need the PDF IFilter installed on the server in order for the crawl to recognize PDF files and index them correctly. Here are some instructions from Adobe (PDF warning!) as well.