We Keep Coding

Embedding DITA Open Toolkit in a php based application

We are looking to integrate DITA in our web application, which in an E- Learning platform. The DITA Open Toolkit processes all files using java. Wee are looking for a solution that allows us to work with the DITA content on the fly from a php - based application.
Does anyone know of any php projects that are written to work with DITA maps and content?
After searching we came across XMLmind DITA Converter (DITAC) and
Designed to be easily embedded in any JavaTM, desktop or server-side,
application.
is one of its features. But in the documentation, only how to embed in java application is described.
Can anyone provide any help to sort it out. I dont have any idea about implementing it in our php based web application.

PHP as a dynamic XML rendering platform is limited by having only XSLT 1.0 as a native library for transforms within PHP as the logic layer. However, this standard LAMP/WAMP platform works fairly well for dynamic delivery of DITA content if you treat topics and maps as individually-addressable resources bypassing the usual multi-pass, map-driven processing.
I've been developing this concept into a DITA-based site-building tool that I've named expeDITA. I had put some earlier code for this project into SourceForge but I don't recommend using that code base--it was an RPC-based proof of concept whereas the latest version supports RESTful addressing with a front controller setup and vastly improved theming. The latest version is just about ready to put into a new project, and now that conference season is over for me, I can focus on prepping the docs and headers.
For the moment, you can check out this latest code running on a staging server at http://expedita.x10host.com/. But note that this free-hosted site seems to throttle access to the DTDs from time to time, hosing the class-based transforms for minutes at a time. Once I get the project into a repository, I'll set up a demo site on a less persnickety hosted account.
If you are looking for full DITA rendering, this is not the project for you. The typical use case here would be for any web presence for which DITA as source would be preferred over HTML. You might use it as a wiki for collecting SME contributions as DITA source, or to use DITA's filtering and flagging features to produce adaptive content for responsive themes, or to produce site content that can be aggregated as a single-page view or served via API as XML or JSON formats for consuming in mobile apps. I've even added slide capabilities that might fit into dynamic eLearning content delivery modes.
This blog post gives some background into the project and its goals: http://contelligencegroup.com/ditaperday/what-is-dita-for-the-web/ . I hope this is helpful information. Can you mention more about what goals you have for a hosted DITA application? Would the serve-on-demand model work okay for you, or do you require the map-driven extended features of DITA-OT/DITAC based processing?

Using Nashorn with other Web Application Framework

In JavaOne 2013 I attended a seminar on Project Nashorn. I was astonished after knowing about it. Calling Java From JavaScript and vice versa.
But one question is still unclear to me, that how can we use Nashorn in favor of Web Application Framework like JSF, ADF Faces or Wicket etc. If someone give any pointer, it would be highly appreciable.

Scripting API for Java Platform, in general, and Nashorn, in particular, open wide range of opportunities for web app development on JVM. Frameworks like node.js and vert.x solvency of JavaScript as server-side framework. Yes, we still waiting news about node.jar - mystery Oracle's project of implementing node.js API on Java platform.
In todays modern web applications we should think about server-side more as service provider (RESTful services) rather than presentation framework that generates html on the server. But even for server-generated pages you not necessarily need stick to frameworks like JSF, Wicket, ADF. With Nashorn/Rhino you can use JavaScript templates to generate html markup on the backend. LinkedIn, for instance, already described benefits of having templates written in JavaScript in both browser and on the server. In case when your browser unable to precess client-side templates you can graceful degrade and switch to server-side rendering.
If you're looking to example for to leverage JavaScript in server-side web framework you can start with Dust4j. Do not be confused by words Rhino in description. Dust4j doesn't use internal Rhino's APIs. It uses jsr223 APIs so if you run it on JDK8 or JDK7 with Nashorn backport it should work. Dust4j project shows how you can integrate scripting into you JSP/Servlet/Filter-based application.

Nashorn is a JavaScript compiler and runtime for the Java Virtual Machine. It is not a Web Application Framework in itself, but might enable one to be built on top of it.
Therefore, it isn't a replacement for JSF or ADF.

Apache Wicket provides a functionality to post javascript code against the server, now and also allow to access session / request scoped objects. It does not replace the Web Framework itself, but allows you to create a programming interface to run code on the server and modify java objects, calculate values and return the calculcation.
The documentation of Wicket's Nashorn Integration can be found here: https://github.com/wicketstuff/core/wiki/NashornIntegration
And if you fork the git repository you can run the nashorn integration examples:
https://github.com/wicketstuff/core/tree/master/nashorn-parent/nashorn-examples
One thing left to be mentioned: Because it is an arbitrary code execution this might lead to security issues, so ensure that only logged in users can access this interface.

When to use GWT and when to not

I am wondering if there are specific cases where GWT is not suitable? For example would it be approriate to re-develop Stack Overflow using GWT?
I am developing an app which has a Java Restlet API and I was planning on using GWT (previously I would just have used bog-standard HTML/CSS with back-end PHP code calling an API). I am wondering if there are reasons why I shouldnt choose to do this?

