Templating Engines

 

 

TEMPLATE ENGINES

 

 

·        Template View -- the look and feel of the site

·        Servlet Controller -- who is it? what do they want?

·        Java Model -- ordinary business logic objects, JavaBeans

 

Template engines take pure markup language as input and generate Java methods.  This is a different program flow compared to JSP.  Instead JSPs calls logic from the application and the application server (i.e., Enhydra) uses methods to affect the values of the page. 

 

Using templating engines, however, the designer can make changes as often as needed and resupply the markup page or encapsulate HTML. These get compiled for you into Template objects, which generate HTML dynamically, using data provided by your servlets.

 

By using a template engine intended for this exact use instead of the general-purpose JSP, the underlying design can be cleaner, the syntax clearer, the error messages more meaningful, and the tool more customizable. Several companies have built such engines, the most popular probably being WebMacro (http://webmacro.org, from Semiotek) whose engine is free.

Using a dedicated template engine instead of JSP offers several technical advantages that developers should be aware of:

 

  • Template engines enforce good design
  • Template engines improve on JSP by removing the ability to put raw code in the page
  • There's no need to duplicate the page data into a second file, so hard drive space is spared.
  • Template engines also give the programmer full control over how templates are cached in memory.

 

 

 

WebMacro:

·        WebMacro is a 100% Java open-source servlet framework that enables programmers and designers to work together while promoting the Model View Controller pattern.  WebMacro is a viable alternative to Java Server Pages, PHP, and ASP. It's the fundamental page technology behind several major websites such as AltaVista.

  • WebMacro is a very focused template script language.  It provides a powerful class analyzer that can connect up ordinary Java objects with those templates: since WebMacro does all the work in hooking up your Java objects with the template, programmers never have to think about layout.

 

 

 

FREE

 

 

 

Apache Velocity:

“Best Practices”   http://dcb.sun.com/practices/profiles/velocity.jsp

“You make the decision” JSP vs. Velocity http://jakarta.apache.org/velocity/ymtd/

  • Company info: Apache Software Foundation, Forest Hill, MD; fax, 410-803-2258; jakarta.apache.org/velocity
  • Price:  Free
  • Velocity is a Java-based template engine based on the WebMacro idea.  It enables designers of Web pages to reference data defined in Java code as objects. The data, provided through Java code, can be any object the Web designer needs to create dynamically generated output for a Web page.
  • Because Velocity is a generalized template engine, it can be used to do more than create pages for Web sites. It can generate SQL statements, PostScript documents, Java source code, or XML documents. It can also be used as a stylesheet processor for XML documents.
  • Using JSP is now a multi step process. The authors of JSP have done a good job of hiding this process stuff behind the scenes in such a way that you do not even notice it. One simply edits the .jsp page in their favorite editor and then uses their browser to call the page via a URI which starts the process of transforming it into a .class file.
  • There are some fundamental issues that are being dealt with in the generated .jsp template. The first one is the class name. What happens is that the engine needs to produce a name that is unique in order to work around class loader issues that might crop up. Therefore, each and every time one modifies a .jsp page, a new file is created on disk in the temporary directory. Unfortunately, this directory ends up growing in size until someone decides to clean it up. The engine could probably do this for you, except then it might make the mistake of actually removing the wrong file.
  • Regarding JSP vs templating engines: The point being that this whole process of edit->transform->compile->load->run is really unnecessary and in particular, a bad design.
  • Error Handling: Velocity improves on JSPs by providing better error-handling.  One benefit, for example, is when an error is thrown, the error includes line number and column.
  • Buffering is also another big issue as constantly writing to the output stream is not very efficient.
  • Velocity does not suffer from as much debugging problems as JSP because there is no intermediate step and no layers of abstraction.
  • Velocity comes in with a simpler solution that is designed around the idea of a few core template tags. A scripting language is something like PHP which may require months of usage to completely master. A template language is something that can be mastered in just a few hours. This is what differentiates Velocity from being a scripting language vs. a template language.
  • One last point to make about using a HTML syntax is that this really pigeon holes JSP and Struts into simply being a tool for creating dynamic HTML/XML/WML (ie: tag markup) code. Velocity on the other hand is designed to take as input any type of text (Java, SQL, HTML, etc) and output anything as a result of running it through its processing engine.

 

 

 

FREE

 

 

 

 

 

 

Java Templating Engines not reviewed:

 

  • Tea:     Tea is a newly open sourced product from the Walt Disney Internet Group,
    created internally over the years to solve their tremendous web production
    needs for sites such as ESPN.com. It's similar to JSP although it avoids
    many of JSPs problems, and already has terrific tools support.  http://opensource.go.com/
  • FreeMarker 2.0     FreeMarker provides an easy way to get data from Java servlets into Web pages, and helps you keep graphic design separate from application logic. To use it, you encapsulate HTML in templates. These get compiled for you into Template objects, which generate HTML dynamically, using data provided by your servlets. The template language is powerful and intuitive, the compiler is fast, and the output approaches the speed of static HTML pages.  FREE

http://freemarker.sourceforge.net/

 

 

ClearSilver:

http://www.clearsilver.net/

ClearSilver is a Cross-language templating system.

  • Instead of allowing the separation presentation and code, it actively enforces it. There is no database connectivity, file system access, or anything of the sort available to a ClearSilver template. The templates only have access to a static dataset of strings. The dataset strings are contained in a hierarchical namespace that is populated by application code prior to the template rendering stage. This restriction is deliberate. It ensures that editing of a page template can do no work, and is thus pure presentation.
  • Enforcing this separation has many benefits. Debugging is simplified because it is divided into two distinct states -- debugging the application logic, and debugging of the presentation template. A website can be constructed in a truly language independent fashion. Application logic can be written in in C, Python, or any other language. The templates are the glue which plug together pieces from the different languages underneath into a single UI presentation. In fact, it is easy to generate individual pages from pieces of code written in multiple languages. However, the most important benefit is that changes made to the presentation templates won't introduce bugs into the application code.

 

 

FREE

 

 

Other Templating Systems:

 

Python:                        AHTS, htmltmpl, SkunkWeb, wt

Perl:                             Mason, Embperl, HTML::Template

PHP:                            Smarty, FastTemplate

 

 

 

Apache Turbine:

http://jakarta.apache.org/turbine/

  • Turbine (formerly known as Dash) is an Apache open source servlet framework to help "experienced Java developers quickly build secure web applications." It takes an object oriented approach to web application architecture.
  • Turbine can be used with Velocity, WebMacro, FreeMarker, and JSP.  
  • The point of Turbine is to collect that code into one location and make it easy to create re-usable components (such as ParameterParsing, Database Connection Pools, Job Scheduling, GlobalCaches, integration with other tools such as Velocity, Webmacro, etc...) all under a license (Apache) that allows you to create useful websites for your customers without worrying about viral code.
  • This framework has an intended audience that is directed at web engineers, not necessarily the web designers. By using this framework, it is possible for the web engineers to build intuitive high level systems for the web designers to use, but the low level framework is strictly for web engineers. Turbine is not a web application server. It is a tool for building web applications. Your servlet engine is your application server and the application that you develop using this framework is your web application.
  • The advantage of this type of behavior is that it prevents you from putting logic for handling form data into your servlets.

 

 

 

 

 

 

Opinions about JSPs and Templates (from newsgroups):

 

[Colleen] So JSP is a bad idea and JSP is a part of J2EE… so the best way to maximize the benefits of using Java and maintain the Model-View-Controller is through Java templating systems (Webmacro, Velocity, clearsilver)?

 

[JSP fan]  I could not disagree more!  JSP is *not* a bad idea.  In fact it is a very *good* idea.  J2EE (most notably EJB) is *not* a bad idea in *all case*, though EJB is often overused.  I have used JSP on the last 4 projects I have worked on, and it has been excellent to work with every time.

 

[JSP fan]  At the same time, I would recommend one of the JSP frameworks out there.  Two that I've been meaning to use are Struts and WebWork.

 

[JSP fan]   http://jakarta.apache.org/struts/

[JSP fan]  http://sourceforge.net/projects/webwork

 

[JSP fan]  Struts is more mature, though.

 

[JSP fan]  Another topic to follow is the standard JSP tag library.  Sun is working on a set of standard JSP tags that all servlet engines must provide.  These tags provide basic functionality like iteration and i18l support.  You can get a glimpse of what these will be like on the Jakarta Taglibs project:

 

[JSP fan]   http://jakarta.apache.org/taglibs/i

 

[Templates/Clearsilver fan]  I've read about the promises of Struts and JSP tags to help you clean up and keep JSP organized. However, I like real world examples. While I can find many examples of people writing sites in JSP, and even PHP, I've not heard those people extolling its flexibility.

 

[Templates/Clearsilver fan]  Here are a few things we were able to achieve with Clearsilver's cousin CS/HDF at eGroups.com and Yahoo:

 

  - easily mixed site pages between full-C, full Python, or Python/C    while sharing the same page template   parts. (same goes for any language)

 

  - easily had pages which render partially in fast shared C code and partially in slow script code (Python).

 

  - easily converted pages or parts of pages from Python (slow) to C (screaming fast) without changing page templates.

 

  - Changed 90% of the look and feel from egroups.com to Yahoo Groups, with one programmer in under 14 days.

 

    He didn't need to change the application code at all to implement the new look, and he did NOT break the old look and feel. We then had a few programmers implement the new required functionality and complete the project. It took longer to DESIGN the new UI than it did to implement it. Our QA team much appreciated the fact that few bugs were created in the process because the application logic was untouched.

 

  - Shiped Yahoo Groups-US while the remaining internationals ran the old eGroups UI....with the same code.

 

  - Kept eGroups Japan running for 6 months while all other  languages were switched over to Yahoo Groups UI, to allow time for Yahoo Japan to purchase eGroups Japan.... all with the same code.

 

[Templates/Clearsilver fan]  This great code/presentation separation was the reason all this was possible. Moving forward without this would have required code branches and committing and QAing the same code to two lines of development because we had to make significant backend changes to support integration into Yahoo.

 

[Templates/Clearsilver fan]  There are many other benefits of using template systems like Clearsilver or Velocity which JSP simply does not provide, such as:

 

1) Template systems create a far simpler development model where you first develop your code to output just a raw dataset (which is viewed as a text list of hierarchical key/value pairs). Then you drop in the template and plug in your values. This allows you to separately debug your code from your HTML and then rapidly go from a static HTML mockup to a working page, with just some simple cutting and pasting.

 

