I am getting started researching / creating a groovy portlet that will connect to a REST based ESB service that returns JSON; I will also need to pass the username in the headers. I was wondering if there are any examples out there on how to create the portlet and set the headers? I am new to groovy and from what I understand this can be accomplished rather easily. Essentially I want a portlet that will allow a user to search for a widget via a search box and return a list of matches. Not sure that it matters but the portlet will be deployed to the Vignette Portal. Any info would be much appreciated!
Thanks in Advance!
Doing a portlet with Java/Groovy is very doable with Spring Portlet MVC. I used some sample code from various sources a year ago but googling on it will give you more modern examples and let you pick something more applicable to your app. The real issue comes up with how you plan on building your app. Gradle is the best option for writing a Groovy web app.
However if you are talking about using Grails, then it becomes much more difficult and I would not advise learning Grails as you are trying to get it jammed into a 'portal' implementation. There are plugins for Liferay and 'portlets' in Grails but when I last looked at them earlier this year, they did not seem fully baked.
Calling REST based services with JSON or whatever from your server code doesn't have to care that you are in a 'portal'. The big issues comes up when you are trying to create the UI with your portal provider specific APIs. Don't be fooled into thinking you won't be using portal specific stuff. We used Liferay a bit and from my perspective the Portlet spec was very slim so to do much of anything interesting in a portal, you have to use some portal specific stuff, at least for UI and authentication services.
So my suggestion is build a Gradle Groovy Web project and use the Spring Portlet MVC Java examples to get something going and then you can simplify with Groovy as it makes sense. Initially you might want to simply start with Java if that is your comfort zone because integrating with your portal might be daunting enough without trying to learn a new language to boot.
Related
this seems pretty basic, but I am rather new to web development so I am a bit stuck here. I have MongoDB running on the backend, which contains geo-spatial objects that in the front end should be displayed on a map. The communication between backend and web frontend is where I have knowledge gaps.
The user should be able to zoom to an area on a map that he is interested in, then press "Search". The backend would then find every entry in the database that has coordinates that are on the users current screen. It would transmit these to the frontend, ideally as a list of JSON objects. The frontend displays these on a map.
I have a front end mock up, code that puts data into MongoDB and code that queries MongoDB. I know that I am missing a server that can be queried from the frontend. I thought I use Jetty. But what do I need to do then? I guess I need Jetty to provide a JSON API that I can query from JavaScript. Could someone point me to the Jetty class or interface that I need to implement and maybe give a few lines of code on how to query this from JavaScript?
You have a very open question here.
To start with, Jetty is merely a Java Web Container (following a subset of the Java EE Web Profile), while it does have some AJAX/JSON capabilities, it is extremely fundamental and not hooked up into any sort of query API.
You would do better do use Jetty along with a proper REST/JSON API library for your project.
Some examples (these are not the only choices available):
jersey - Jersey - an Open Source JAX-RS (JSR 311) implementation for RESTful web services, with JSON Support - Here's Lars Vogel's Tutorial on JAX-RS using Jersey.
restlet - Restlet - another RESTful web API, with a JSON extension
resteasy - RESTEasy - another JAX-RS implementation for RESTful web services, with JSON marshalling.
Also note that there are many flavors of Java based JSON APIs and Libraries, you should probably be aware of them as you will encounter them in your journey to success.
In the end I found the Dropwizard framework (there might be others), which does a lot of the work that is necessary to get a simple JSON API up out of the box:
http://dropwizard.io/
I've been looking at asp.net Web Api, and I like the simplicity of implementing a practical web service.
However, how can I document/specify the interface of a service implemented like that? For example, is there any spec I can pass on or generate to a Java guy with no .NET background that will let him easily call and consume the service? What can I give to the javascript guy?
Ideally, I'd like the benefits of SOAP/XSD or something like it (easy to deserialize with nicely typed objects) for the java guy, while retaining a service that's callable from a web browser too (i.e. supports non-crufy JSON).
Update
It's worth noting that since I originally posted this question, I discovered ServiceStack which deals with this more naturally; supporting JSON, SOAP, and WSDL out of the box for the same service, as the client chooses. If you really want SOAP+JSON, it may be a better framework than ASP.NET Web Api.
Update March 2016
It has been a while since this was answered and the tooling for documenting any Rest API has come along a lot. We are currently evaluating Swagger 2.0 now spawning out to the the Open Api Initiative, RAML and API Blueprint.
For WebAPI projects there is a tool Swashbuckle that auto creates Swagger (Open API) format documentation.
Format for documenting a REST service:
There are some attempts at structuring and standardising the description of REST services:
Web Application Desciption Language (WADL)
Web Service Description Language 2.0 (WSDL 2.0)
I think it is fair to say neither of the two approaches above have very wide adoption, but WADL does look like a nice concise format - a quick XSLT over the top and it could be a nice human readable format. There lots of examples of WADL for some famous API's at the apigee github site here.
When trying to find a documentation format that is appropriate I tend to look for "inspiration" from others.... Apigee do a lot of research in this area and have this as documentation for one of their API's here or take a look at Facebook's social graph api here.
The examples are largely in line with the advise here
How to auto document:
Using .NET: There is a good example of auto generating a WebApi "help" page here. A logical extension of this example may be to get it outing a WADL formated version as well...
Using Java: Jersey is a tool used in the Java community to generate WADL automatically.
What to share with the other developers:
Your Javascript guy will most likely want a manual like the Facebook and apigee one; giving the dev examples of the resources, urls, response codes etc. The most important thing here will be supporting JSON as the primary content type this will be the easiest for him/her to consume and work with by far.
Your Java guy would also want the manual, but also in theory they could be given example XSD for any XML representations of the resources you send/consume (assuming they make the request as "Content-Type: appplication/xml"). This may help them build proxy classes etc. JSON to Java and .NET converters are available online and given the example resources in your manual they should simply be able to use one of these types of services to quickly create proxies. Generate Java class from JSON?.
If you absolutely must have auto discovery, auto proxy generation etc then you may need to offer a choice of both REST and SOAP (with WSDL) endpoints - relevant question here: ReST Proxy Object Generator.
You can use IApiExplorer interface and ApiExplorer class in order to create a help page for your Web Api service. This help page will describe the REST methods exposed by your service so any developer who understands how REST works will be able to use it (regardless the language). Please read below links for details and samples:
ASP.NET Web API: Introducing IApiExplorer/ApiExplorer
ASP.NET Web API: Generating a Web API help page using ApiExplorer
Documenting your ASP.Net Web API’s
In one of my projects, I have a very active classic ASP site with a requirement to integrate live event-based feeds as part of the existing UI. There is a plan to upgrade the site architecture to either MVC or MVP in the future, but this new feature must be implemented in the meanwhile.
I have decided to go with a WebSocket approach for this, as this is ultimately what we will want to use in the future, and rebuilding this doesn't make sense. The question is, how to integrate this with the classic ASP "architecture"?
The site already implements the jQuery library, and was hoping to leverage jQuery's capabilities to create those streamed sections on a given page.
The current req's ask for this news feed to exist on every page. Thus, loading a new page will re-render the news feed, and should kick of from where it left on the last page. For this, I'm guessing a position indicator will need to be read (session variable I'm guessing).
Anyhow, those are the requirements. I was thinking of wrapping the the entire existing classic ASP site inside a MVC or MVP (C#/.Net) project to allow us to begin swapping out legacy features as they are developed, such as this one.
I would like to get some advice on some recommended approaches for this scenario.
Thanks.
I would do a SignalR app and integrate it in you old app.
It's easy to integrate ASP classic with ASP.net MVC. Just mix the projects and exclude *.asp from the routes
routes.IgnoreRoute("{resource}.asp/{*pathInfo}");
You will have some trouble in the root (/), but you can sort it with a redirect.
For a mixed authentication (if you need it) you will need to write your own authentication in MVC to use the same auth cookie that you use in Classic ASP. I've done this in the past with success.
I have a legacy web application that I want to enhance by adding a message board. Is it possible to add the message board portlet of liferay into this external application.
I am a newbie so pardon my naivity if I've overlooked something obvious.
Many Thanks
No this is not possible. Liferay is a portlet container that implements JSR 268 portlet specification. All portlets that can be installed in Liferay conform to this specification.
So, if you have a legacy application, which obviously isn't a portlet container, you can't install portlets into it.
Embedding a portlet container in your webapp, just for being able to use Liferay's Message Boards (which isn't THAT good anyway), seems like a huge overkill...
In which language is your application written and which framework(s) do you use? Do a Google to see if there are any projects that you can start from or integrate in your app.
Both the answers in my view are correct limburgie and kgiannakakis, still I would like to add something which may be a little useful.
There is an interesting feature of "Sharing" in liferay with which you can embed portlets as widgets into any application.
But the only catch is that Liferay Server should also be running while your Application is also running on the same or another server.
For more information on sharing you can visit this link.
I am looking at JavaFX to create RIA. and technology behind partial refresh and news feed, anything that can update and display new information real time. anyone knows anything behind the technology of soccernet gamecast?
Ewww...java.....
From what I understand, GameCast is built using plain old HTML/Javascript. The back end is written in ASP.Net (likely C#). Here are some resources to brush up on to get started with realtime applications:
Ajax Beginners Tutorial
An ASP.Net AJAX example
Using Tomcat to run an AJAX-enabled application