This is not rocket science, but if you want to do a UI-only plugin for elastic search, it is not readily revealed by the top Google (or StackOverflow) search hits, so I thought I'd ask-and-answer here:
How do you develop a "head-only" (i.e. lacking any server-side Java code) HTML-frontend for ElasticSearch? The documentation and guides concentrate on Maven and jar files, but all I want is to create a simple query UI and have that UI be hosted by elasticsearch itself.
Elasticsearch's plugin folder structure looks like this:
/[es-home]/plugins/my-plugin/_site
Elasticsearch's HTTP server will happily serve static content from within the _site path. Furthermore, it will serve index.html as the default document for the main plugin url (e.g. http://my-es-server:9200/_plugin/my-plugin). Given this, it's simple to create a static HTML/CSS/JS site that uses relative urls to query the elasticsearch instance and display the results in a browser. elasticsearch-head is an example of this kind of plugin.
Related
I have a project hosted on GitHub. To document the API I am using the OpenAPI spec. Now I want to add a link on readme.md (on GitHub) that refers my visitors to the OpenAPI document for good user experience.
Far as I see I have two solutions:
http://editor.swagger.io/?raw=https://raw.githubusercontent.com/path/to/file.yaml
https://app.swaggerhub.com/apis/(username)/(api-name)/(api-version)
Both approaches are working, but they both open with an editor on left side that shows the content of YAML file and is, IMHO, wasting a significant screen space. Not really what I want. Is there an option to display the OpenAPI document without editor opened? Just similiar what is done for https://petstore.swagger.io/ which comes without editor opened.
Or ... is there maybe an option available to display the OpenAPI document on GitHub directly?
Thanks, Christoph
If you use SwaggerHub, replace /apis/ with /apis-docs/ in the URL to view just the API docs without the editor part. For example:
https://app.swaggerhub.com/apis-docs/swagger-hub/registry-api/1.0.47
Or if your OpenAPI definition is hosted elsewhere (e.g. on GitHub), you can use
https://petstore.swagger.io/?url=https://path/to/file.yaml
to load it into the public Swagger UI demo. Swagger UI renders API docs without the editor part.
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/
I would like to use DocPad together with its built-in server.
For a website with a single landing page I have set up the structure as recommended on DocPad website: all page sources go into the src/documents, static files into src/files and layouts for the page sources into src/layouts. Then docpad run will generate the resulting site in the out directory and launch a web server using which I can inspect the current state in my browser.
Now, I would like to do the same with multiple landing pages. That means, I plan to deploy files to one site, http://site-one.org and other files to another site http://site-two.org. I am doing this by deploying web pages to two distinct directories /public/site-one/ and /public/site-two/ at my web hoster.
What is the most practical way to accomplish this with DocPad?
These are the things I have tried so far -- they both work (sort of), but neither is very elegant:
Let page sources go into src/documents/site-one and src/documents/site-two and static files into src/files/site-one and src/files/site-two. This renders the entire site properly and it can be uploaded easily. However, the entire DocPad infrastructure with live-reload and the built-in server no longer works (since the built-in server root directory points to out/ instead of out/site-[one|two]/ as it should).
Have two separate DocPad-installations with duplicate docpad.coffee files, duplicate plugins and partially duplicate src/* trees and then upload the resulting out tree to the corresponding sub-directory on the server.
Update: When using option 1, instead of using DocPad built-in live-reload feature it's possible to use one's own web server, point it to out/site-one on one port and out/site-two on another port and then use the grunt live-reload feature which is part of grunt-contrib-watch, where grunt is available as a plugin here. It requires adding a single line of code to the template file, see this link, and to configure the plugin, see this link.
Update 2: A possible solution would involve the ability to set a custom directory for the server. By default it is set to the out directory. While that can be changed, it is not possible to specify separate directories for the generate action and the watch action. However, I have not found such an option in the configuration files.
Turns out that this is much easier than I thought. DocPad has a scarcely documented feature called "environments". This allows to customize several of the regular configuration variables, making it easy to pick the desired landing page on the command line.
This blog post on multiple languages demonstrates exactly how to customize both the document and the output paths in different environments. Applied to my original problem it becomes:
docpadConfig = {
...
environments:
site-one:
documentsPaths: ['documents_site-one']
outPath: 'out_site-one'
site-two:
documentsPaths: ['documents_site-two']
outPath: 'out_site-two'
...
}
Then it is as simple as
docpad [generate|run|...] --env [site-one|site-two|...]
to run regular commands like generate etc. for one of the landing pages by picking the proper custom environment.
I have a Grails plugin which I’m using as basically a container for some shared static resources that will be used by various other Grails projects in-house (CSS, JS files, etc). The idea of using a plugin was just to share these things — the plugin doesn’t really do anything else very interesting. What is the best way to directly reference resources inside the plugin? I’d rather not create custom taglibs, since I’m not really adding any functionality here; I just want access to the resources inside the plugin — something like this, e.g., to reference a CSS file from a GSP:
<g:link rel="stylesheet" url="${resource(dir:'css', file:'mycss.css',
plugin:'myplugin')}"/>
Does this idea violate the concept of plugins, where only certain aspects of it should be exposed, and the rest is a black box? Alternative approaches to sharing static resources among related Grails projects are also welcome, in case I’m headed down an insane, wrong-headed path by even trying this. :)
First, in Grails, a plugin is not considered a black box. To the contrary, all the code is exposed; if you really want to make it a black box, then you should use another plugin, Binary Artifacts.
Secondly, your approach is very sensible. To access plugin resources, I would have created a taglib like:
def res = { attrs ->
attrs.dir=pluginContextPath
//Do whatever you want here
out << g.resource(attrs)
}
and call it the same way as <g:resource>. That way, you don’t even have to expose your plugin’s resources path. The Nimble plugin is using this approach.
Also you might have a look at the Grails Resources plugin, which is trying to handle the nightmare of static resource dependencies among Grails plugins and projects. I have never used it, but for sure in my next Grails project, I will integrate it (BTW, it will be included into Grails 1.4).
I want to design a website using GWT. This is my understanding of how GWT pages will be delivered to the client browser - When the user puts in the URL into her browser she receives all the static HTML + GWT javascript, and then the javascript queries the server for the dynamic page content and adds it to the DOM. eg - For a blog page the content of the blog is queried by the javascript. is my understanding correct?
If I know that the content will surely be a part of the page(add does not depend on user clicking an expand button etc.), Will it be more efficient if the blog content was a part of the HTML initially served? Something that could be done by using a templating engine like django.
Is there a way to make a templating mechanism in GWT?
Yes, putting your content into the HTML will reduce the number of round trips the client makes to your server. It also means that the blog content won't have to wait for your GWT javascript to load before it can be displayed.
GWT itself isn't useful for a template system, but most servers that run GWT servlets will also support JSP pages. GWT works fine with these pages, you just need to put the GWT script tag in as usual. You will no doubt be able to find a ready-made templating solution but rolling your own is not too hard.