2) At any time you can look at the contents of the raw-dataset (just by dropping in an extra URL parameter). This makes it much easier to debug and fix broken HTML or oddly operating pages. It also makes it possible for QA level people to get access to the raw data from a page to help qualify problems.

 

3) Using Clearsilver, the entire page is rendered before it is output to the user. This reduces load on your database by allowing transactions to finish faster, and it also allows you to get real-time data about page render performance. Without this, any page performance becomes dependent on the user's download speed.

This makes it terribly difficult to debug page speed problems.

 

4) Using C/Clearsilver to render pages is 'really' fast, as fast as using straight C. Using Python/PyApache/Clearsilver can be faster than Java/JSP by a good margin depending on the operations in the page.

 

5) Code is decoupled from the template. There is no "object model" which must remain in place for the template to run. The code can be optimized at will, or completely rewritten, because it is merely required to output the same dataset as it did before for the template to run. You can get this property with well written PHP or JSP, but it's really hard to avoid all the ways you can break this. In real template systems, this is the only way to write the page, so it can't be broken.

 

[JSP fan]  Ok, I'm gonna be blunt.  There is *no* benefit to a templating engine over JSP.  I think one of the biggest issues of template engines is finding developers.  You'll have a much easier time trying to find an experienced JSP developer than an experience Velocity developer.  This has nothing to do with the technology, but due to the fact that there are more people using JSP than templating engines.

 

