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?
Related
I have just read this article: http://docs.oracle.com/javafx/2/webview/jfxpub-webview.htm It shows how to build a java app using the javafx library and also how to use some classes such as WebEngine and WebView to display a web page in the app, basically turning it into a browser.
Here is some relevant info from the article:
The embedded browser component is based on WebKit, an open source web
browser engine. It supports Cascading Style Sheets (CSS), JavaScript,
Document Object Model (DOM), and HTML5.
The embedded browser enables you to perform the following tasks in
your JavaFX applications:
Render HTML content from local and remote URLs
Obtain Web history
Execute JavaScript commands
Perform upcalls from JavaScript to JavaFX
Manage web pop-up windows
Apply effects to the embedded browser
I would basically like to entirely dispense with Java or JavaFX GUI tools, except for those required to display HTML and CSS, as described in the article, and build the entire user interface for my app in HTML and CSS. I would like various HTML buttons to cause events to transpire in my java code.
Does this seem like a good idea? And since it does seem like a good idea to me, I'm also wondering why would anyone ever use any other method to build a GUI in java.
I'm creating an entire desktop application with a single WebView, it is available at github. Basically it's UI is a single HTML file which links a dozen of JS files. To call Java from JS I wrap my requests into json and call a Java facade bean. It is also possible to call JS from Java in same fashion. Though it is possible to call Java directly by invoking a method on a Java bean with parameters of any type, I did have a few application crashes after which I decided to make it completely safe and stay with json. This app uses AngularJS and Twitter Bootstrap to render pages.
I had created a ticket in Oracle's JIRA for better Java integration (JSR-223) inside a WebView and their answer was it could be scheduled for Java 9.
The development is pretty fast, when the process is set up - it's hard to debug the app in the beginning because there is no debugger. Some top-level JS exceptions are not being caught as well. At the moment I'm having no issues with WebView in JavaFX 8. JavaFX 7 is unusable for me because of the problem with fonts.
Answering your last question - I have no idea, but the situation is completely the opposite. For some reason Oracle puts resources for JavaFX native components development, but not for better WebView integration.
You can use a MVC framework such as Struts2 or Spring MVC together with AJAX and build a user interface (the view component) completely with HTML/CSS. Sometimes, using a template engine such as FreeMarker3 also helps replacing default java rendering with pure HTML/CSS solutions.
Vaadin
Vaadin is a sophisticated servlet-based framework that creates server-side based apps that run your pure Java code while automatically rendering the user interface on the client side in HTML, CSS, and JavaScript.
You don't need to know about or do in programming in those web client technologies, Vaadin does all the web-related work for you. No web templates, no pages, none of that. Your Java code simply creates label, field, buttons, and layouts. Vaadin transforms those on-the-fly to be rendered in the browser. Pure Java on the server, no Java at all on the client/browser side.
Xojo
Vaadin is not "yet another web app framework". It really has no direct competitors in terms of architecture except the non-Java Xojo Web Edition which uses its own proprietary OOP language.
It looks a very good idea.
An alternative can be to use Jetty or a similar open source server but you have much more work to do for adapt it to your application.
An other alternative is to build a Java EE application but it is not so much agile for a simple web view of your app, Java EE gives you the possibility to build dynamic web pages using the Java Server Pages and manage the user requests using the Servlets but you have to submit to his structure and this is not useful for your easy application.
I would like to replace Java Applet which currently needs to use client's resources, i.e. external readers, and to communicate with a server via socket.
Reason:
1. I have thousands of client machines using this Java Applet program, and most of them are running out-dated JRE. When the Java Applet program is updated / added new features, all client machines will need updating the latest JRE.
Expected Solution:
The Java Applet program would be expected to be replaced by a web-based application, which allows to compile and run source code at client's side such that the new web-based application could still use client's resources and communicate with server via socket.
Can I use JavaScript to achieve it?
I would very appreciate your help/suggestion for this problem. Thank you!
JavaScript is a scripting language that gets evaluated in the browser.
I would not describe it as compiling and running but yes, it does mean you can run code in the client and is commonly used to create applications that run in the browser.
There's a staggering amount of frameworks that you can use to write your application. Take a look at the TodoMVC site to see the same TODO app created using several different frameworks.
If you come from Java applets, GWT may be interesting to look at.
If you wish to let the JavaScript client listen for messages from the server, take a look at websockets.
The smart card reader is going to be a problem, though!
See Architectures to access Smart Card from a generic browser? Or: How to bridge the gap from browser to PC/SC stack?
By the way:
The real issue with outdated JREs is not that your code will not run on old JREs, you can create perfectly fine applets using java 1.4 or java 5. Any libraries you may need you can deploy alongside your applet. The pain is a security problem. Anything but the latest version Java plugin is getting actively exploited and puts the user at risk. Occasionally, even the latest version is not safe.
try socket.io
I think this is the latest technology you can use to communicate with client browsers. it support the latest browsers and mobile browsers too.
hope this will help you.
Javascript has become very powerful with HTML 5.0. Here is a list of new elements that you can use to access all kinds of resources, including local files, audio, video, GPU rendering (canvas + WebGL) and GPU compute (WebCL). Here are even more things you can do, including database connections and networking. You can even create offline Javascript applications.
jQuery and jQuery layout make robust GUI development a lot easier. Rich tool suites, such as Google Closure offer optimization and a compiler for improving performance and detecting obvious mistakes early in the development process.
W3 offers useful stats for making an informed decision on how many users on average have access to which features. Note that the most annoying guy in that list arguably is IE8 due to it's lack of proper HTML 5.0 support.
In case you want to stick with Java, then one alternative would be to use my http://bck2brwsr.apidesign.org project. It's goal is to create small Java that can run in 100% of modern browsers without any plugin installed.
There are Java bindings to HTML (via knockout - one of the four most popular frameworks for HTML5) and that is why one can code whole business logic in Java and just render it via HTML. Should be enough to replace most of the applet UI.
In addition to that there is an experimental API to render on HTML canvas. People use it to write Java games that run in a pure browser.
There is a simple way to communicate with server via JSON REST API or via WebSockets. A live example is here.
I'm working on a client-side Java application for which I want to create a web-based user interface (which will be served up to a browser from the local app). At the risk of oversimplifying, its a microblogging tool that will support functionality similar to Twitter and Facebook. Its open source, and you can read more on our wiki.
Its important that this app is extremely easy to use, and I also want it to look good relative to contemporary web applications (such as the examples available on the Chrome web store). Since I am not a web designer, I'm hoping to use tools that give me an attractive UI "out of the box". Oh, and I need to keep the distributable file reasonably small (un him so whatever I use needs to be reasonably lightweight.
So far, I've looked at Sproutcore and GWT.
Sproutcore apps definite have the appearance I'm hoping for, but I'm not that familiar with JavaScript, and after some experimentation is not entirely clear to me how I will achieve some of the more sophisticated functionality that I think I'm going to need.
Being Java, GWT is more within my comfort zone, however I had a hell of a time just getting my development environment set up properly. It seems that GWT wants to dictate the structure of my application, but since the user interface is only a small part of it I'm not willing to build the entire app around GWT.
Something else I've been thinking about is using CoffeeScript (which seems more palatable him and him him him him him than JavaScript, and there are Maven builders for it), perhaps together with JQuery-UI.
What other options should I consider?
To recommend two big javascript frameworks Sencha and Cappuccino.
These have an extensive UI toolkit out of the box. The latter has an MVC framework build in, the former has a general JavaScript library build in. Both come highly recommended.
Also as recommended jQuery UI is a reasonable toolkit. I would personally couple Sencha for its rich UI toolkit and a lightweight MVC framework like Backbone. I'm afraid this does require learning JavaScript well.
You can also instead drive your JavaScript UI toolkit mainly from the server and skip the clientside MVC. For that sencha should surfice as a UI toolkit, but if you want meaningful functionality you will need some more structure. I would also recommend RequireJS for modular file management.
Take a look on Vaadin its based on GWT but simpler to use. I use it since 2 years and i'am not a designer too.
Take a look at jQuery & jQuery UI (jQuery Modile if you are looking to deploy to hand held devices)
Also, since you mentioned that you are not a designer, you might want to implement the front end in an MVVM pattern to separate the UI from the business logic of your applications. Knockout is a nice way to do with with decelerative data binding
I don't like writing plain JavaScript, so I'll tell you little bit about Java based frameworks. Recently, I've picked Google Web Toolkit.
Pros:
plenty of materials
Eclipse + Google plugin
Very intuitive API
3rd party libraries
Fancy widgets + optimized JavaScript
lot of generics
very active community
awesome async callbacks
Cons:
very slow debugging, that will drive you mad sooner or later
lot of deprecated code for so young framework
Mixed feelings:
You don't have to write declarative UI (you can do Swing-like development), but your code grows bigger and less maintainable, so it is quite probable that you'll eventually learn some declarative UI like UI Binder
Visual designer for GWT is somehow nice, but very unstable (eclipse) :(
Some considerations:
Do some prototyping with Vaadin. Try some debugging. Then try GWT and debugging on similar sized project. Consider debugging as the VERY important decision factor, because GWT debugging was the most frustrating thing for me.
Consider JSF + some nice rich component framework for JSF like RichFaces, IceFaces, PrimeFaces etc (but you app won't be "light" and "small" anymore if you really care). Be sure to be perfectly comfortable with environment (IDE + plugins), nothing beats JSF there (I'd pick RichFaces + Seam today, if full Java EE is option).
If you don't want to learn javascript I recommend you GWT with Sencha-GWT (GXT), you can develop all your app in java language, and also debug your code in java.
It is very easy to create a web app with this technology, and provides almost all funcionality available in javascript version.
Also you can mix it with hibernate and giled to persist your data, and giled helps you to serialize hibernate objects.
I have been writing an application in SproutCore for the front-end and a Java backend. In my mind this works perfectly.
The backend can stop worrying about HTML and JavaScript contents on the client side, if the request is XHR or plain request/response. I can implement the backends using plain old Java Servlets, and only worry about the data that is passed between the client and the server (JSON for the most part).
The client becomed fast and responsive, and SproutCore has a rich amount of components that you can mix and match.
So in other words with SproutCore (and Cappuccino and other full-blows MVC JavaScript frameworks) you can let your client do what it does best : Render and display HTML, CSS and JavaScript, while leaving your server to worry about what it does best: retrieve, store and update data. If you are interested, the source code for this project is available with the GPLv3 licence: https://github.com/joachimhs/EurekaJ
I have written an article about the differnt approaches between server-side MVC and client-side MVC here: http://haagen.name/2011/05/24/The_RIA_MVC_Model.html.
Also SproutCore comes with the MIT licence, so its avaiable for use without (m)any restrictions.
In many JVM web frameworks survies and Indeed.com trends graphs, GWT looks to be the most (or among the top) popular JVM framework.
But AFAIK, GWT excels when the application is one page app -to some degree of course- (like GMail, Google Reader ..)
Does this mean that new developed Java webapps are one page apps mainly (not traditional request-new page response)?
Is it possible to develop SpringMVC or Struts2 style webapps with GWT? or it is not recommended?
Absolutely, it is definitely possible to build struts apps with GWT; at some level all the GWT is, is a convenient way of writing javascript (in my perl days, we called it 'syntactic sugar').
You can still use GWT-RPC, JSON, or HTML forms to communicate with the server.
You can attach to any arbitrary HTML element using RootPanel.get("id"); to add javascript widgets.
Almost every javascripty component on my employer's website is written in GWT: http://www.cohomefinder.com/ . The backend is an old fork of struts.
And here's a nice, though a bit dated, article about building 'normal' websites in GWT: http://www.canoo.com/blog/2007/03/13/building-a-regular-website-with-the-google-web-toolkit/
I'm not sure, however, that this use of GWT is where it really shines. One downside is a lot of javascript parsing on every page load. Code splitting can help with that, some.
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.