I would like to know what does .do webpages stand for ( as .php stands for PHP pages with PHP Scripting) and what is the scripting language behind it.
http://www.fileinfo.com/extension/do
According to WikiPedia, .do is:
a pseudo file extension representing
an Apache Struts action. It does not
map to an actual file extension,
although it appears that way.
However, you can't really say anything about the technology behind based solely on the "extension", i.e., the server can be configured to use .do for PHP files etc. This can be done in order to secure backwards compatibility or whatever.
.do is the commonly used convention to denote a Struts action. Like .jsf for JSF .
But there is no compulsion that all struts action should map to .do extenstion. It can be configured in
web.xml to .anything. Also a simple servlet can also be mapped to a .do extension. So nothing can be derived by just looking
at the URL.
While .do seems to be a Struts convention, it is used in Spring and Spring MVC as well. This SO thread talks a little bit about that, also noting that whereever Servlets are used, '.do' files can be used: Why do Java webapps use .do extension? Where did it come from?
Related
I'm developing a web application and using JSF 2.2 and Primefaces.
It contains a lot of output texts, user warning messages etc. I want to support many different languages. What is the most usable way to do this? Is there any standard or efficient procedure to achieve this?
JSF supports internationalized messaging through locale specific .properties resource files. Once a locale is set, either implicitly via the browser or explicitly by the user, the appropriate bundle will be loaded. For browser settings:
<f:view locale="#{facesContext.externalContext.requestLocale}">
You will also need to define the <resource-bundle> in you faces-config.xml where base-name defines the base file name and var defines the scoped result map.
I would start with this doc from #BalusC: http://jdevelopment.nl/internationalization-jsf-utf8-encoded-properties-files/
Also from #Mkyong: http://www.mkyong.com/jsf2/jsf-2-message-and-messages-example/
I just realized a JSF (web JavaScript application) that connect to a MongoDB database and generate a report (PDF) thanks to JasperReports Library (so with a .java file).
Is it possible to do the same thing with a web application in CoffeeScript and Node.js? I am really new to this, so I don't know where to start.
For example: Is it possible to run a .java thanks to Node.js or CoffeeScript?
JSF is actually a JavaServer Faces application, not a JavaScript application. JavaScript (which Node.js, CoffeeScript are based on) is not equivalent to Java despite the similarity in names.
If you already have a JSF-based application then you already should have everything you need to create a web-based application. There is no need for Node.js, CoffeeScript, etc.
Go take a look at JSP, Tomcat, etc. to figure out how to render web pages rather than output to PDF and you should be set.
If you want to rewrite your application in javascript and run it on node.js, you should be able to use PDFKit to build the PDFs.
If you only wish to use your existing application and integrate it with a node.js server, I think you would be wise to run them in parallel (or proxy requests to your JSF application through node, in case that makes sense). It's hard to give a better answer unless you can state more clearly what it is you want to accomplish.
Yes, it's possible. You can start / stop / control another process with Node.js - so You can start .java in another process and use it to generate PDF. But ... it may be not very efficient in terms of resource usage, so it's an open question.
Or, you can write a simple worker that will generate PDF from JSON data and use 0MQ or other inter-process communications between Node.js and this Java worker.
He-he, JSF was one of the worst technologies I ever saw (I believe it's still in the same state now as it was in 2007 when I left Java), even dumb JSP and servlets was better...
Just wondering which programming languages is used on the web pages with the extension ".do"
According to FileInfo, the file extension is for Java Servlets.
Strictly speaking, you can't tell for sure just by looking at the extension. I can configure a web server to interpret *.do URLs as referring to PHP files or even executables and run it accordingly. In fact, *.do URLs may not even refer to files at all! It really does depend on how the server is configured.
That is typically not so much a programming language feature but a framework feature: apps developed with Apache Struts (see http://struts.apache.org/) typically use that extension.
.do extension is used to build a J2EE enterprise application using Struts and dao factory method that is latest technology framework to build EE applications. It is much faster and efficient than JSP and JSF.
I'm puzzled because of build and run errors that mislead me. From them, I can't quite figure out what the distinction is between the various JavaServer Page Standard Tag Libraries. For instance, I see:
jstl.jar (in Apache Tomcat)
jstl-1.2.jar (in Tomahawk examples)
jstl-impl.jar (in GlassFish)
In times past, I've used (and recently recovered and have stored privately against disaster) from javax.servlet.jsp.jstl
jstl-api-1.2.jar
jstl-impl-1.2.jar
These latter are the only ones I seem to be able to use reliably in doing JavaServer Faces (JSF) work.
There's no wiki statement I've found that contrasts these different JARs. Yeah, I know their ages are different. I wonder, for instance, if jstl.jar isn't supposed to be a modern, definitive, both in one (api and impl) and I'm just using the wrong JSF libraries (myfaces-api-1.2.8.jar, for instance) to go with it?
My purpose is to establish a definitive set of JARs for doing Facelet work using either MyFaces or RichFaces, the two I know best.
Thanks to anyone who can shed some light and best practice on this.
If your target servletcontainer has it builtin, then you do not need to have any in your /WEB-INF/lib. Full fledged Java EE containers like Glassfish and JBoss AS have it builtin.
If your target servletcontainer does not have it builtin (Tomcat, etc), or you want to cover as much as possible servletcontainers, then you need to pick the newest JSTL version which matches the Servlet API version as declared by your web.xml.
For more detail about JSTL version differences and where to download them, see our own JSTL tag wiki page. It's the same page as when you hover the jstl tag below your question and click info.
I'm starting work on a new website (sort of an e-commerce product comparison thing) and I'm trying to choose what technologies to build it on. I've ruled out PHP and I don't think I want to use Python or Ruby. I really like Java and Hibernate so I started looking into Java-based web technologies.
My problem is that all of the documentation and examples I've read can't seem to stop repeating the words "enterprise" and "web applications." I'm afraid of ending up with giant XML configuration files and business-oriented components while losing the ability to actually design the website. From what I've read of JSF, I like the idea of reusable components, but I still want the ability to customize individual pages. So my question is, are JSF/Seam/Spring well-suited for non-enterprise development? If not, what Java technologies are?
I have just started looking into JSF/Seam so please forgive me if this is an uninformed quesiton. Thanks in advance. :)
No problem. The JSF/Seam stack gives you all the customization you want, and it has very few XML files. In fact, it uses a lot of annotations to define entities and components, so you don't have to worry about writing tou much XML (it is one of the reason why Seam was invented).
JSF's standard components are rendered as simple HTML tags, while if you want to go AJAX and use Richfaces it will be a little harder to customize it, but nothing dramatic. I can assure you that for the view part, you can write whatever you want in your webpages.
Here's a nice reference of how the JSF tags are rendered.
For the model and DB part, the JPA framework gives you the ability to work with simple Java Objects, and sometimes using it in an "enterprise" context with legacy schema is even more difficult, so don't worry.
For a simple website you may safely skip the EJB part, this will help you writing a more cleaner project structure. You can package all your website in a simple .WAR file.
As for the "enterprise" word, I think it is more related to the fact that the Java EE framework gives you the feature you may need in an enterprise context, (i.e. EJBs), but you can avoid them.
They don't bite.