[Colleen]   One of the benefits of JSP, it seems, is that it allows designers to pick up the technology fast.  While this can be detrimental, in some ways it's beneficial.  We have a lot of designers here and only one technical person, is it very difficult to teach non-techies to use a template engine?

 

[JSP fan]  I would guess that JSP, PHP, and templating engines would all have similar learning curves for graphic designers.  When it comes down to it, they are all programming languages and you're going to end up teaching a non-technical person how to program.  If you need to do server side programming, hire a programmer!  A designer *will* make a mess of it, no matter which language or technology you choose.  Let designers do what they do best and programmers do what they do best. Forcing one or the other into the other role is asking for trouble.

 

[Templates/Clearsilver fan]  I agree that a dynamic application is basically an application no matter how you slice it. However, I find that even programmers will easily break other programmers’ pages written in PHP or JSP. Using a template language isolates ALL the application logic from the template. A programmer might break the form by incorrectly putting elements into the new page, but they won't break the underlying code because they don't have to touch it.

 

JSPs vs. Templates – Opinions on Session Caching

 

[Templates/Clearsilver fan]  The REALITY (imo) is that [centralized session caching] creates a whole lot of bad architecture which is impossible to performance optimize. You really don't want "centralized" app server which keeps persistent state and can crash. You really shouldn't use a centralized session caching server because it does not scale. If you want to cache something small, put it in a cookie, if you want to caching something big, put it in a caching server which can be segmented by some kind of key.

 

