Littlebitz Long Time Memory

Encode doctrine entities to json symfony 2

noreply@blogger.com (littlebitz) — Fri, 23 May 2014 15:47:00 +0000

use Symfony\Component\Serializer\Serializer;

 
use Symfony\Component\Serializer\Normalizer\GetSetMethodNormalizer;

 
use Symfony\Component\Serializer\Encoder\JsonEncoder;

 

$serializer = new Serializer(array(new GetSetMethodNormalizer()), array('json' => new 
JsonEncoder()));

 
$json = $serializer->serialize($entity, 'json');

Media Queries para dispositivos standard

noreply@blogger.com (littlebitz) — Sat, 25 Jan 2014 17:29:00 +0000

/* Smartphones (portrait and landscape) ----------- */ @media only screen and (min-device-width : 320px) and (max-device-width : 480px) { /* Styles */ } /* Smartphones (landscape) ----------- */ @media only screen and (min-width : 321px) { /* Styles */ } /* Smartphones (portrait) ----------- */ @media only screen and (max-width : 320px) { /* Styles */ } /* iPads (portrait and landscape) ----------- */ @media only screen and (min-device-width : 768px) and (max-device-width : 1024px) { /* Styles */ } /* iPads (landscape) ----------- */ @media only screen and (min-device-width : 768px) and (max-device-width : 1024px) and (orientation : landscape) { /* Styles */ } /* iPads (portrait) ----------- */ @media only screen and (min-device-width : 768px) and (max-device-width : 1024px) and (orientation : portrait) { /* Styles */ } /* Desktops and laptops ----------- */ @media only screen and (min-width : 1224px) { /* Styles */ } /* Large screens ----------- */ @media only screen and (min-width : 1824px) { /* Styles */ } /* iPhone 4 ----------- */ @media only screen and (-webkit-min-device-pixel-ratio : 1.5), only screen and (min-device-pixel-ratio : 1.5) { /* Styles */ }

Creating a Mobile-First Responsive Web Design - HTML5 Rocks

noreply@blogger.com (littlebitz) — Sat, 21 Sep 2013 14:21:00 +0000

Creating a Mobile-First Responsive Web Design - HTML5 Rocks

Journey From DHTML To Ember.js/Angular.js

noreply@blogger.com (littlebitz) — Mon, 29 Jul 2013 13:41:00 +0000

Journey From DHTML To Ember.js/Angular.js

PHP isset() vs empty() vs is_null() - Virendra's TechTalk

noreply@blogger.com (littlebitz) — Mon, 29 Jul 2013 13:23:00 +0000

PHP isset() vs empty() vs is_null() - Virendra's TechTalk

gradient: All the CSS3 properties explained | css3files.com

noreply@blogger.com (littlebitz) — Fri, 22 Feb 2013 12:18:00 +0000

gradient: All the CSS3 properties explained | css3files.com

Web Analytics Technical Implementation Best Practices. (JavaScript Tags) - Occam's Razor by Avinash Kaushik

noreply@blogger.com (littlebitz) — Mon, 18 Feb 2013 12:38:00 +0000

Web Analytics Technical Implementation Best Practices. (JavaScript Tags) - Occam's Razor by Avinash Kaushik

The Top 10 Javascript MVC Frameworks Reviewed - CodeBrief

noreply@blogger.com (littlebitz) — Sun, 03 Feb 2013 09:53:00 +0000

The Top 10 Javascript MVC Frameworks Reviewed - CodeBrief

Simulating mouse clicks in JavaScript

noreply@blogger.com (littlebitz) — Wed, 16 Jan 2013 15:04:00 +0000

Simulating mouse clicks in JavaScript

There might be times when you would like to simulate a mouse click on an DOM Node and don’t know how (for instance, submitting a form when in multi-frame environment).

Furthermore, it would be nice if the functionality could extend the DOM, so as to be able to use it combined with other pre-existing features.
Here’s the script bellow, just added and use it as you please (Ex. document.getElementById(”my_element”).click();)

HTMLElement.prototype.click = function() {
var evt = this.ownerDocument.createEvent('MouseEvents');
evt.initMouseEvent('click', true, true, this.ownerDocument.defaultView, 1, 0, 0, 0, 0, false, false, false, false, 0, null);
this.dispatchEvent(evt);
}
}

The code above is for Firefox only. For IE, just call document.getElementById(”my_element”).click() - it works by default, out of the box.
Quick code explanation:

Extend/create the click function for the HTMLElement
Create e new Mouse Event. The ownerDocument property returns the root element (document object) for a node. The createEvent arguments can be: “UIEvents”, “MouseEvents”, “MutationEvents”, and “HTMLEvents”.
Ok, here you would normally have an initEvent, instead of initMouseEvent. The initEvent can take as parameters the name of the event, a boolean specifying whether or not the event can bubble (there are two phases, capture and bubble) and a boolean specifying whether or not the event’s default action can be prevented. The initMouseEvent can hold some other parameters (beside the ones from above), which you can check out here: initMouseEvent.
Dispatches the event into the implementations event model.

For a nice guide of firing events (cross-browser wise), you can checkoutfiring javascript events properly, where there are some nice examples to think of.
Just to give a short receipt from Jehiah’s post:

function fireEvent(element,event){
if (document.createEventObject){
// dispatch for IE
var evt = document.createEventObject();
return element.fireEvent('on'+event,evt)
}
else{
// dispatch for firefox + others
var evt = document.createEvent("HTMLEvents");
evt.initEvent(event, true, true ); // event type,bubbling,cancelable
return !element.dispatchEvent(evt);
}

Jquery Listar eventos de un objeto por consola

noreply@blogger.com (littlebitz) — Tue, 13 Nov 2012 17:05:00 +0000

var clickEvents = $('#selectores').data("events").click;

jQuery.each(clickEvents, function(key, value) {
console.log(value);
});

How To Install Magento Locally On Windows XP | Website Design, Content Management System And SEO | Blog

noreply@blogger.com (littlebitz) — Tue, 30 Oct 2012 16:56:00 +0000

How To Install Magento Locally On Windows XP | Website Design, Content Management System And SEO | Blog

Patrones de diseño en PHP: DAO Pattern

noreply@blogger.com (littlebitz) — Mon, 29 Oct 2012 10:32:00 +0000

El Objeto de Acceso a Datos es un patrón ampliamente utilizado.

Un problema recurrente en el desarrollo de software es el acceso a recursos de datos. En el ámbito del desarrollo Web, las aplicaciones tienden a recoger datos de algún motor de persistencia, por ejemplo, una base de datos.

Esta tarea de recoger y almacenar datos, se sitúa intuitivamente en los controladores de nuestros objetos dentro del modelo de datos. Distribuyendo la información a cada objeto cuando este lo precise.
Tareas comunes a todos los objetos del modelo, y que ligan fuertemente la parte Web de la aplicación con el acceso a la base de datos.

La idea de diseñar una capa intermedia entre la capa frontal y la base de datos, que provea de una interfaz de acceso a la base de datos, solucionará el problema de acoplamiento entre las dos capas, y además permitirá reutilizar el código común, evitando duplicidades, mejorando su extensibilidad y mantenimiento.

Ref. DAO Pattern in PHP » World of Web

EclipseZone - Keeping Eclipse running clean ...

noreply@blogger.com (littlebitz) — Mon, 03 Sep 2012 08:09:00 +0000

EclipseZone - Keeping Eclipse running clean ...

3 Column CSS Layout: Fixed Width And Centered - Vanseo Design

noreply@blogger.com (littlebitz) — Tue, 28 Aug 2012 19:37:00 +0000

3 Column CSS Layout: Fixed Width And Centered - Vanseo Design

A dark corner of PHP: class casting » Jasny · web development

noreply@blogger.com (littlebitz) — Thu, 05 Jul 2012 09:42:00 +0000

Sometimes you want things that simply look impossible in PHP. A few years ago I was using the DB library from PEAR. I wanted to add some functionality to the DB_Result class, however since the result object is created in the DB class and the class used for that isn’t configurable, I was kind of stuck there.
I solved this problem by writing a class extending the DB_Result class. The class had which used reflection to pull all the info out of the DB_Result class and created a new DB_Result_Ext object. In the end I decided that I didn’t like DB class at all (nor MDB2 for that mather), so I threw away this dirty code, however I always felt that there had to be a better way in solving these kind of issues.
The new solution for this problem I’m about to show, is really a dark corner of PHP and perhaps even dirtier than the other dirty solution. However the method can get you out of a jam when this situation arises.

PHP has a function serialize, which can create a hash from any type of variable, scalars, array, but objects as well. Using the unserialize function, PHP can recreate the variable from the serialized hashed. If we look at how an object is serialized, we see only the properties and the class name are stored. Serializing an object of the ‘mother’ class, with a protected variables ‘$myvar’, would give the following hash:

O:6:"mother":1:{s:8:"�*�myvar";i:5;}

We see an ‘O’ for object, the string length of the class name, the quoted class name and the properties. What would happen if we would change the class name and unserialize?

Let’s have a look at the following example:


/**
 * Parent class
 */
class mother
{
protected $myvar;
function __construct($value)
{
$this->myvar = $value;
}
}
/**
 * Child class
 */
class grandmother extends mother
{
protected $bval;
function __construct($value)
{
$this->bval = $value;
$this->myvar = $value / 10;
}
function __wakeup()
{
if (!isset($this->myvar)) throw new Exception("Illegal unserialize: The original object did not contain a myvar property.");
$this->bval = $this->myvar * 10;
}
function getVal() {
return $this->bval;
}
}
/**
 * Cast an object to another class, keeping the properties, but changing the methods
 *
 * @param string $class  Class name
 * @param object $object
 * @return object
 */
function casttoclass($class, $object)
{
return unserialize(preg_replace('/^O:\d+:"[^"]++"/', 'O:' . strlen($class) . ':"' . $class . '"', serialize($object)));
}
$a = new mother(5);
$z = casttoclass('grandmother', $a);
echo $z->getVal();

view raw class_casting.php This Gist brought to you by GitHub.

We have a class ‘mother’ and a class ‘grandmother’ extending ‘mother’. We create a ‘mother’ object and now we want to cast it to a ‘grandmother’. In the casttoclass() function, we serialize the object, use a preg_replace to change the class name and than unserialize the hash. This creates a ‘grandmother’ object, with a property ‘$myvar’ set to 5, however the ‘$bval’ property is not set. To solve this we can use the magic method __wakeup(). After the conversion, we can use $z normally as any other ‘grandmother’.

Regular Expressions: REGEXP_LIKE

noreply@blogger.com (littlebitz) — Thu, 22 Mar 2012 12:20:00 +0000

Regular Expressions: REGEXP_LIKE

PostgreSQL Regexp Operator and Functions

noreply@blogger.com (littlebitz) — Thu, 22 Mar 2012 12:18:00 +0000

PostgreSQL Regexp Operator and Functions

HTML select tag

noreply@blogger.com (littlebitz) — Sun, 11 Mar 2012 14:00:00 +0000

HTML select tag

Evitar que un script en PHP se ejecute desde navegador

noreply@blogger.com (littlebitz) — Mon, 20 Feb 2012 10:13:00 +0000

if (!empty($_SERVER['HTTP_USER_AGENT'])) die();

PHP y ORACLE

noreply@blogger.com (littlebitz) — Wed, 18 Jan 2012 15:38:00 +0000

Ahora mismo estoy poniendo un producción un servidor en mi centro de trabajo, en el que además de tener que dar servicio para la base de datos PostgreSQL (explique hace poco cómo permitir conexiones entrantes a esta BBDD), debe hacer conexiones externas a una base de datos Oracle.
Estas conexiones las hará un script en PHP por lo que además, deberemos instalar OCI (Oracle Call Interface) para PHP. Suponemos que está ya instalado el servidor web Apache 2 y los componentes básicos de PHP.

Instalación de Oracle instantclient
Antes de instalar el instantclient como tal, debemos instalar la librería libaio, necesaria para gestionar entradas/salidas asíncronas al kernel. La instrucción será (utilizo “#” en el prompt para indicar como superusuario, “$” en caso contrario):

# yum install libaio1

O si usamos una distribución que use APT:

# apt-get install libaio1

Lo siguiente será acceder al portal de descargas de Oracle y descargar los componentes necesarios para el instantclient:

Basic
Devel
SQLPlus

Elegimos la última versión, nuestra arquitectura y descargamos los paquetes RPM. La instalación será inmediata si tenemos una distribución basada en Red Hat:

# yum install paquete.rpm

En caso contrario, deberemos instalar alien previamente para que convierta los paquetes RPM en paquetes DEB:

# apt-get install alien
# alien paquete.rpm
# dpkg -i paquete.deb

Ahora ya nos tocar configurar el famoso fichero Tnsnames.ora. Este fichero variará de una configuración a otra por lo que sólo vamos a comentar dónde situarlo. Su ruta debe ser: /etc/oracle/tnsnames.ora, en caso de no existir, deberemos crearla.
Para terminar, deberemos crear unas variables de entorno. Para ello accedemos al fichero /root/.bashrc como superusuario e incluimos las siguientes líneas:

export TNS_ADMIN=/etc/oracleexport SQLPATH=/usr/lib/oracle/11.1.0.1/client/binexport LD_LIBRARY_PATH=/usr/lib/oracle/11.1.0.1/client/lib:$LD_LIBRARY_PATHexport PATH=$PATH:$SQLPATH

En algunas distribuciones, también podréis hacer ese cambio en otro fichero: /etc/environment.

Instalación de OCI en PHP
Ahora nos toca la parte de PHP, es decir, instalar los componentes necesarios para poder hacer llamadas a Oracle desde PHP usando el instantclient que acabamos de instalar (con lo fácil que es hacer esto mismo con MySQL o PostgreSQL…, las cosas del software cerrado).
Suponemos que tenemos instalado Apache2 y PHP, pero aún así instalaremos dos paquetes más:

# yum install php-pear php5-dev
# apt-get install php-pear php5-dev

PHP-PEAR es según definen sus siglas: PHP Extension and Application Repository, es decir, un repositorio de extensiones y aplicaciones para PHP que nos permite instalar sin problemas ciertos componentes de PHP que no podemos instalar a través de nuestro gestor de paquetes habitual (me recuerda a CPAN con Perl, pero esa es otra historia para otra entrada).

Ya estamos en disposición de ejecutarlo para instalar OCI:

pecl install oci8

En la terminal nos aparecerá algo así como:

1-1, ‘all’, ‘abort’, or Enter to continue:

Pulsamos “1″ luego ENTER y escribimos las siguientes opciones (debemos saber el PATH exacto de nuestras librerías Oracle, cambiará en función de la versión):

shared,instantclient,/usr/lib/oracle/mi_version/client/lib/

PHP-PEAR descargará, configurará, compilará e instalará el módulo. Finalmente, tenemos que añadir a nuestro fichero php.ini una línea para que cargue la librería dinámica de OCI y puedan hacerse llamadas desde los ficheros PHP.
La ruta del fichero será: /etc/php5/apache2/php.ini y la línea a agregar junto a las demás extensiones la siguiente:

extension=oci8.so

Reiniciamos el servidor web y listo:

services httpd restart

/etc/init.d/apache2 reload

Proxy Apache Mod

noreply@blogger.com (littlebitz) — Mon, 21 Nov 2011 11:05:00 +0000

Running a Reverse Proxy in Apache

Contents

In 2003, Nick Kew released a new module that complements Apache's mod_proxy and is essential for reverse-proxying. Since then he gets regular questions and requests for help on proxying with Apache. In this article he attempts to give a comprehensive overview of the proxying and mod_proxy_html

This article was originally published at ApacheWeek in January 2004, and moved to ApacheTutor with minor updates in October 2006.

Web Proxies ^

A proxy server is a gateway for users to the Web at large. Users configure the proxy in their browser settings, and all HTTP requests are routed via the proxy. Proxies are typically operated by ISPs and network administrators, and serve several purposes: for example,

to speed access to the Web by caching pages fetched, so that popular pages don't have to be re-fetched for every user who views them.
to enable controlled access to the web for users behind a firewall.
to filter or transform web content.

Reverse Proxies ^

A reverse proxy is a gateway for servers, and enables one web server to provide content from another transparently. As with a standard proxy, a reverse proxy may serve to improve performance of the web by caching; this is a simple way to mirror a website. But the most common reason to run a reverse proxy is to enable controlled access from the Web at large to servers behind a firewall.

The proxied server may be a webserver itself, or it may be an application server using a different protocol, or an application server with just rudimentary HTTP that needs to be shielded from the web at large. Since 2004, reverse proxying has been the preferred method of deploying JAVA/Tomcat applications on the Web, replacing the old mod_jk (itself a special-purpose reverse proxy module).

Proxying with Apache ^

The standard Apache module mod_proxy supports both types of proxy operation. Under Apache 1.x, mod_proxy only supported HTTP/1.0, but from Apache 2.0, it supports HTTP/1.1. This distinction is particularly important in a proxy, because one of the most significant changes between the two protocol versions is that HTTP/1.1 introduces rich new cache control mechanisms.

This article deals with running a reverse proxy with Apache 2. Users of earlier versions of Apache are encouraged to upgrade and take advantage of the altogether richer architecture and improved application support. At the time of writing, the reason most commonly cited for not upgrading is difficulties running PHP on Apache 2. I cannot speak from personal experience, but several well-informed sources tell me the difficulty lies with non-thread-safe code in PHP, and that it works well with Apache 2 if it is built with the non-threaded Prefork MPM.

The Apache Proxy Modules ^

So far, we have spoken loosely of mod_proxy. However, it's a little more complicated than that. In keeping with Apache's modular architecture, mod_proxy is itself modular, and a typical proxy server will need to enable several modules. Those relevant to proxying and this article include:

mod_proxy: The core module deals with proxy infrastructure and configuration and managing a proxy request.
mod_proxy_http: This handles fetching documents with HTTP and HTTPS.
mod_proxy_ftp: This handles fetching documents with FTP.
mod_proxy_connect: This handles the CONNECT method for secure (SSL) tunneling.
mod_proxy_ajp: This handles the AJP protocol for Tomcat and similar backend servers.
mod_proxy_balancer implements clustering and load-balancing over multiple backends.
mod_cache, mod_disk_cache, mod_mem_cache: These deal with managing a document cache. To enable caching requires mod_cache and one or both of disk_cache and mem_cache.
mod_proxy_html: This rewrites HTML links into a proxy's address space.
mod_headers: This modifies HTTP request and response headers.
mod_deflate: Negotiates compression with clients and backends.

Having mentioned the modules, I'm going to ignore caching for the remainder of this article. You may want to add it if you are concerned about the load on your network or origin servers, but the details are outside the scope of this article. I'm also going to ignore all non-HTTP protocols, and load balancing.

Building Apache for Proxying ^

With the exception of mod_proxy_html, the above are all included in the core Apache distribution. They can easily be enabled in the Apache build process. For example:

$ ./configure --enable-so --enable-mods-shared="proxy \
proxy_http proxy_ftp proxy_connect headers"
$ make
# make install

Of course, you may want other build options too, and you could just as well build the modules as static.

If you are adding proxying to an existing installation, you should use apxs instead:

# apxs -c -i [module-name].c
noting that mod_proxy itself is in two source files
(mod_proxy.c and proxy_util.c).

This leaves mod_proxy_html, which is not included in the core distribution. mod_proxy_html is a third-party module, and requires a third-party library libxml2. At the time of writing, libxml2 is installed as standard or packaged for most operating systems. If you don't have it, you can download it from xmlsoft.org and install it yourself. For the purposes of this article, we'll assume libxml2 is installed as /usr/lib/libxml2.so, with headers in /usr/include/libxml2/libxml/.

Check libxml2 is installed. If you have a version older than 2.5.10, then upgrade - there's a bug in earlier versions that can, in some particular cases, severely affect performance.
Download mod_proxy_html.c from http://apache.webthing.com/
Build mod_proxy_html with apxs:

# apxs -c -I/usr/include/libxml2 -i mod_proxy_html.c

A Reverse Proxy Scenario ^

Company example.com has a website at www.example.com, which has a public IP address and DNS entry, and can be accessed from anywhere on the Internet.

The company also has a couple of application servers which have private IP addresses and unregistered DNS entries, and are inside the firewall. The application servers are visible within the network - including the webserver, as "internal1.example.com" and "internal2.example.com", But because they have no public DNS entries, anyone looking at internal1.example.com from outside the company network will get a "no such host" error.

A decision is taken to enable Web access to the application servers. But they should not be exposed to the Internet directly, instead they should be integrated with the webserver, so that http://www.example.com/app1/any-path-here is mapped internally to http://internal1.example.com/any-path-here and http://www.example.com/app2/other-path-here is mapped internally to http://internal2.example.com/other-path-here. This is a typical reverse-proxy situation.

Configuring the Proxy ^

As with any modules, the first thing to do is to load them in httpd.conf (this is not necessary if we build them statically into Apache).

LoadModule  proxy_module         modules/mod_proxy.so
LoadModule  proxy_http_module    modules/mod_proxy_http.so
#LoadModule proxy_ftp_module     modules/mod_proxy_ftp.so
#LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule  headers_module       modules/mod_headers.so
LoadModule  deflate_module       modules/mod_deflate.so
LoadFile    /usr/lib/libxml2.so
LoadModule  proxy_html_module    modules/mod_proxy_html.so

For windows users this is slightly different: you'll need to load libxml2.dll rather than libxml2.so, and you'll probably need to load iconv.dll and xlib.dll as prerequisites to libxml2 (you can download them from zlatkovic.com, the same site that maintains windows binaries of libxml2). The LoadFile directive is the same.

Of course, you may not need all the modules. Two that are not required in our typical scenario are shown commented out above.

Having loaded the modules, we can now configure the Proxy. But before doing so, we have an important security warning:

Do Not set "ProxyRequests On". Setting ProxyRequests On turns your server into an Open Proxy. There are 'bots scanning the Web for open proxies. When they find you, they'll start using you to route around blocks and filters to access questionable or illegal material. At worst, they might be able to route email spam through your proxy. Your legitimate traffic will be swamped, and you'll find your server getting blocked by things like family filters.

Of course, you may also want to run a forward proxy with appropriate security measures, but that lies outside the scope of this article. The author runs both forward and reverse proxies on the same server (but under different Virtual Hosts).

The fundamental configuration directive to set up a reverse proxy is ProxyPass. We use it to set up proxy rules for each of the application servers:

ProxyPass       /app1/  http://internal1.example.com/
ProxyPass       /app2/  http://internal2.example.com/

Now as soon as Apache re-reads the configuration (the recommended way to do this is with "apachectl graceful"), proxy requests will work, so http://www.example.com/app1/some-path maps to http://internal1.example.com/some-path as required.

However, this is not the whole story. ProxyPass just sends traffic straight through. So when the application servers generate references to themselves (or to other internal addresses), they will be passed straight through to the outside world, where they won't work.

For example, an HTTP redirection often takes place when a user (or author) forgets a trailing slash in a URL. So the response to a request for http://www.example.com/app1/foo proxies to http://internal.example.com/foo which generates a response:

HTTP/1.1 302 Found
Location: http://internal.example.com/foo/
(etc)

But from the outside world, the net effect of this is a "No such host" error. The proxy needs to re-map the Location header to its own address space and return a valid URL

HTTP/1.1 302 Found
Location: http://www.example.com/app1/foo/

The command to enable such rewrites in the HTTP Headers is ProxyPassReverse. The Apache documentation suggests the form:

 
ProxyPassReverse /app1/ http://internal1.example.com/
ProxyPassReverse /app2/ http://internal2.example.com/

However, there is a slightly more complex alternative form that I recommend as more robust:


ProxyPassReverse /


ProxyPassReverse /

The reason for recommending this is that a problem arises with some application servers. Suppose for example we have a redirect:

HTTP/1.1 302 Found
Location: /some/path/to/file.html

This is a violation of the HTTP protocol and so should never happen: HTTP only permits full URLs in Location headers. However, it is also a source of much confusion, not least because the CGI spec has a similar Location header with different semantics where relative paths are allowed. There are a lot of broken servers out there! In this instance, the first form of ProxyPassReverse will return the incorrect response

HTTP/1.1 302 Found
Location: /some/path/to/file.html

which, even allowing for error-correcting browsers, is outside the Proxy's address space and won't work. The second form fixes this to

HTTP/1.1 302 Found
Location: /app2/some/path/to/file.html

which is still broken, but will at least work in error-correcting browsers. Most browsers will deal with this.

If your backend server uses cookies, you may also need the ProxyPassReverseCookiePath and ProxyPassReverseCookieDomain directives. These are similar to ProxyPassReverse, but deal with the different form of cookie headers. These require mod_proxy from Apache 2.2 (recommended), or a patched version of 2.0.

Fixing HTML Links ^

As we have seen, ProxyPassReverse remaps URLs in the HTTP headers to ensure they work from outside the company network. There is, however, a separate problem when links appear in HTML pages served. Consider the following cases:

This link will be resolved by the browser and will work correctly.
This link will be resolved by the browser to http://www.example.com/otherfile.html, which is incorrect.
This link will resolve to "no such host" for the browser.

The same problem of course applies to included content such as images, stylesheets, scripts or applets, and other contexts where URLs occur in HTML.

To fix this requires us to parse the HTML and rewrite the links. This is the purpose of mod_proxy_html. It works as an output filter, parsing the HTML and rewriting links as it is served. Two configuration directives are required to set it up:

SetOutputFilter proxy-html This simply inserts the filter, to enable ProxyHTMLURLMap
ProxyHTMLURLMap from-pattern to-pattern [flags] In its basic form, this has a similar purpose and semantics to ProxyPassReverse. Additionally, an extended form is available to enable search-and-replace rewriting of URLs within Scripts and Stylesheets.

How it works ^

mod_proxy_html is based on a SAX parser: specifically the HTMLparser module from libxml2 running in SAX mode (any other parse mode would of course be very much slower, especially for larger documents). It has full knowledge of all URI attributes that can occur in HTML 4 and XHTML 1. Whenever a URL is encountered, it is matched against applicable ProxyHTMLURLMap directives. If it starts with any from-pattern, that will be rewritten to the to-pattern. Rules are applied in the reverse order to their appearance in httpd.conf, and matching stops as soon as a match is found.

Here's how we set up a reverse proxy for HTML. Firstly, full links to the internal servers should be rewritten regardless of where they arise, so we have:

ProxyHTMLURLMap http://internal1.example.com /app1
ProxyHTMLURLMap http://internal2.example.com /app2

Note that in this instance we omitted the "trailing" slash. Since the matching logic is starts-with, we use the minimal matching pattern. We have now globally fixed case 3 above.

Case 2 above requires a little more care. Because the link doesn't include the hostname, the rewrite rule must be context-sensitive. As with ProxyPassReverse above, we deal with that using


ProxyHTMLURLMap / /app1/


ProxyHTMLURLMap / /app2/

Debugging your Proxy Configuration ^

The above is a simple case taken from mod_proxy_html version 1. With the more complex URLmapping and rewriting enabled by Version 2, you may need a bit of help setting up a complex ruleset, perhaps involving a series of complex regexps, chained anc blocking rules, etc. To help with setting up and troubleshooting your rulesets, mod_proxy_html 2 provides a "debug" mode, in which all the 'interesting' things it does are written to the Apache error log. To analyse and fix your rulesets, set

ProxyHTMLLogVerbose On
LogLevel Info   (or LogLevel Debug)

Now run your testcases through your rulesets, and examine the apache error log for details of exactly how it was processed.

Do not leave ProxyHTMLLogVerbose On for normal use. Although the effect is marginal, it is an overhead.

Extended URL Mapping ^

The previous section sets up remapping of HTML URLs, but leaves any URL encountered in a Stylesheet or Script untouched. mod_proxy_html doesn't parse Javascript or CSS, so dealing with URLs in them requires text-based search-and-replace. This is enabled by the directive ProxyHTMLExtended On.

Because the extended mode is text-based, it can no longer guarantee to match exact URLs. It's up to you to devise matching rules that can pick out URLs, just as if you were writing an old-fashioned Perl or PHP regexp-based filter (though of course it's still massively more efficient than performing search-and-replace on an entire document in-memory). To help with this, ProxyHTMLExtended supports both simple text-based and regular expression search-and-replace, according to the flags. You can also use the flags to specify rules separately for HTML links, scripting events, and embedded scripts and stylesheets.

A second key consideration with extended URL mapping is that whereas an HTML link contains exactly one URL, a script or stylesheet may contain many. So instead of stopping after a successful match, the processor will apply all applicable mapping rules. This can be stopped with the L (last) flag.

Dealing with multimedia content ^

We just set up a proxy to parse and where necessary correct HTML. But of course, the web isn't just HTML. Surely feeding non-HTML content through an HTML parser is at best inefficient, if not totally broken?

Yes indeed. mod_proxy_html deals with that by checking the Content-Type header, and removing itself from the processing chain when a document is not HTML (text/html) or XHTML (application/xhtml+xml). This happens in the filter initialisation phase, before any data are processed by the filter.

But that still leaves a problem. Consider compressed HTML:

Content-Type: text/html
Content-Encoding: gzip

Feeding that into an HTML parser is clearly broken!

There are two solutions to this. One is to uncompress the incoming data with mod_deflate. Uncompressing and compressing content radically reduces network traffic, but increases the processor load on the proxy. It is worthwhile if and only if bandwidth between the proxy and the backend is at a premium: this is common on the 'net at large, but unlikely to be the case on a company internal network.

SetOutputFilter  INFLATE;proxy-html;DEFLATE

The alternative solution is to refuse to support compression. Stripping any Accept-Encoding request header does the job. So invoking mod_headers, we add a directive

RequestHeader unset Accept-Encoding

This should only apply to the Proxy, so we put it inside our containers.

A similar situation arises in the case of encrypted (https) content. But in this case, there is no such workaround: if we could decrypt the data to process it then so could any other man-in-the-middle, and the security would be worthless. This can only be circumvented by installing mod_ssl and a certificate on the proxy, so that the actual secure session is between the browser and the proxy, not the origin server.

The Complete Configuration ^

We are now in a position to write a complete configuration for our reverse proxy. Here is a bare minimum, that ignores extended urlmapping:

LoadModule proxy_module      modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule headers_module    modules/mod_headers.so
LoadFile   /usr/lib/libxml2.so
LoadModule proxy_html_module modules/mod_proxy_html.so
 
ProxyRequests off
ProxyPass /app1/ http://internal1.example.com/
ProxyPass /app2/ http://internal2.example.com/
ProxyHTMLURLMap http://internal1.example.com /app1
ProxyHTMLURLMap http://internal2.example.com /app2
 

ProxyPassReverse /
SetOutputFilter  proxy-html
ProxyHTMLURLMap  /      /app1/
ProxyHTMLURLMap  /app1  /app1
RequestHeader    unset  Accept-Encoding

 

ProxyPassReverse /
SetOutputFilter proxy-html
ProxyHTMLURLMap /       /app2/
ProxyHTMLURLMap /app2   /app2
RequestHeader   unset   Accept-Encoding

Of course, there's more than one way to do it. Our configuration would actually have been simpler if we'd used Virtual Hosts for each application server. But that takes you beyond the realm of Apache configuration and into DNS. If you don't fully understand that (or if you think "why can't I see my domain" is a webserver question), then please don't try using virtual hosts for this.

Further topics ^

Caching ^

We haven't dealt with caching in this article. In a company-intranet situation, the connection from the proxy to the application servers is the local LAN, which is probably fast and has ample capacity. In such cases, caching at the proxy will have little effect, and can probably be omitted.

If we want to cache pages, we can of course do so with mod_cache But that is beyond the scope of this article.

Content Transformation ^

Another powerful use for a proxy is to transform the content on-the-fly according to the user's preferences. This author's flagship mod_accessibility product (from which mod_proxy_html is a spinoff) serves to transform HTML and XHTML on-demand to enhance usability and accessibility.

Filtering and Security ^

A reverse proxy is not the natural place for a "family filter", but is ideal for defining access controls and imposing security restrictions. We could, for example, configure the proxy to recognise a custom header from an origin server and block content based on it. This delegates control to the application servers.

Questions and Answers ^

(Q) Where can I get the software?

(A) Most of it from the obvious place, http://httpd.apache.org/ mod_proxy_html is available from http://apache.webthing.com/ libxml2 is available from http://xmlsoft.org/. Windows users should read libxml2.dll for libxml2.so, and can obtain it together with the prerequisites iconv.dll and zlib.dll from Igor Zlatkovic's site.

(Q) Can I get a binaries of software ?

(A) If there's no link at the websites above, ask the provider of your operating system or distribution. The author can compile it on different platforms but does not provide a free compilation service.

(Q) What is httpd.conf? My apache has different configuration files.

(A) Some distribution packagers mess about with the Apache configuration. If this applies to you, the details should be documented by your distributor, and have nothing to do with Apache itself! Substitute your distributions choice of configuration file for httpd.conf in the above discussion, or create your own proxy.conf file and Include it.

(Q) You mentioned apxs and apachectl. Where do I find them?

(A) They're part of a standard Apache installation (except on Windows). If you don't have them or can't find them, that's a problem with your installation. The easiest solution is probably to download a complete Apache from httpd.apache.org.

(Q) Does mod_proxy_html deal with Javascript links?

(A) From mod_proxy_html 2.0, yes!

(Q) The proxy appears to change my HTML?

(A) It doesn't really, but it may appear to. Here are the possible causes:

Changing the FPI (the line) may affect some browsers. FIX: set the doctype explicitly if this bothers you.
mod_proxy_html has the side-effect of transforming content to utf-8 (Unicode) encoding. This should not be a problem: utf-8 is well-supported by browsers, and offers comprehensive support for internationalisation. If it appears to cause a problem, that's almost certainly a bug in the application server, or possibly a misconfigured browser. FIX: filter through mod_charset_lite to your chosen charset.
mod_proxy_html will perform some minor normalisations. If your HTML includes elements that are closed implicitly, it will explicitly close them. In other words:
```
Hello, World!
```
will be transformed to
```
Hello, World!
```
If this affects the rendition in your browser, it almost certainly means you are using malformed HTML and relying on error-correction in a browser. FIX: validate your HTML! The online Page Valet service will both validate and show your markup normalised by the DTD, while a companion tool AccessValet will show markup normalised by the same parser used in the proxy, and highlight other problems. Both are available at http://valet.webthing.com/

(Q) I need a customised solution.

(A) The author is available for development and consultancy.

Aplicaciones Web con Java (pÃ¡gina 2) - Monografias.com

noreply@blogger.com (littlebitz) — Thu, 13 Oct 2011 14:23:00 +0000

En los últimos años las aplicaciones web han tenido gran auge gracias, en gran parte, a Internet y la proliferación de sitios web por toda la red, principalmente con el fin de fomentar el comercio electrónico. Su facilidad de administración centralizada las hace ideales tanto para su despliegue en redes de amplio alcance como en redes corporativas. La facilidad de uso de las interfaces web y el hecho de que cada día más personas están acostumbradas a la navegación por Internet hace que el tiempo de aprendizaje se reduzca considerablemente respecto a las tradicionales aplicaciones de escritorio.
Por otra parte, más reciente el creciente auge (en aumento acelerado) de multitud de marcos de trabajo de código abierto o libre hace que su desarrollo sea sencillo y que un gran número de desarrolladores tengan experiencia con ellos. Otro hecho a tener en cuenta es que una vez realizada una aplicación web para uso interno de una empresa, por ejemplo en una intranet, el poner esa funcionalidad, o incluso funcionalidades nuevas, a disposición de empleados o el público general tiene un coste mínimo a la vez que una potencial proyección mundial.

Aplicaciones en capas

La estrategia tradicional de utilizar aplicaciones compactas causa gran cantidad de problemas de integración en sistemas de aplicaciones complejos como pueden ser los sistemas de gestión de una empresa o los sistemas de información integrados consistentes en más de una aplicación. Estas aplicaciones suelen encontrarse con importantes problemas de escalabilidad, disponibilidad, seguridad e integración. Para solventar estos problemas se ha generalizado la división de las aplicaciones en capas que normalmente serán tres: una capa que servirá para guardar los datos (base de datos), una capa para centralizar la lógica de negocio (modelo) y por último una interfaz gráfica que facilite al usuario el uso del sistema (presentación).

Figura 1.1. Arquitectura tradicional en tres capas.

Si se establece una separación entre la capa de interfaz gráfica (cliente), replicada en cada uno de los entornos de usuario, y la capa del modelo, que quedaría centralizada en un servidor de aplicaciones, según el diagrama que podemos ver en la Figura 1.1, obtenemos una potente arquitectura que otorga algunas ventajas:

Centralización de los aspectos de seguridad y transaccionalidad, que serían responsabilidad del modelo.
No replicación de lógica de negocio en los clientes: esto permite que las modificaciones y mejoras sean automáticamente aprovechadas por el conjunto de los usuarios, reduciendo los costes de mantenimiento.
Mayor sencillez de los clientes.

Si intentamos aplicar esto a las aplicaciones web, debido a la obligatoria sencillez del software cliente que será un navegador web, nos encontramos con una doble posibilidad:
Crear un modelo de cuatro capas, separando cliente, servidor web, modelo y almacén de datos. Esto permite una mayor extensibilidad en caso de que existan también clientes no web en el sistema, que trabajarían directamente contra el servidor del modelo.
Sin embargo, la gran mayoría de las aplicaciones web comunes utilizan una arquitectura basada en la de tres capas extendida a las particularidades de la web.

Figura 1.2. Arquitectura web en tres capas

La arquitectura MVC

La arquitectura Model-View-Controller surgió como patrón arquitectónico para el desarrollo de interfaces gráficas de usuario en entornos Smalltalk. Su concepto se basaba en separar el modelo de datos de la aplicación de su representación de cara al usuario y de la interacción de éste con la aplicación, mediante la división de la aplicación en tres partes fundamentales:

El modelo, que contiene la lógica de negocio de la aplicación
La vista, que muestra al usuario la información que éste necesita.
El controlador, que recibe e interpreta la interacción del usuario, actuando sobre modelo y vista de manera adecuada para provocar cambios de estado en la representación interna de los datos, así como en su visualización.

Esta arquitectura ha demostrado ser muy apropiada para las aplicaciones web y especialmente adaptarse bien a las tecnologías proporcionadas por la plataforma J2EE, de manera que:

1. El modelo, que contiene la lógica de negocio, sería modelado por un conjunto de clases Java, existiendo dos claras alternativas de implementación, utilizando objetos java tradicionales llamados POJOs (Plain Old Java Objects) o bien utilizando EJB (Enterprise JavaBeans) en sistemas con unas mayores necesidades de concurrencia o distribución.

2. La vista proporcionará una serie de páginas web dinámicamente al cliente, siendo para él simples páginas HTML. Existen múltiples marcos de trabajo o frameworks que generan estas páginas web a partir de distintos formatos, siendo el más extendido el de páginas JSP (JavaServer Pages), que mediante un conjunto de tags XML proporcionan un interfaz sencillo y adecuado a clases Java y objetos proporcionados por el servidor de aplicaciones. Esto permite que sean sencillas de desarrollar por personas con conocimientos de HTML. Entre estos tags tienen mención especial la librería estándar JSTL (JavaServer Pages Standard Tag Library) que proporciona una gran funcionalidad y versatilidad.

3. El controlador en la plataforma J2EE se desarrolla mediante servlets, que hacen de intermediarios entre la vista y el modelo, más versátiles que los JSP para esta función al estar escritos como clases Java normales, evitando mezclar código visual (HTML, XML...) con código Java. Para facilitar la implementación de estos servlets también existe una serie de marcos de trabajo que proporcionan soporte a los desarrolladores, entre los que cabe destacar Struts, que con una amplia comunidad de usuarios se ha convertido en el estándar de facto en este rol.

Con todo lo anterior, el funcionamiento de una aplicación web J2EE que utilice el patrón arquitectural MVC se puede descomponer en una serie de pasos:

1. El usuario realiza una acción en su navegador, que llega al servidor mediante una petición HTTP y es recibida por un servlet (controlador). Esa petición es interpretada y se transforma en la ejecución de código java que delegará al modelo la ejecución de una acción de éste.
2. El modelo recibe las peticiones del controlador, a través de un interfaz o fachada que encapsulará y ocultará la complejidad del modelo al controlador. El resultado de esa petición será devuelto al controlador
3. El controlador recibe del modelo el resultado, y en función de éste, selecciona la vista que será mostrada al usuario, y le proporcionará los datos recibidos del modelo y otros datos necesarios para su transformación a HTML. Una vez hecho esto el control pasa a la vista para la realización de esa transformación.
4. En la vista se realiza la transformación tras recibir los datos del controlador, elaborando la respuesta HTML adecuada para que el usuario la visualice.

Esta arquitectura de aplicaciones otorga varias ventajas clave al desarrollo de aplicaciones web, destacando que:

Al separar de manera clara la lógica de negocio (modelo) de la vista permite la reusabilidad del modelo, de modo que la misma implementación de la lógica de negocio que maneja una aplicación pueda ser usado en otras aplicaciones, sean éstas web o no.
Permite una sencilla división de roles, dejando que sean diseñadores gráficos sin conocimientos de programación o desarrollo de aplicaciones los que se encarguen de la realización de la capa vista, sin necesidad de mezclar código Java entre el código visual que desarrollen (tan sólo utilizando algunos tags, no muy diferentes de los usados en el código HTML).

La plataforma Java

Java es el nombre de un entorno o plataforma de computación originaria de Sun Microsystems, capaz de ejecutar aplicaciones desarrolladas usando el Lenguaje de programación Java u otros lenguajes que compilen a bytecode y un conjunto de herramientas de desarrollo. En este caso, la plataforma no es un hardware específico o un sistema operativo, sino más bien una máquina virtual encargada de la ejecución de aplicaciones, y un conjunto de librerías estándar que ofrecen funcionalidad común.
La plataforma así llamada incluye:

Edición Estándar (Java Platform, Standard Edition), o Java SE (antes J2SE)
Plataforma Java, Edición Empresa (Java Platform, Enterprise Edition), o Java EE (antes J2EE)
Plataforma Java, Edición Micro (Java Platform, Micro Edition), o Java ME (antes J2ME)

Desde 2006, la versión actual de la Plataforma Java Standard Edition se le conoce como Java SE 6 como versión externa, y 1.6 como versión interna. Sin embargo, se prefiere el término versión 6.
La Plataforma Java se compone de un amplio abanico de tecnologías, cada una de las cuales ofrece una parte del complejo de desarrollo o del entorno de ejecución en tiempo real. Por ejemplo, los usuarios finales suelen interactuar con la máquina virtual de Java y el conjunto estándar de bibliotecas. Además, las aplicaciones Java pueden usarse de forma variada, como por ejemplo ser incrustadas en una página Web. Para el desarrollo de aplicaciones, se utiliza un conjunto de herramientas conocidas como JDK (Java Development Kit, o herramientas de desarrollo para Java).

Java Runtime Environment

Un programa destinado a la Plataforma Java necesita dos componentes en el sistema donde se va a ejecutar: una máquina virtual de Java (Java Virtual Machine, JVM), y un conjunto de librerías para proporcionar los servicios que pueda necesitar la aplicación. La JVM que proporciona Sun Microsystems, junto con su implementación de las librerías estándar, se conocen como Java Runtime Environment (JRE) o Entorno en tiempo de ejecución para Java. El JRE es lo mínimo que debe contener un sistema para poder ejecutar una aplicación Java sobre el mismo.
En el concepto de máquina virtual se encierra el concepto común de un procesador "virtual" que ejecuta programas escritos en el lenguaje de programación Java. En concreto, ejecuta el código resultante de la compilación del código fuente, conocido como bytecode. Este "procesador" es la máquina virtual de Java o JVM, que se encarga de traducir (interpretar o compilar al vuelo) el bytecode en instrucciones nativas de la plataforma destino. Esto permite que una misma aplicación Java pueda ser ejecutada en una gran variedad de sistemas con arquitecturas distintas, siempre que con una implementación adecuada de la JVM. Este hecho es lo que ha dado lugar a la famosa frase: "write once, run anywhere" (escriba una vez, ejecute en cualquier parte). La condición es que no se utilicen llamadas nativas o funciones especificas de una plataforma y aún así no se asegura completamente que se cumpla una verdadera independencia de plataforma.
Desde la versión 1.2 de JRE, la implementación de la máquina virtual de Sun incluye un compilador JIT (Just In Time). De esta forma, en vez de la tradicional interpretación del código bytecode, que da lugar a una ejecución lenta de las aplicaciones, el JIT convierte el bytecode a código nativo de la plataforma destino. Esta segunda compilación del código penaliza en cuanto a tiempo, pero el código nativo resultante se ejecuta de forma más eficaz y rápida que si fuera interpretado. Otras técnicas de compilación dinámica del código durante el tiempo de ejecución permiten optimizar más aún el código, dejando atrás el estigma que caía sobre Java en cuanto a su lentitud y en sus últimas versiones la JVM se ha optimizado a tal punto que ya no se considera una plataforma lenta en cuanto a ejecución de aplicaciones.
Java no fue la primera plataforma basada en el concepto de una máquina virtual, aunque es la que de más amplia difusión ha gozado. El empleo de máquinas virtuales se había centrado principalmente en el uso de emuladores para ayudar al desarrollo de hardware en construcción o sistemas operativos, pero la JVM fue diseñada para ser implementada completamente en software, y al mismo tiempo hacer que fuera portable a todo tipo de hardware.

Librerías de Java

En la mayoría de los sistemas operativos actuales, se ofrece una cantidad de código para simplificar la tarea de programación. Este código toma la forma, normalmente, de un conjunto de librerías dinámicas que las aplicaciones pueden llamar cuando lo necesiten. Pero la Plataforma Java está pensada para ser independiente del sistema operativo subyacente, por lo que las aplicaciones no pueden apoyarse en funciones dependientes de cada sistema en concreto. Lo que hace la Plataforma Java, es ofrecer un conjunto de libererías estándar, que contiene mucha de las funciones reutilizables disponibles en los sistemas operativos actuales.
Las librerías de Java tienen tres propósitos dentro de la Plataforma Java. Al igual que otras librerías estándar, ofrecen al programador un conjunto bien definido de funciones para realizar tareas comunes, como manejar listas de elementos u operar de forma sofisticada sobre cadenas de caracteres. Además, las librerías proporcionan una interfaz abstracta para tareas que son altamente dependientes del hardware de la plataforma destino y de su sistema operativo. Tareas tales como manejo de las funciones de red o acceso a ficheros, suelen depender fuertemente de la funcionalidad nativa de la plataforma destino. En el caso concreto anterior, las librerías java.net y java.io implementan el código nativo internamente, y ofrecen una interfaz estándar para que aplicaciones Java puedan ejecutar tales funciones. Finalmente, no todas las plataformas soportan todas las funciones que una aplicación Java espera. En estos casos, las librerías bien pueden emular esas funciones usando lo que esté disponible, o bien ofrecer un mecanismo para comprobar si una funcionalidad concreta está presente.

Lenguaje de programación Java

La palabra Java, por sí misma, se refiere habitualmente al lenguaje de programación Java, que fue diseñado para usar con la Plataforma Java. Los lenguajes de programación se encuentran fuera del ámbito de lo que es una "plataforma", aunque el lenguaje de programación Java es uno de los componentes fundamentales de la propia plataforma. El propio lenguaje y el entorno en tiempo de ejecución suelen considerarse una única entidad.

Marcos de trabajo en Java

Lo novedoso de las tecnologías usadas es uno de los puntos fuertes de este proyecto. Todas ellas son tecnologías Java de código abierto. El aprendizaje y familiarización ha ocupado la mayor parte del tiempo del proyecto. A continuación se describen los marcos de trabajo utilizados para el desarrollo de la aplicación
Spring
Spring es un marco de trabajo de aplicaciones Java/J2EE desarrollado por Rod Jonson, Juergen Hoeller, Justin Gehtland y Bruce A. Tate.
Spring proporciona:

Una potente gestión de configuración basada en JavaBeans, aplicando los principios de Inversión de Control (IoC). Esto hace que la configuración de aplicaciones sea rápida y sencilla. Ya no es necesario tener singletons ni ficheros de configuración, una aproximación consistente y elegante. Esta factoría de beans puede ser usada en cualquier entorno, desde applets hasta contenedores J2EE. Estas definiciones de beans se realizan en lo que se llama el contexto de aplicación.
Una capa genérica de abstracción para la gestión de transacciones, permitiendo gestores de transacción enchufables (pluggables), y haciendo sencilla la demarcación de transacciones sin tratarlas a bajo nivel. Se incluyen estrategias genéricas para JTA y un único JDBC DataSource. En contraste con el JTA simple o EJB CMT, el soporte de transacciones de Spring no está atado a entornos J2EE.
Una capa de abstracción JDBC que ofrece una significativa jerarquía de excepciones (evitando la necesidad de obtener de SQLException los códigos que cada gestor de base de datos asigna a los errores), simplifica el manejo de errores, y reduce considerablemente la cantidad de código necesario.
Integración con Hibernate, JDO e iBatis SQL Maps en términos de soporte a implementaciones DAO y estrategias con transacciones. Especial soporte a Hibernate añadiendo convenientes características de IoC, y solucionando muchos de los comunes problemas de integración de Hibernate. Todo ello cumpliendo con las transacciones genéricas de Spring y la jerarquía de excepciones DAO.
Funcionalidad basada en Programación orientada a aspectos (AOP), totalmente integrada en la gestión de configuración de Spring. Se puede aplicar AOP a cualquier objeto gestionado por Spring, añadiendo aspectos como gestión de transacciones declarativa. Con Spring se puede tener gestión de transacciones declarativa sin EJB, incluso sin JTA, si se utiliza una única base de datos en un contenedor web sin soporte JTA.
Un marco de trabajo MVC (Model-View-Controller), construido sobre el núcleo de Spring. Este marcod de trabajo es altamente configurable a través de interfaces y permite el uso de múltiples tecnologías para la capa vista como pueden ser JSP, Velocity, Tiles, iText o POI. De cualquier manera una capa modelo realizada con Spring puede ser fácilmente utilizada con una capa web basada en cualquier otro framework MVC, como Struts, WebWork o Tapestry.

Toda esta funcionalidad puede usarse en cualquier servidor J2EE, y la mayoría de ella ni siquiera requiere su uso. El objetivo central de Spring es permitir que objetos de negocio y de acceso a datos sean reusables, no atados a servicios J2EE específicos. Estos objetos pueden ser reutilizados tanto en entornos J2EE (web o EJB), aplicaciones standalone, entornos de pruebas,... sin ningún problema.
La arquitectura en capas de Spring (Figura 1.3) ofrece gran flexibilidad. Toda la funcionalidad está construida sobre los niveles inferiores. Por ejemplo se puede utilizar la gestión de configuración basada en JavaBeans sin utilizar el marco de trabajo MVC o el soporte AOP.

Figura 1.3. Arquitectura en capas de Spring

Hibernate
Hibernate es un potente mapeador objeto/relacional y servicio de consultas para Java. Es la solución ORM (Object-Relational Mapping) más popular en el mundo Java.
Hibernate permite desarrollar clases persistentes a partir de clases comunes, incluyendo asociación, herencia, polimorfismo, composición y colecciones de objetos. El lenguaje de consultas de Hibernate HQL (Hibernate Query Language), diseñado como una mínima extensión orientada a objetos de SQL, proporciona un puente elegante entre los mundos objetual y relacional. Hibernate también permite expresar consultas utilizando SQL nativo o consultas basadas en criterios.
Soporta todos los sistemas gestores de bases de datos SQL y se integra de manera elegante y sin restricciones con los más populares servidores de aplicaciones J2EE y contenedores web, y por supuesto también puede utilizarse en aplicaciones standalone.
Características clave:

Persistencia transparente

Hibernate puede operar proporcionando persistencia de una manera transparente para el desarrollador.

Modelo de programación natural

Hibernate soporta el paradigma de orientación a objetos de una manera natural: herencia, polimorfismo, composición y el marco de trabajo de colecciones de Java.

Soporte para modelos de objetos con una granularidad muy fina

Permite una gran variedad de mapeos para colecciones y objetos dependientes.

Sin necesidad de mejorar el código compilado (bytecode)

No es necesaria la generación de código ni el procesamiento del bytecode en el proceso de compilación.

Escalabilidad extrema

Hibernate posee un alto rendimiento, tiene una caché de dos niveles y puede ser usado en un cluster. Permite inicialización perezosa (lazy) de objetos y colecciones.

Lenguaje de consultas HQL

Este lenguaje proporciona una independencia del SQL de cada base de datos, tanto para el almacenamiento de objetos como para su recuperación.

Soporte para transacciones de aplicación

Hibernate soporta transacciones largas (aquellas que requieren la interacción con el usuario durante su ejecución) y gestiona la política optimistic locking automáticamente.

Generación automática de claves primarias

Soporta los diversos tipos de generación de identificadores que proporcionan los sistemas gestores de bases de datos (secuencias, columnas autoincrementales,...) así como generación independiente de la base de datos, incluyendo identificadores asignados por la aplicación o claves compuestas.
Java Server Pages
Es una tecnología Java que permite generar contenido dinámico para web, en forma de documentos HTML, XML o de otro tipo. Es un desarrollo de la compañía Sun Microsystems. La Especificación JSP 1.2 fue la primera que se liberó y en la actualidad está disponible la especificación JSP 2.1.
Permiten la utilización de código Java mediante scripts y permite la utilización de algunas acciones JSP predefinidas mediante etiquetas. Estas etiquetas pueden ser enriquecidas mediante la utilización de Librerías de Etiquetas (TagLibs o Tag Libraries) externas e incluso personalizadas.
JSP puede considerarse como una manera alternativa, y simplificada, de construir servlets. Es por ello que una página JSP puede hacer todo lo que un servlet puede hacer, y viceversa. El funcionamiento general de la tecnología JSP es que el Servidor de Aplicaciones interpreta el código contenido en la página JSP para construir el código Java del servlet a generar. Este será luego el que genere el documento (típicamente HTML) que se presentará en la pantalla del Navegador del usuario.
El rendimiento de una página JSP es el mismo que tendría el servidor equivalente, ya que el código es compilado como cualquier otra clase Java. A su vez, la máquina virtual compilará dinámicamente a código de máquina las partes de la aplicación que lo requieran. Esto hace que JSP tenga un buen desempeño y sea más eficiente que otras tecnologías web que ejecutan el código de una manera puramente interpretada.
La principal ventaja de JSP frente a otros lenguajes es que el lenguaje Java es un lenguaje de propósito general que excede el mundo web y que es apto para crear clases que manejen lógica de negocio y acceso a datos de una manera prolija. Esto permite separar en niveles las aplicaciones web, dejando la parte encargada de generar el documento HTML en el archivo JSP.
Otra ventaja es que JSP hereda la portabilidad de Java, y es posible ejecutar las aplicaciones en múltiples plataformas sin cambios. Es común incluso que los desarrolladores trabajen en una plataforma y que la aplicación termine siendo ejecutada en otra.
Java Server Faces
Es un marco de trabajo para aplicaciones Java basadas en web que simplifica el desarrollo de intrefaces de usuario en aplicaciones Java EE. Usa Java Server Pages (JSP) como la tecnología que permite hacer el despliegue de las páginas, pero también se puede acomodar a otras tecnologías.
Su implementación incluye:

Un conjunto de APIs para representar componentes de una interfaz de usuario y administrar su estado, manejar eventos, validar entrada, definir un esquema de navegación de las páginas y dar soporte para internacionalización y accesibilidad.
Un conjunto por defecto de componentes para la interfaz de usuario.
Dos librerías de etiquetas personalizadas para JavaServer Pages que permiten expresar una interfaz JavaServer Faces dentro de una página JSP.
Un modelo de eventos en el lado del servidor.
Administración de estados.
Beans administrados.

La especificación de JSF fue desarrollada por la Java Community Process.
Richfaces
Es una biblioteca de componentes para JSF y un avanzado marco de trabajo para la integración de AJAX con facilidad en la capacidad de desarrollo de aplicaciones de negocio. Los componentes de RichFaces vienen listos para ser usados de manera rápida y sencilla, por lo que los desarrolladores pueden ahorrar tiempo de inmediato para aprovechar las características de los componentes para crear aplicaciones Web que proporcionan mejoras en gran medida la experiencia del usuario. RichFaces también incluye un fuerte apoyo para el tratamiento de temas visuales (skins) en las aplicaciones JSF. También aprovecha al máximo los beneficios del marco de trabajo JSF incluyendo, la validación y conversión de instalaciones, junto con la gestión de estática y dinámica los recursos.
Es una biblioteca de código abierto que se integra totalmente en la arquitectura de JSF y hereda las funcionalidades de sus etiquetas dotándolas con tecnología Ajax de forma limpia y sin añadir código Javascript. Mediante este marco de trabajo se puede variar el ciclo de vida de una petición JSF, recargar determinados componentes de la página sin necesidad de recargarla por completo, realizar peticiones al servidor automáticas y controlar cualquier evento de usuario.
El funcionamiento de la herramienta es muy sencillo. Mediante sus propias etiquetas se generan eventos que envían peticiones al contenedor Ajax. Estos eventos se pueden ejecutar por pulsar un botón, un enlace, una región específica de la pantalla, un cambio de estado de un componente, etc. Esto significa que el desarrollador no tiene que preocuparse de crear el código Javascript y el objeto XMLHttpRequest para que envíe la petición al servidor ya que el marco de trabajo hace el trabajo.
Una etiqueta especial del marco de trabajo es Ajax4jsf que se usa para activar las funcionalidades de Ajax dentro de la aplicación. Los tags de Richfaces se pueden acceder mediante el tag , como por ejemplo (para hacer una lista desplegable editable o , para visualizar datos en un componente tipo rejilla (grid)
Facelets
Es un sistema de plantillas, que sirve para integrar las partes estaticas de la aplicación web dentro del contenido dinámico. El problema de esta herramienta para JSF es la poca integración que tiene con otros marcos de trabajo, uno de ellos es Spring Security 2.0, que no dispone de etiquetas para trabajarlo. Las plantillas deben ser nombradas con la extensión .xhtml y su uso es muy sencillo.
Spring AOP
La Programación Orientada a Aspectos, más conocida como AOP por su nombre en inglés Aspect Oriented Programming, es un modelo de programación que aborda un problema específico: capturar las partes de un sistema que los modelos de programación habituales obligan a que estén repartidos a lo largo de distintos módulos del sistema. Estos fragmentos que afectan a distintos módulos son llamados aspectos y los problemas que solucionan, problemas cruzados (crosscutting concerns).
Usando un lenguaje que soporte AOP, podemos capturar estas dependencias en módulos individuales, obteniendo un sistema independiente de ellos y podemos utilizarlos o no sin tocar el código del sistema básico, preservando la integridad de las operaciones básicas.
Los principales campos de aplicación de la AOP son:

rastreo de la ejecución (tracing)
medida de tiempos y optimización (profiling)
pruebas (testing)

Spring AOP es uno de los marcos de trabajo existentes para implantar la programación orientada a aspectos.
Spring Security
Proporciona servicios de seguridad dentro de Spring. Proporciona un sistema de autenticación a través del cual los usuarios pueden autenticarse y acceder a múltiples aplicaciones a través de un único punto de entrada. Para ello utiliza el servicio de autenticación CAS (Central Authentication Service) desarrollado por la Universidad de Yale [CAS], con el que una aplicación puede participar en un entorno single sign on a nivel de toda la empresa. Ya no es necesario que cada aplicación tenga su propia base de datos de autenticación, ni tampoco existe la restricción de que sólo se pueda utilizar dentro del mismo servidor de aplicaciones. Otras características avanzadas que proporciona son soporte para proxy y refrescamiento forzado de logins. Tiene completa integración con Spring, utiliza los propios mecanismos de configuración de Spring y asegura la seguridad a nivel de instancia de objetos del dominio. En muchas aplicaciones es deseable definir listas de control de acceso (Access Control Lists o ACLs) para instancias de objetos del dominio individuales. Spring Security proporciona un completo paquete ACL con características que incluyen máscaras de bits, herencia de permisos, un repositorio utilizando JDBC, caché y un diseño pluggable utilizando interfaces.
Spring Security también implementa la protección de las peticiones HTTP. Ya no es necesario depender de restricciones de seguridad definidas en el fichero web.xml. Las peticiones HTTP pueden ser protegidas por una serie de expresiones regulares que definen expresiones de caminos de acceso, así como para la autenticación, autorización y gestores de reemplazo de credenciales para la ejecución como otro usuario, todo ello totalmente configurable.
Además, el sistema de seguridad puede redirigir automáticamente las peticiones a un canal de transmisión adecuado. Comúnmente esto se aplica para asegurar que las páginas seguras estarán sólo disponibles sobre HTTPS, y las páginas públicas sobre HTTP, aunque es suficientemente flexible para soportar cualquier tipo de requisitos de "canal".

Conclusiones

Las tecnologías modernas y el avance en la programación orientada a objetos, aspectos y a servicios, o sea llámese, diferentes perspectivas de abordar el tema unido al creciente auge de Internet hace que las aplicaciones del presente y del futuro se orienten cada vez más a la web y al mundo de Internet, por varias razones: facilidad de uso, necesidad de pocas prestaciones de hardware y software para manipular tal aplicación y otras.
Dentro de este mundo, las tecnologías de desarrollo y programación de software han evolucionado a paso rápido y Java, una herramienta de gran expansión mundial y que cuenta con una inmensa comunidad de desarrolladores no está exenta de proponer muchas variantes y alternativas válidas para realizar aplicaciones de este tipo. La curva de aprendizaje y sobre todo el ensamblaje de todas estas tecnologías resulta ser algo que requiere de manos expertas y conocedoras del tema pero una vez que se logran establecer los marcos de trabajo y las herramientas se configuran para su buen uso y trabajo, la programación con Java orientado a aplicaciones web resulta ser algo relativamente sencillo y práctico y se convierte en una herramienta de trabajo muy útil para el desarrollo de aplicaciones.

Bibliografía utilizada

Agüero, Martín. Introducción a Spring Framework. UP: Universidad de Palermo. Facultad de Ingeniería. [En línea] octubre de 2007. [Citado el: 31 de abril de 2009.] http://www.palermo.edu/ingenieria/downloads/introduccion_spring_framework_v1.0.pdf. version 1.0.
Albin, Stephen. The Art of Software Architecture: Design methods and techniques. Nueva YorkÂ ; Wiley, 2003.
Alur, D.; Crupi, J. y Malks, D. Core J2EE Patterns, Best Practices and Design Strategies. . s.l. ; Pretince Hall, 2001.
Bagüés, Ramiro Lago. Proactiva Calidad - Framework Spring. [En línea] mayo de 2009. [Citado el: 1 de junio de 2009.] http://www.proactiva-calidad.com/java/spring/index.html.
Bosch, Jan. 2000. Design and use of Software Architecture. s.l.Â ; Addison-Wesley, 2000.
Campo, Miguel Ángel Manzanedo del, y otros. UBU - Guía de Iniciación al Lenguaje Java. [En línea] Universidad de Burgos , 19 de septiembre de 1999. [Citado el: 25 de mayo de 2009.] http://pisuerga.inf.ubu.es/lsi/Invest/Java/Tuto/Index.htm.
Fielding, Roy Thomas ; Taylor, Richard. Principled design of the modern Web architecture. s.l.Â ; ACM Transactions on Internet Technologies, 2002. 2(2), pp. 115-150.
García, Sergio Campos. Hibernate. [En línea]. [Citado el: 14 de abril de 2009.] http://md2.dei.inf.uc3m.es:8000/PA/Practicas/Exposiciones%20(2006)/Hibernate.ppt
Marañón, Gonzalo Álvarez. Departamento de Tratamiento de la Información y Codificación - Qué es Java? [En línea] [Citado el: 26 de mayo de 2009.] http://www.iec.csic.es/CRIPTONOMICON/java/funcionamiento.html.
Microsystem, Sun. Java en Castellano. [En línea] [Citado el: 17 de marzo de 2009.] http://www.programacion.net/java/tutorial/patrones2/0/.
MyFaces. MyFaces Apache. [En línea] [Citado el: 11 de mayo de 2009.] http://myfaces.apache.org/index.html.
Ajax4JSF. MyFaces Apache. [En línea]. [Citado el: 1 de junio de 2009.] http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=Ajax4Jsf
Spring – Wikipedia.[En línea]. [Citado el: 26 de mayo de 2009.] http://es.wikipedia.org/wiki/Spring
JSP – Wikipedia [En línea]. [Citado el: 29 de mayo de 2009.]

http://es.wikipedia.org/wiki/JSP

jGuru: JavaServer Pages Fundamentals, Short Course Contents

noreply@blogger.com (littlebitz) — Thu, 13 Oct 2011 14:15:00 +0000

Course Outline

Introduction

Directives

Request Chaining

Including Requests

Introduction

While there are numerous technologies for building web applications that serve dynamic content, the one that has really caught the attention of the development community is JavaServer Pages (JSP). And not without ample reason either. JSP not only enjoys cross-platform and cross-Web-server support, but effectively melds the power of server-side Java technology with the WYSIWYG features of static HTML pages.
JSP pages typically comprise of:

Static HTML/XML components.
Special JSP tags
Optionally, snippets of code written in the Java programming language called "scriptlets."

Consequently, you can create and maintain JSP pages by conventional HTML/XML tools.
It is important to note that the JSP specification is a standard extension defined on top of the Servlet API. Thus, it leverages all of your experience with servlets.
There are significant differences between JSP and servlet technology. Unlike servlets, which is a programmatic technology requiring significant developer expertise, JSP appeals to a much wider audience. It can be used not only by developers, but also by page designers, who can now play a more direct role in the development life cycle.
Another advantage of JSP is the inherent separation of presentation from content facilitated by the technology, due its reliance upon reusable component technologies like the JavaBeans component architecture and Enterprise JavaBeans technology. This course provides you with an in-depth introduction to this versatile technology, and uses the Tomcat JSP 1.1 Reference Implementation from the Apache group for running the example programs.

JSP Advantages

Separation of static from dynamic content: With servlets, the logic for generation of the dynamic content is an intrinsic part of the servlet itself, and is closely tied to the static presentation templates responsible for the user interface. Thus, even minor changes made to the UI typically result in the recompilation of the servlet. This tight coupling of presentation and content results in brittle, inflexible applications. However, with JSP, the logic to generate the dynamic content is kept separate from the static presentation templates by encapsulating it within external JavaBeans components. These are then created and used by the JSP page using special tags and scriptlets. When a page designer makes any changes to the presentation template, the JSP page is automatically recompiled and reloaded into the web server by the JSP engine.
Write Once Run Anywhere: JSP technology brings the "Write Once, Run Anywhere" paradigm to interactive Web pages. JSP pages can be moved easily across platforms, and across web servers, without any changes.
Dynamic content can be served in a variety of formats: There is nothing that mandates the static template data within a JSP page to be of a certain format. Consequently, JSP can service a diverse clientele ranging from conventional browsers using HTML/DHTML, to handheld wireless devices like mobile phones and PDAs using WML, to other B2B applications using XML.
Recommended Web access layer for n-tier architecture: Sun's J2EE Blueprints, which offers guidelines for developing large-scale applications using the enterprise Java APIs, categorically recommends JSP over servlets for serving dynamic content.
Completely leverages the Servlet API: If you are a servlet developer, there is very little that you have to "unlearn" to move over to JSP. In fact, servlet developers are at a distinct advantage because JSP is nothing but a high-level abstraction of servlets. You can do almost anything that can be done with servlets using JSP--but more easily!

Comparing JSP with ASP

Although the features offered by JSP may seem similar to that offered by Microsoft's Active Server Pages (ASP), they are fundamentally different technologies, as shown by the following table:

	JavaServer Pages	Active Server Pages
Web Server Support	Most popular web servers including Apache, Netscape, and Microsoft IIS can be easily enabled with JSP.	Native support only within Microsoft IIS or Personal Web Server. Support for select servers using third-party products.
Platform Support	Platform independent. Runs on all Java-enabled platforms.	Is fully supported under Windows. Deployment on other platforms is cumbersome due to reliance on the Win32-based component model.
Component Model	Relies on reusable, cross-platform components like JavaBeans, Enterprise JavaBeans, and custom tag libraries.	Uses the Win32-based COM component model.
Scripting	Can use the Java programming language or JavaScript.	Supports VBScript and JScript for scripting.
Security	Works with the Java security model.	Can work with the Windows NT security architecture.
Database Access	Uses JDBC for data access.	Uses Active Data Objects for data access.
Customizable Tags	JSP is extensible with custom tag libraries.	Cannot use custom tag libraries and is not extensible.

JSP or Servlets?

It is true that both servlets and JSP pages have many features in common, and can be used for serving up dynamic web content. Naturally, this may cause some confusion as to when to opt for one of the technologies over the other. Luckily, Sun's J2EE Blueprints offers some guidelines towards this.
According to the Blueprints, use servlets strictly as a web server extension technology. This could include the implementation of specialized controller components offering services like authentication, database validation, and so forth. It is interesting to note that what is commonly known as the "JSP engine" itself is a specialized servlet running under the control of the servlet engine. Since JSP only deals with textual data, you will have to continue to use servlets when communicating with Java applets and applications.
Use JSP to develop typical web applications that rely upon dynamic content. JSP should also be used in place of proprietary web server extensions like server-side includes as it offers excellent features for handling repetitive content.

Exercise

Installing and Configuring Tomcat

JSP Architecture

The purpose of JSP is to provide a declarative, presentation-centric method of developing servlets. As noted before, the JSP specification itself is defined as a standard extension on top the Servlet API. Consequently, it should not be too surprisingly that under the covers, servlets and JSP pages have a lot in common.
Typically, JSP pages are subject to a translation phase and a request processing phase. The translation phase is carried out only once, unless the JSP page changes, in which case it is repeated. Assuming there were no syntax errors within the page, the result is a JSP page implementation class file that implements the Servlet interface, as shown below.

The translation phase is typically carried out by the JSP engine itself, when it receives an incoming request for the JSP page for the first time. Note that the JSP 1.1 specification also allows for JSP pages to be precompiled into class files. Precompilation may be especially useful in removing the start-up lag that occurs when a JSP page delivered in source form receives the first request from a client. Many details of the translation phase, like the location where the source and class files are stored are implementation dependent. The source for the class file generated by Tomcat for this example JSP page (shown in the above figure) is as follows:

package jsp;  import javax.servlet.*; import javax.servlet.http.*; import javax.servlet.jsp.*; import javax.servlet.jsp.tagext.*; import java.io.PrintWriter; import java.io.IOException; import java.io.FileInputStream; import java.io.ObjectInputStream; import java.util.Vector; import org.apache.jasper.runtime.*; import java.beans.*; import org.apache.jasper.JasperException; import java.text.*; import  java.util.*;  public class _0005cjsp_0005cjsptest_0002ejspjsptest_jsp_0   extends HttpJspBase {   static {  }  public _0005cjsp_0005cjsptest_0002ejspjsptest_jsp_0( ) {  }   private static boolean _jspx_inited = false;  public final void _jspx_init() throws JasperException {  }   public void _jspService(HttpServletRequest request,     HttpServletResponse  response)       throws IOException, ServletException {       JspFactory _jspxFactory = null;      PageContext pageContext = null;      HttpSession session = null;      ServletContext application = null;      ServletConfig config = null;      JspWriter out = null;      Object page = this;      String  _value = null;      try {           if (_jspx_inited == false) {              _jspx_init();              _jspx_inited = true;          }          _jspxFactory = JspFactory.getDefaultFactory();          response.setContentType("text/html");          pageContext = _jspxFactory.getPageContext(this,           request,response, "", true, 8192, true);           application = pageContext.getServletContext();          config = pageContext.getServletConfig();          session = pageContext.getSession();          out = pageContext.getOut();          // begin          out.write("\r\n\r\n\r\n");         // end         // begin [file="E:\\jsp\\jsptest.jsp";from=(3,2);to=(5,0)]         Date d = new Date();         String today =  DateFormat.getDateInstance().format(d);         // end         // begin         out.write("\r\nToday is: \r\n ");         // end         // begin [file="E:\\jsp\\jsptest.jsp";from=(7,8);to=(7,13)]         out.print(today);         // end         // begin         out.write(" \r\n\r\n\r\n");         // end     } catch (Exception ex) {        if (out.getBufferSize() != 0)        out.clear();        pageContext.handlePageException(ex);     } finally {        out.flush();        _jspxFactory.releasePageContext(pageContext);     }   } }

The JSP page implementation class file extends HttpJspBase, which in turn implements the Servlet interface. Observe how the service method of this class, _jspService(), essentially inlines the contents of the JSP page. Although _jspService() cannot be overridden, the developer can describe initialization and destroy events by providing implementations for the jspInit() and jspDestroy() methods within their JSP pages.
Once this class file is loaded within the servlet container, the _jspService() method is responsible for replying to a client's request. By default, the _jspService() method is dispatched on a separate thread by the servlet container in processing concurrent client requests, as shown below:

JSP Access Models

The early JSP specifications advocated two philosophical approaches, popularly known as Model 1 and Model 2 architectures, for applying JSP technology. These approaches differ essentially in the location at which the bulk of the request processing was performed, and offer a useful paradigm for building applications using JSP technology.
Consider the Model 1 architecture, shown below:

In the Model 1 architecture, the incoming request from a web browser is sent directly to the JSP page, which is responsible for processing it and replying back to the client. There is still separation of presentation from content, because all data access is performed using beans.
Although the Model 1 architecture is suitable for simple applications, it may not be desirable for complex implementations. Indiscriminate usage of this architecture usually leads to a significant amount of scriptlets or Java code embedded within the JSP page, especially if there is a significant amount of request processing to be performed. While this may not seem to be much of a problem for Java developers, it is certainly an issue if your JSP pages are created and maintained by designers--which is usually the norm on large projects. Another downside of this architecture is that each of the JSP pages must be individually responsible for managing application state and verifying authentication and security.

The Model 2 architecture, shown above, is a server-side implementation of the popular Model/View/Controller design pattern. Here, the processing is divided between presentation and front components. Presentation components are JSP pages that generate the HTML/XML response that determines the user interface when rendered by the browser. Front components (also known as controllers) do not handle any presentation issues, but rather, process all the HTTP requests. Here, they are responsible for creating any beans or objects used by the presentation components, as well as deciding, depending on the user's actions, which presentation component to forward the request to. Front components can be implemented as either a servlet or JSP page.
The advantage of this architecture is that there is no processing logic within the presentation component itself; it is simply responsible for retrieving any objects or beans that may have been previously created by the controller, and extracting the dynamic content within for insertion within its static templates. Consequently, this clean separation of presentation from content leads to a clear delineation of the roles and responsibilities of the developers and page designers on the programming team. Another benefit of this approach is that the front components present a single point of entry into the application, thus making the management of application state, security, and presentation uniform and easier to maintain.

JSP Syntax Basics

JSP syntax is fairly straightforward, and can be classified into directives, scripting elements, and standard actions.

Directives

JSP directives are messages for the JSP engine. They do not directly produce any visible output, but tell the engine what to do with the rest of the JSP page. JSP directives are always enclosed within the <%@ ... %> tag. The two primary directives are page and include. (Note that JSP 1.1 also provides the taglib directive, which can be used for working with custom tag libraries, although this isn't discussed here.)

Page Directive

Typically, the page directive is found at the top of almost all of your JSP pages. There can be any number of page directives within a JSP page, although the attribute/value pair must be unique. Unrecognized attributes or values result in a translation error. For example,

<%@ page import="java.util.*, com.foo.*" buffer="16k" %>

makes available the types declared within the included packages for scripting and sets the page buffering to 16K.

Include Directive

The include directive lets you separate your content into more manageable elements, such as those for including a common page header or footer. The page included can be a static HTML page or more JSP content. For example, the directive:

<%@ include file="copyright.html" %>

can be used to include the contents of the indicated file at any location within the JSP page.

Declarations

JSP declarations let you define page-level variables to save information or define supporting methods that the rest of a JSP page may need. While it is easy to get led away and have a lot of code within your JSP page, this move will eventually turn out to be a maintenance nightmare. For that reason, and to improve reusability, it is best that logic-intensive processing is encapsulated as JavaBean components.
Declarations are found within the <%! ... %> tag. Always end variable declarations with a semicolon, as any content must be valid Java statements:

<%! int i=0; %>

You can also declare methods. For example, you can override the initialization event in the JSP life cycle by declaring:

<%! public void jspInit() {  //some initialization code      } %>

Expressions

With expressions in JSP, the results of evaluating the expression are converted to a string and directly included within the output page. Typically expressions are used to display simple values of variables or return values by invoking a bean's getter methods. JSP expressions begin within <%= ... %> tags and do not include semicolons:

 <%= fooVariable %>  <%= fooBean.getName() %>

Scriptlets

JSP code fragments or scriptlets are embedded within <% ... %> tags. This Java code is run when the request is serviced by the JSP page. You can have just about any valid Java code within a scriptlet, and is not limited to one line of source code. For example, the following displays the string "Hello" within H1, H2, H3, and H4 tags, combining the use of expressions and scriptlets:

<% for (int i=1; i<=4; i++) { %>     >Hello> <% } %>

Comments

Although you can always include HTML comments in JSP pages, users can view these if they view the page's source. If you don't want users to be able to see your comments, embed them within the <%-- ... --%> tag:

<%-- comment for server side only --%>

A most useful feature of JSP comments is that they can be used to selectively block out scriptlets or tags from compilation. Thus, they can play a significant role during the debugging and testing process.

Object Scopes

Before we look at JSP syntax and semantics, it is important to understand the scope or visibility of Java objects within JSP pages that are processing a request. Objects may be created implicitly using JSP directives, explicitly through actions, or, in rare cases, directly using scripting code. The instantiated objects can be associated with a scope attribute defining where there is a reference to the object and when that reference is removed. The following diagram indicates the various scopes that can be associated with a newly created object:

JSP Implicit Objects

As a convenience feature, the JSP container makes available implicit objects that can be used within scriptlets and expressions, without the page author first having to create them. These objects act as wrappers around underlying Java classes or interfaces typically defined within the Servlet API. The nine implicit objects:

request: represents the HttpServletRequest triggering the service invocation. Request scope.
response: represents HttpServletResponse to the request. Not used often by page authors. Page scope.
pageContext: encapsulates implementation-dependent features in PageContext. Page scope.
application: represents the ServletContext obtained from servlet configuration object. Application scope.
out: a JspWriter object that writes into the output stream. Page scope.
config: represents the ServletConfig for the JSP. Page scope.
page: synonym for the "this" operator, as an HttpJspPage. Not used often by page authors. Page scope.
session: An HttpSession. Session scope. More on sessions shortly.
exception: the uncaught Throwable object that resulted in the error page being invoked. Page scope.

Note that these implicit objects are only visible within the system generated _jspService() method. They are not visible within methods you define yourself in declarations.

Synchronization Issues

By default, the service method of the JSP page implementation class that services the client request is multithreaded. Thus, it is the responsibility of the JSP page author to ensure that access to shared state is effectively synchronized. There are a couple of different ways to ensure that the service methods are thread-safe. The easy approach is to include the JSP page directive:

<%@ page isThreadSafe="false" %>

This causes the JSP page implementation class to implement the SingleThreadModel interface, resulting in the synchronization of the service method, and having multiple instances of the servlet to be loaded in memory. The concurrent client requests are then distributed evenly amongst these instances for processing in a round-robin fashion, as shown below:

The downside of using this approach is that it is not scalable. If the wait queue grows due to a large number of concurrent requests overwhelming the processing ability of the servlet instances, then the client may suffer a significant delay in obtaining the response.
A better approach is to explicitly synchronize access to shared objects (like those instances with application scope, for example) within the JSP page, using scriptlets:

<% synchronized (application) {    SharedObject foo = (SharedObject)  application.getAttribute("sharedObject");    foo.update(someValue);    application.setAttribute("sharedObject",foo); } %>

Exception Handling

JSP provides a rather elegant mechanism for handling runtime exceptions. Although you can provide your own exception handling within JSP pages, it may not be possible to anticipate all situations. By making use of the page directive's errorPage attribute, it is possible to forward an uncaught exception to an error handling JSP page for processing. For example,

<%@ page isErrorPage="false" errorPage="errorHandler.jsp" %>

informs the JSP engine to forward any uncaught exception to the JSP page errorHandler.jsp. It is then necessary for errorHandler.jsp to flag itself as a error processing page using the directive:

<%@ page isErrorPage="true" %>

This allows the Throwable object describing the exception to be accessed within a scriptlet through the implicit exception object.

Exercise

Exception Handling in JSP

Session Management

By default, all JSP pages participate in an HTTP session. The HttpSession object can be accessed within scriptlets through the session implicit JSP object. Sessions are a good place for storing beans and objects that need to be shared across other JSP pages and servlets that may be accessed by the user. The session objects is identified by a session ID and stored in the browser as a cookie. If cookies are unsupported by the browser, then the session ID may be maintained by URL rewriting. Support for URL rewriting is not mandated by the JSP specification and is supported only within a few servers. Although you cannot place primitive data types into the session, you can store any valid Java object by identifying it by a unique key. For example:

<%  Foo foo = new Foo(); session.putValue("foo",foo); %>

makes available the Foo instance within all JSP pages and servlets belonging to the same session. The instance may be retrieved within a different JSP page as:

<% Foo myFoo = (Foo) session.getValue("foo"); %>

The call to session.getValue() returns a reference to the generic Object type. Thus it is important to always cast the value returned to the appropriate data type before using it. It is not mandatory for JSP pages to participate in a session; they may choose to opt out by setting the appropriate attribute of the page directive:

<%@ page session="false" %>

There is no limit on the number of objects you can store into the session. However, placing large objects into the session may degrade performance, as they take up valuable heap space. By default, most servers set the lifetime of a session object to 30 minutes, although you can easily reset it on a per session basis by invoking setMaxInvalidationInterval(int secs) on the session object. The figure below highlights the general architecture of session management:

The JSP engine holds a live reference to objects placed into the session as long as the session is valid. If the session is invalidated or encounters a session timeout, then the objects within are flagged for garbage collection.

Standard Actions

Actions allow you to perform sophisticated tasks like instantiating objects and communicating with server-side resources like JSP pages and servlets without requiring Java coding. Although the same can be achieved using Java code within scriptlets, using action tags promotes reusability of your components and enhances the maintainability of your application.

Using JavaBean Components

The component model for JSP technology is based on JavaBeans component architecture. JavaBeans components are nothing but Java objects which follow a well-defined design/naming pattern: the bean encapsulates its properties by declaring them private and provides public accessor (getter/setter) methods for reading and modifying their values.
Before you can access a bean within a JSP page, it is necessary to identify the bean and obtain a reference to it. The tag tries to obtain a reference to an existing instance using the specified id and scope, as the bean may have been previously created and placed into the session or application scope from within a different JSP page. The bean is newly instantiated using the Java class name specified through the class attribute only if a reference was not obtained from the specified scope. Consider the tag:

In this example, the Person instance is created just once and placed into the session. If this useBean tag is later encountered within a different JSP page, a reference to the original instance that was created before is retrieved from the session.
The tag can also optionally include a body, such as

 <%   user.setDate(DateFormat.getDateInstance(                        ).format(new Date()));   //etc.. %>

Any scriptlet (or tags, which are explained shortly) present within the body of a tag are executed only when the bean is instantiated, and are used to initialize the bean's properties.
Once you have declared a JavaBean component, you have access to its properties to customize it. The value of a bean's property is accessed using the tag. With the tag, you specify the name of the bean to use (from the id field of useBean), as well as the name of the property whose value you are interested in. The actual value is then directly printed to the output:

Changing the property of a JavaBean component requires you to use the tag. For this tag, you identify the bean and property to modify and provide the new value:

When developing beans for processing form data, you can follow a common design pattern by matching the names of the bean properties with the names of the form input elements. You also need to define the corresponding getter/setter methods for each property within the bean. The advantage in this is that you can now direct the JSP engine to parse all the incoming values from the HTML form elements that are part of the request object, then assign them to their corresponding bean properties with a single statement, like this:

This runtime magic is possible through a process called introspection, which lets a class expose its properties on request. The introspection is managed by the JSP engine, and implemented through the Java reflection mechanism. This feature alone can be a lifesaver when processing complex forms containing a significant number of input elements.
If the names of your bean properties do not match those of the form's input elements, they can still be mapped explicitly to your property by naming the parameter as:

Exercises

Understanding JSP object scope

Form processing using JSP

Forwarding Requests

With the tag, you can redirect the request to any JSP, servlet, or static HTML page within the same context as the invoking page. This effectively halts processing of the current page at the point where the redirection occurs, although all processing up to that point still takes place:

The invoking page can also pass the target resource bean parameters by placing them into the request, as shown in the diagram:

A tag may also have jsp:param subelements that can provide values for some elements in the request used in the forwarding:

Request Chaining

Request chaining is a powerful feature and can be used to effectively meld JSP pages and servlets in processing HTML forms, as shown in the following figure:

Consider the following JSP page, say Bean1.jsp, which creates a named instance fBean of type FormBean, places it in the request, and forwards the call to the servlet JSP2Servlet. Observe the way the bean is instantiated--here we automatically call the bean's setter methods for properties which match the names of the posted form elements, while passing the corresponding values to the methods.

The servlet JSP2Servlet now extracts the bean passed to it from the request, makes changes using the appropriate setters, and forwards the call to another JSP page Bean2.jsp using a request dispatcher. Note that this servlet, acting as a controller, can also place additional beans if necessary, within the request.

public void doPost (HttpServletRequest request,                       HttpServletResponse response) {   try {     FormBean f = (FormBean) request.getAttribute                                          ("fBean");      f.setName("Mogambo");      // do whatever else necessary     getServletConfig().getServletContext().       getRequestDispatcher("/jsp/Bean2.jsp").         forward(request, response);   } catch (Exception ex) {     . . .   } }

The JSP page Bean2.jsp can now extract the bean fBean (and whatever other beans that may have been passed by the controller servlet) from the request and extract its properties.

Including Requests

The tag can be used to redirect the request to any static or dynamic resource that is in the same context as the calling JSP page. The calling page can also pass the target resource bean parameters by placing them into the request, as shown in the diagram:

For example:

not only allows shoppingcart.jsp to access any beans placed within the request using a tag, but the dynamic content produced by it is inserted into the calling page at the point where the tag occurs. The included resource, however, cannot set any HTTP headers, which precludes it from doing things like setting cookies, or else an exception is thrown.

Web Sites

The following sites have product information as well as whitepapers on JSP and Servlets:

Hacer un texto que se adapta a un círculo, Photoshop

noreply@blogger.com (littlebitz) — Fri, 07 Oct 2011 01:15:00 +0000

Existen tutoriales complicados con técnicas para conseguir con Photoshop que un texto se adapte a una circunferencia. Esas técnicas eran necesarias de utilizar porque Photoshop no tenía una manera directa de hacer que un texto se adapte a un círculo o una curva en general. Ahora con CS2 es posible hacer esto y conseguir un texto editable que se adapta a un trazo. En este artículo haremos un círculo y el texto se escribirá siguiendo la circunferencia. Pero en realidad esto se puede hacer con cualquier tipo de trazo.
Primero creamos un archivo nuevo, en el que vamos a dibujar una circunferencia con la herramienta elipse. Esta circunferencia nos servirá para adaptar el texto que vamos a escribir más tarde.

Seleccionamos la mencionada herramienta elipse y dibujamos una circunferencia. El tamaño será el deseado. Pero para la prueba vamos a hacer una elipse suficientemente grande para trabajar con espacio.
En nuestra lista de capas tendremos el fondo y la elipse.

Entonces tomamos la herramienta de texto. Al situarnos sobre el lienzo, nuestro puntero se transforma en el típico cursor para mostrar que se va a insertar un texto (se muestra el típico puntero de texto, que es una línea vertical con una línea pequeña horizontal abajo y arriba). Si nos situamos con el puntero en la misma línea de la elipse veremos como el puntero se transforma en un cursor de texto especial, como el que podemos ver en la siguiente imagen:

En ese punto hacemos clic para empezar a escribir un texto. Veremos que el texto que vamos escribiendo se va colocando rodeando el círculo. Para ello, las letras se van adaptando al recorrido de la elipse. El resultado será algo como lo siguiente:

Seguramente tengamos que editar la posición del texto, para situarlo en un lado u otro del perímetro de la elipse. Esto lo tenemos que hacer con la herramienta de selección directa.

Ahora nos situamos con el puntero encima del texto. Veremos que el puntero se transforma como en un guión para escribir texto, en el que aparece al lado una flecha, apuntando a uno u otro lado del puntero. Entonces podemos pinchar y arrastrar para mover una guía para recolocar el texto dentro del trazado de la curva.
Si queremos, podemos conseguir así mover el texto para que se coloque siguiendo la curva, pero por la parte de dentro en lugar de la de fuera. Para ello simplemente habrá que arrastrar la posición de la guía para dentro, o fuera, del trazo.

Con esto tenemos nuestro texto alrededor de un círculo. Hay que señalar que este texto es perfectamente editable, por lo que fácilmente podremos cambiar el tamaño del texto, el color, la fuente, etc. Como cualquier otro texto simple de Photoshop. De esta manera conseguirmos adaptar el texto y que este sea totalmente editable.
La elipse luego podemos eliminarla o ocultarla para que no salga en la imagen. El trazado ahora queda asociado al texto, por lo que es indiferente lo que hagamos con la silueta de la elipse.

Esta es la manera más simple que existe de adaptar un texto a una circunferencia. Espero que haya sido sencillo de entender.
Ahora puedes ver un vídeo sobre este tutorial, que hemos preparado en DesarrolloWeb.com.

Facebook Launches New Metric:

noreply@blogger.com (littlebitz) — Mon, 03 Oct 2011 14:32:00 +0000

Facebook has overhauled its Pages Insights analytics tool and added a new metric to gauge the health of a page: “People Talking About.”

That statistic, which users will see on Pages below the total number of “Likes,” will be one of four tracked by Pages Insights. The idea is that users will understand a Page with a high People Talking About rating is one that has compelling content. Likewise, content creators will be motivated to make their Pages more comment-worthy.

People Talking About (that might not be the final name for the metric; at press time, Facebook wasn’t sure) will measure user-initiated activity related to a Page, including posting to a Page’s Wall, “liking,” commenting, sharing a Page post or content on the Page, answering a Question posed to fans, mentioning a Page, “liking” or sharing a deal or checking in at your Place.

The other metrics, which are designed for administrators of brand and media Pages, include “Likes,” “Friends of Fans” and “Weekly Total Reach.” While “Likes” is self-explanatory, Friends of Fans is the actual number of friends your fans have, and weekly total reach is designed to be an accurate assessment of how many total people have posted something about your Page, how many news organizations (within Facebook) have referenced it and how much viral distribution elements of your Page has gotten.

David Baser, product manager for Pages Insights, says that despite a raft of new activities that Facebook will be introducing soon under the Facebook Gestures banner, those four metrics will remain and the “Like” will maintain its ranking as a top measurement. “Likes are an expression of identity,” Baser says. “It’s a user saying that I have a relationship with this brand.”

In addition to tracking the four metrics, Pages Insights will also offer a deeper dive into data around specific updates. Facebook will list your last 500 posts (the company began tracking them in July) and count the total number of engaged users, People Talking About it and virality. The latter measures the percentage of users who commented on the post.

Sentiment, however, will not be part of the calculation. Whether a user is lauding a comment or trashing it, it will count the same.