My answer is not full but I believe the following bullets may be useful.
GWT should not be used for applications that mostly present textual information and some pictures, i.e. not very interactive. For these applications GWT does not bring you a lot of benefits.
GWT should not be used by teams that have strong web skill and relatively weak java skills.
Do not use GWT if you are required to support browsers that GWT does not support officially. For example MSIE 6.

have a look at this topic GWT for big projects?
GWT is best choice to manipulate complex actions in a single page. like Google wave, Google mail ... you can easily update (ajax) any part of the page.
Because of the GWT is java-to-javascript compiler, user should wait the loading of .js files and it causes many and many problems if your web app is big. The bigger your project, the bigger javascript files, the more user should wait the loading of .js files

IMHO If you have a static looking website like a blog, news portals, etc which each page has its own identity and represents an entity and is requested separately don't use GWT alone (you can still mix it with server-side generated pages like FB).
For most of other web apps especially if users sign in to use your app or your app is interactive and there is no technical problem use GWT (like Gmail design).

I would propose to avoid GWT at any cost. I have experience developing huge project with GWT and it is nightmare, because of long development circle. If you have application in angularjs/react/jquery, you update source code, click F5 and reload it. You can quickly debug clicking F12.
If you use GWT on huge project, you have to wait ~1 min for app to compile. And then there is no good way to debug it. Google provided special browser plugins, but they worked unstable and didn't support last versions of browsers, so I had to downgrade FF. Also huge GWT app debuggin takes tons of java memory, so you have to provide more memory to tomcat. And finally in practice you can't avoid learning js, you will have to learn it if you do modern web development.
UPDATE 15.05.2017: My answer was downvoted by GWT fans, but I'd like to note, that my info is up to date: 1-page hello world app rebuild cyrcle takes about 30seconds with last IDEA and 10Gb mem SSD notebook. I also asked friends having GWT in production for serious project: they claim 2min is average redeploy time.

Can a Java portlet be embedded in an ASP.NET page?

We have some portlets created by a team working on a Java EE site.
They would like to include one of these portlets within a site I manage, which is ASP.NET.
Aside from solutions like iframes, is it possible to embed a Java portlet within an ASP.NET page?
(Note: I don't have much Java/portlet experience, so please take that into consideration in your answer)
UPDATE
Is this relevant to my question?
http://download.oracle.com/docs/cd/E13174_01/alui/devdoc/docs60/Portlets/Basics/Hello_World_Portlet_NET.htm

The short answer is yes - this is technically possible.
You could expose the Java portlet using WSRP. The Java portal server will need support being a WSRP producer. The Java portlets will need to strictly adhere to the spec to avoid things like URL rewriting issues, so your Java folks will have to test the app for conformance.
I don't know much about the ASP.NET stack, but I know Sharepoint supports WSRP. If your portlet consumer isn't a Portal server, I don't know how much work would be involved in consuming the web service directly - you'd have to study the spec.

While theoretically the answer is WSRP - cross vendor WSRP has always been challenging (though Oracle Portal uses it internally for example) - especially since WSRP 1.0 omitted Authentication and other important pieces.
In my experience your best bet is either:
Uses AJAX or similar to load a full-page version of your portlet, and rely on SSO or shared secrets to handle authentication
Write a slim webpart that talks over REST/SOAP to a backend service that's shared between a portlet and webpart (e.g. exposes servlet/Webservice endpoints in the portlet webapp)

A "Portlet-Like" java technolgy for a Web app

Do you know a technology which can provide me a portlet-like interface?
But I do not want to use JSR 168/268 portlet specifications and a portlet container.
The reason is: My web app is a product which can be installed on the client's server (it can be weblogic/websphere/tomcat).
Packing the portlets container along with my application to be installed on clients web server is just too much.
Besides, there are a lot of features this technology offers which I don't need. Actually, all I need is the porlets look and feel (dragable and customizable windows,adding and removing windows and so on).
I know there is also the possibility to do it with client technology (like jquery) and that is cool, but I would like to know if there is any kind of java technology out there which will also give me that.
So, if you know something like a struts or a spring-mvc component library which does this job or maybe a third party product, I would like to know.
If you think my whole approach is wrong I would also like to know that.

Take a look at gwtportlets. From their site;
GWT Portlets is a free open source web
framework for building GWT (Google Web
Toolkit) applications. It defines a
very simple & productive, yet powerful
programming model to build good
looking, modular GWT applications.
The programming model is somewhat
similar to writing JSR168 portlets for
a portal server (Liferay, JBoss Portal
etc.). The "portal" is your
application built using the GWT
Portlets framework as a library.
Application functionality is developed
as loosely coupled Portlets each with
an optional server side DataProvider.
Take a look at the demo here

Another suggestion would be JSF 2.0 which provide AJAX support for updating part of the HTML-page out of the box.
Have a look at this series to get an idea of the possibilities:
http://www.ibm.com/developerworks/java/library/j-jsf2fu1/index.html