[Colleen]  Has anyone else on the list had some worthwhile experiences using App servers?

 

[JSP fan]  I have something to add and I would say the exact opposite in regards to centralized session caching.  Servlets do session tracking and provide you an place to store session-related information.  This is a great place to put transient information and it *does* scale.  Any servlet engine worth its salt should provide some means of distributed session management.

 

[Templates/Clearsilver fan]  The largest sites on the web (Yahoo, Amazon, MSN, About, eBay, AmericanGreetings, Weather Channel, Google) do not use server-side session management for a reason. Centralized Session servers/caching use more hardware to render pages slower.

 

[Templates/Clearsilver fan]  For example, let me explain a little bit about the network architecture for Yahoo Groups, where I used to run the engineering team.

 

[Templates/Clearsilver fan]  There is a big router/load balancer at the top, which routes every page request into one of 60 webservers. There is no webserver affinity. We found that using server affinity caused load distribution problems, which resulted in users getting slow pages from overloaded webservers.

 

[Templates/Clearsilver fan]  50-80% of page renders do not touch the database. The information from the database which is required to render most pages (i.e. group title, custom colors, which features are available at your access level) are cached into a "group cookie" on the client. That way, when you are paging around the message archives, the webserver only needs to contact one external server, where the message data is stored.

 

[Templates/Clearsilver fan]  If there were central session serving where information were cached instead of in cookies, then

 

   (a) You'll need twice as much hardware as if you were using cookies.

       One might argue that you don't use session serving very often.

       However, as you have seen in my example above, cookies are

       used on _every_ page to avoid hitting the database, thus every

       page would be hitting your session server. Everyone of those

       page hits would have to talk to your session servers, and thus

       they'll need to handle a similar load as your webservers.

 

   (b) Pages would be slower.  Webservers would need to contact an

       external server to retrieve session information.  It's not

       possible to store session caches on the webservers themselves

       because load-balancer server affinity does not work very well.

       The "upload bandwidth" required for the clients to send

       you the cookie cache data is largely unused on websites, so

       it's "for free".

 

[Templates/Clearsilver fan]  There are some scenarios where session caching makes sense, but they are rare. Most websites can easily avoid them and the performance problems they cause.

 

[Templates/Clearsilver fan]  As an aside, these same huge websites all use native C code for the most popular pages, because Perl, Python, and even Java, are too slow when you are large. However, I admit that most sites don't need to worry about this as they won't get this big.

 

 

 

 

 

Languages

 

In the end, the key is all about a good design.  Separating your application code from the UI is a good practice to get into, even if you're not doing web applications.

 

 

JSP:

http://java.sun.com/products/jsp/index.html

  • Java Server Pages is a technology for creating dynamic web pages advocated by Sun using the Java programming language.  JSP technology is about separating content from presentation.
  • Allows normal HTML pages (and later, WML or other markup language pages) to be compiled at runtime into a Java servlet, essentially mimicking the out.println() paradigm, without requiring the developer to write this code. And it allows you to insert variables into the page that are not interpreted until runtime.
  • JSPs let you insert Java code directly into a page of markup.
  • JavaServer Pages technology is an extension of the JavaTM Servlet technology. Servlets are platform-independent, 100% pure Java server-side modules that fit seamlessly into a web server framework and can be used to extend the capabilities of a web server with minimal overhead, maintenance, and support.
  • They are excellent for server-side processing, and, with their significant installed base, are here to stay. In fact, architecturally speaking, you can view JSP as a high-level abstraction of servlets that is implemented as an extension of the Servlet 2.1 API.

 

 

 

“What is Wrong With Java Server Pages”

http://php.weblogs.com/jsp  

“JSP technology -- friend or foe?”

http://www-106.ibm.com/developerworks/library/w-friend.html?dwzone=web  

 

 

  • Java makes a poor scripting tool. It's not suitable for rapid application development. It's better suited for writing rock-solid code methodically. Before diving into JSP coding, be careful of the rather large hole that lies between its ideal, a complete separation of content and presentation, and what it actually provides, which is at best a pseudo-split between your user interface and the code that drives your application.
  • JSP allows Java code to be inserted into the markup language page, and this rather dangerous feature allows content to be intermingled with presentation. Even worse, business logic often makes its way into JSP pages.  As long as JSP coding allows inline coding, it is very convenient (especially when deadlines are looming) to make last-minute changes with inline code, rather than converting the code to a tag library.
  • The problem is that some designers use HTML editors that do not recognize code scriptlets or tag libraries, which means the designer effectively receives only a partial page.  Imagine the difficulties when tag libraries or code fragments generate rows of a table, or other formatting details for the page. Designers using the incompatible HTML editors can't see what those elements look like. When designers can't easily revise pages after developers finish coding them, instead of clarifying distinct roles, JSP coding can cause them to merge: a developer must multitask, becoming developer, designer, and more.
  • If the application were to allow the JSP page to be evaluated by the original client, the result would be pure HTML (or WML, VXML, and so on). Most applications that request this data, however, employ some form of caching, as network round-trips are very expensive. In these cases, the cached page returns stale data. In those cases, then, you'd probably prefer to return pure XML-compliant results, preferably in a static form. And it is in those cases that JSP technology cannot help; JSP pages must always be evaluated at runtime to remove the JSP code scriptlets and tag libraries.

 

 

 

“Intro to JSP” 

http://hotwired.lycos.com/webmonkey/01/22/index3a_page5.html?tw=programming

Servlets have made great strides in the area of persistence. When a servlet is loaded into the server's memory, it generally remains there as a very compact Java object. When a server using servlets receives a request, there are no interpreters to spawn or variables to instantiate (beyond the first time). This means servlets are efficient: They stand vigilantly like the Marines, always prepared, ready to serve. Also, in addition to their efficiency, servlets are very tightly integrated with the server, which enables more sophisticated interactions with the server than is possible with CGI.

JSP brings all of the power of the Java language to bear on the client/server interaction. Portability, multithreading, extensive class libraries, object-oriented code, strong safety features, robust security measures, elegance, and extensibility are just a few of Java's advantages. For further evidence, look at how the ColdFusion people have added the JRun application server in their product to interact with JSP, servlets, and other Java technologies.

 

Unlike other scripting languages, servlets involve no platform-specific consideration or modifications; they are Java application components that are downloaded, on demand, to the part of the system that needs them. Together, JSP technology and servlets provide an attractive alternative to other types of dynamic web scripting/programming that offers platform independence, enhanced performance, and separation of logic from display, ease of administration, extensibility into the enterprise and most importantly, ease of use.

 

Thanks to its foundation in Java and its use of Java threads to handle incoming requests, JSP is a great deal more efficient than many other scripting languages, such as CGI. Its threading model and error handling also help prevent server hangs and crashes. And when the underlying Java Virtual Machine (JVM) makes use of Just In Time (JIT) compilation, the performance of well-written JSP can approach that of C++.

 

 

 

 

 

 

“Has J2EE Hit a Fork In the Road?”

http://www.sdtimes.com/news/045/story1.htm

 

Recent decisions by major J2EE app server vendors to extend J2EE in proprietary directions have made official what has been known for a long time—the promise of Java is now dead.

  • The platform-independent view of Java is fading into the woodwork very quickly, and threatens to take what was conceived as a standards-based solution into very different proprietary directions.
  • People are continuing to recognize that they are not getting what they were promised, according to Will Zachmann, vice president of Meta Group Inc.’s Open Computing and Server Strategies practice. “They are definitely not getting adequate performance with entity beans, nor reusability, rapid development or total platform independence. The actual ability to take a complex application from one J2EE application server vendor’s product to another is just not happening.”
  • “Anyone that is doing enterprise Java development is learning that you don’t pick up an application from one application server and drop it on to another without any pain,” said Zachmann.

 

Opinions about J2EE:

Benefits: lots of people use it, lots of products available

Drawbacks: slow architecture (especially J2EE), JSP is messy

 

Java Servlets:

http://www.webmacro.org/JavaServlets

 

The Java Servlet API is one of the APIs which form the Java2EnterpriseEdition (J2EE). Servlets play a key part in almost any Java application which has a web interface. The role of servlets in a web application is to interact with the HTTP protocol, handling requests from browsers, decoding any supplied data, performing any required processing using the facilities provided by the rest of the web application, and supplying the results back to the browser.

  • Java Servlets may be considered as a replacement for older, less-efficient, or platform specific ways of providing a web interface. If you have servlet facilities available, there should be little reason to develop CGIs or server plugins
  • To start using servlets, you need a Java runtime system (also known as a Java Virtual Machine, or JVM) and a Servlet Container (also known as a Servlet Engine or Servlet Runner)
  • Servlets have the benefit of being threaded.  Each instance of a servlet handles multiple requests simultaneously.
  • Servlets do not data manage. You need to use Java Beans, Java Data Base Connectivity API (JDBC), or some other API to manage your back-end data.
  • Servlets do not do page generation. A sophisticated site will want to extend the Form Handling, Session Management, and other services provided by the API.
  • Promote parallel workflow.  Designers and Programmers work independently.
  • A servlet is a way of extending your web server with a Java program to perform tasks previously dealt with by CGI scripts or proprietary server extension frameworks.  http://jguru.com/faq/view.jsp?EID=24796
  • Also, it must implement the Servlet interface from the servlet API. http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/Servlet.html
  • Typically for the web, you'll actually be extending the HttpServlet class. http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/http/HttpServlet.html
  • http://java.sun.com/products/servlet/ is the start of all this info.

 

Opinions about Servlets:

A Java-based templating engine, like Velocity, is usually implemented as a Java servlet.

 

 

 

 

More on Servlets:

However, if misused the servlet API can actually increase the time required for development versus a popular tool like PERL or PHP.

The correct approach is to spend a small effort generating something that is just good enough to give the client a better idea. Then allow frequent changes as the project moves forward. Your servlet design must accommodate this.

 

  • Good designs allows prototyping
  • Good designs allow frequent, easy changes
  • Good designs produce visible results at every stage to abstract out the important principles, and illustrate them clearly in your servlet code--only then can a programmer look at the whole and feel like its well understood.
  • Servlet programmers must be able to write clear code
  • Servlet page designers must be able to operate on the whole page

 

 

 

JavaBeans:

http://java.sun.com/products/javabeans/faq/faq.general.html#Q1

http://developer.java.sun.com/developer/onlineTraining/Beans/Beans1/bean-definition.html

JavaBeans is a portable, platform-independent component model written in the Java programming language. JavaBeans components, or Beans, are reusable software components that can be manipulated visually in a builder tool. Beans can be combined to create traditional applications, or their smaller web-oriented brethren, applets. In addition, applets can be designed to work as reusable Beans.

Having artists and developers working on the same file wasn't ideal, and having Java inside HTML proved almost as awkward as having HTML inside Java. It could easily create a hard to read mess. So people matured in their use of JSP and started to rely more on JavaBeans. Beans were written to contain business logic code needed by the JSP page.

Individual Beans will function quite differently, but typical unifying features that distinguish a Bean are:

·        Introspection: enables a builder tool to analyze how a Bean works

·        Customization: enables a developer to use an app builder tool to customize the appearance and behavior of a Bean

·        Events: enables Beans to communicate and connect together

·        Properties: enable developers to customize and program with Beans

·        Persistence: enables developers to customize Beans in an app builder, and then retrieve those Beans, with customized features intact, for future use.

JavaBeans are reusable software components written in the Java programming language, designed to be manipulated visually by a software development environment, like JBuilder or VisualAge for Java. They are similar to Microsoft's ActiveX components, but designed to be platform-neutral; running anywhere there is a Java Virtual Machine (JVM). http://jguru.com/faq/view.jsp?EID=13625

 

 

 

ColdFusion:   http://www.cfm-resources.com/cf_asp_jsp.cfm

ColdFusion Studio tries to automate the coding process as much as possible. Since it features automatic tag completion, expression builders, tag choosers, and wizards, the amount of stuff you actually have to key in is minimal. CF Studio gives you almost instant access to every command, method, property, constant, function, and variable available. This minimizes the amount of time you spend looking for information and maximizes the time you spend using it.

Once you've got your environment set up, you need a way to debug your code. CF Studio obliges with an excellent built-in debugger. It allows you to set breakpoints and watches and keeps track of the tag stack, variables, recordsets, and CF output generated during execution. With this information, you can step through an entire application and locate errors with ease.

Perhaps my favorite thing about ColdFusion is the way it makes use of custom tags. Any ColdFusion page you create can be called as a custom tag.

 

PHP:

PHP isn't just a database-centric language. It does so much more: dynamic graphics generation, IMAP, SNMP, LDAP, XML — they're all there.

According to PC Magazine, PHP is more mature than either ASP or JSP.  PHP can interface with Sybase, Oracle, Informix, Solid, Postgres, and even MSSQL.

PHP has been criticized for its lack of session handling. But this was overcome previously by the use of the PHPLIB library, and now session support has been built into PHP4. And ISAPI support, which had been lacking, is also now covered by PHP4 (plus PHP contains a generalized server API library to make it easily adaptable to other Web server APIs).

With PHP, each source of page information is essentially treated equally in that each becomes a normal variable within your script.

PHP is an established server-side scripting language for creating dynamic Web pages. As a language that has been designed expressly for the Web, it brings many features that commercial entities are looking for:

  • Exceptionally short learning curve
  • Quick development time
  • Very high performance
  • Designed specifically for Web development

 

 “Advantages of PHP Over Java”

http://zend.com/zend/art/php-over-java.php

JSP's performance also leaves much to be desired: a recent survey in ZDnet's eWeek online publication found that PHP is as much as 3.5 times faster than JSP. In the Web environment, this makes JSP a significantly worse solution – because it can perform fewer transactions per second, and features considerably slower response times.

  • PHP also can also integrate with Java, which means that it can be used as the scripting language for activating Java logic, just as much as JSP can.
  • Easier learning curve.  Code changes do not require a programmer.

 

Opinions about PHP:

> There are some articles comparing JSPs and PHP and it says that PHP pages load 3.5 times faster.

Maybe for the first hit after you put the web server up, but not after that.  The JSP becomes a compiled Java class and it is run out of byte-code (and then out of machine code if your JIT is working well) while a PHP page is interpreted each time.  PHP will be slower in the long run because of this, IMHO.

PHP is GREAT for small projects

If you are just hacking out two or three pages, just use PHP. If two or three pages is going to turn into 20, and more than one person is going to work on it, then a Model-View-Controller style template system works best.

 

Python:

http://www.python.org/

 

Rocketmail, which became Yahoo Mail, was at one point entirely written in Python. 

 

eGroups.com, which became Yahoo Groups, was at one point entirely written in Python.

 

Python is just as fast as, and easier to use than, Perl, although it is certainly less popular.

 

  http://www.bagley.org/~doug/shootout/craps.shtml

 

 

Python doesn't have anywhere near the kind of following Java does. 

 

.NET Framework:

“Microsoft .NET vs. J2EE: How Do They Stack Up?”  http://java.oreilly.com/news/farley_0800.html 

·        C#, a "new" language for writing classes and components, which integrates elements of C, C++, and Java, and adds additional features, like metadata tags, related to component development.

·        A "common language runtime", which runs bytecodes in an Internal Language (IL) format. Code and objects written in one language can, ostensibly, be compiled into the IL runtime, once an IL compiler is developed for the language.

  • A set of base components, accessible from the common language runtime, that provide various functions (networking, containers, etc.).
  • ASP+, a new version of ASP that supports compilation of ASPs into the common language runtime (and therefore writing ASP scripts using any language with an IL binding).
  • Win Forms and Web Forms, new UI component frameworks accessible from Visual Studio.
  • ADO+, a new generation of ADO data access components that use XML and SOAP for data interchange.

·        JDEE vs .NET: NET is a sign of a subtle but significant shift in Microsoft's strategy to evangelize their platforms. They have been fighting alternative frameworks and platforms at the management level pretty well, touting the usual questionable "statistics" about cost of ownership and seamless integration. Now they are fighting Java and open source initiatives on their own terms, putting their own spin on "open" and attempting to directly address the needs of developers, two things that they have been faulted for not doing very well in the past.

 

 

Opinions about .NET:

This is not a framework we want to consider.  Server side Java is leaps and bounds more mature than .NET at this point.  Unless you absolutely need to move to .NET for something (aka you're at an all MS shop with developers who will only use MS products or you have existing ASP code you want to use), I would steer clear of .NET until it proves itself.

 

 

 

 

 

What about XML?

http://www.w3.org/TR/1998/REC-xml-19980210

Most database servers are on a collision course with XML. The move to XML is a natural tie-in with a new approach to computing—deploying database-enabled Web applications running on application servers in place of standalone Windows programs. XML is causing database vendors to rethink their direction from the ground up, and the SQL language itself could well be on the way out in a few years, potentially to be replaced by an XML-based language called XML Query, now in development.

  • XML is straightforwardly usable over the Internet.
  • XML supports a wide variety of applications.
  • The XML design can be prepared quickly and the design of XML is formal and concise.

FREE

 

 

 

 

Opinions about XML:

[Colleen]  Just like you can use Velocity or Clearsilver to output HTML or WAP, you can use them to output XML.

 

[Templating/Clearsilver fan] If you use XML at the start, you are going to use XSLT (the XML transformation language) to convert it into HTML for your website. However, you will ALSO use XSLT to transform it into different looking XML data for another service such as voice... If you find it more convenient to start with XML just so you can again transform and dump into a different XML, then perhaps you would find using XML from the start easier. However, I personally find XML/XSLT too complicated for my needs in templating.

 

[Templating/Clearsilver fan]  In short, Velocity and Clearsilver are much simpler and nicer, and you can still output XML when you want to.

 

[Templating/Clearsilver fan]  As an example, using Clearsilver's cousin CS/HDF, we setup the Yahoo Groups website simultaneously running WAP, the old eGroups.com UI in Japanese, and the new Yahoo Groups UI in several languages... it ran like that for over six months through many releases. I've heard people talk about stuff like that in XML/XSLT, but I've never heard of anyone DO it.

 

[Colleen]

> If we plan to deploy content for various mediums (browser, wap,

> voice?) isn't XML the best choice?  If we decide not to go that route

> (XML) now, would it be difficult to implement later on?

[JSP fan]  I do not think XML is the best choice.  IMO, a wise choice would be to write your software with a good MVC design.  Then write different "views" tailored to the specific medium.  Done right, your views will be very easy to write.  I don't think XML/XSLT really lives up to its promise, here.  And if you go this route and want/need XML and XSLT in the future, XML is just another view!

 

XSL:

http://www.w3.org/Style/XSL/

·        XSL is a language for expressing stylesheets. An XSL style sheet is, like with CSS, a file that describes how to display an XML document of a given type.

·        It consists of three parts: XSL Transformations (XSLT): a language for transforming XML documents, the XML Path Language (XPath), an expression language used by XSLT to access or refer to parts of an XML document, and XSL Formattin