Entradas

PHP en NetBeans 6.0

Imagen
PHP es un lenguaje de programación basado en scripts muy popular, fácil de aprender, de desplegar, es multiplataforma (igual que java, solo necesita de un programa que interprete el lenguaje para que lo convierta a la plataforma ya sea Linux, Windows o cualquiera), y sobretodo... es libre. No tiene un IDE específico, por lo que es necesario navegar por la documentación para recordar las sentencias... a menos que uno tenga buena memoria para recordarlas todas. Lo que está de moda en los IDEs es la coloración de sintaxis y el autollenado de sentencias. Existen varios IDEs que están apostando por este lenguaje que no es nada nuevo. Uno de ellos es CodeGear con su Delphi for PHP . Y Eclipse tiene un subproyecto que esta trabajando en un plugin para manejar PHP llamado PHP Development Tools . La gente de NetBeans - por su puesto - no se queda atrás. Por lo que en el NetBeans 6.0 han puesto a disposición un plugin (a la fecha de este post) en versión beta. Veremos como configurarlo, y ha

La caida de un grande - JBuilder

Yo era un consumidor de los productos Borland desde que existió Turbo Pascal 5.5. Con la venida de los Windows, Borland decidió subir un poco más de nivel evolucionando Turbo Pascal a Delphi que todas luces era mucho mejor que Visual Basic 3.0 (creo que fue por el año 1993) Tenía todo lo necesario para que fuese una aplicación completa para Win32: orientado a objetos, usa el API directo de Windows (sin ningún runtime como lo tiene Visual Basic), no sé.. era EL software para desarrollo de Windows. Pero perdió terreno porque le faltó a Borland lo que tiene (o lo que es) Microsoft: PUBLICIDAD. La mejor versión de Delphi fue la 7.0, aún hay gente que lo usa, y a pesar que Borland ya puesto todo su esfuerzo para poner a Delphi 2007 sobre cualquier versión previa... parece que no es suficiente. ¿Como pudieron los de Microsoft poner a el Visual Studio .Net sobre todo el studio 6.0? Simple... publicidad. Recuerdo también antes que saliera el Windows 95 (que decía ser de 32 bits, cuando rea

Tutorial: EJB 3.0 Enterprise Beans con NetBeans 5.5

Imagen
Uno de los puntos fuertes e importantes de programar con Java Enteprise es la centralización del código de negocio usando EJBs. De esta manera, cualquier aplicación (ya sea web o desde una aplicación cliente desktop) siempre tendrán la misma lógica. El problema era que hasta antes de la versión 3.0 de EJB la programación era realmente pesada. Aprender lo que eran los beans de sesión (con estado y sin estado), crear interfaces y usar clases como javax.ejb.SessionBean , codificando los archivos de despliegue (y que eran diferentes entre los diferentes contenedores como JBoss, Jonas, etc) y no sé que tanto más... era un lío. Personalmente no me apetecía aprenderlo... ni usando los IDE más sofisticados como NetBeans, JBuilder, JDevelopment... nada.. me quedaría programando en web y listo. Pero no pude huir fácilmente... aún la necesidad de utilizar un solo código de negocio para varias aplicaciones me rondaba. Hasta que salió el Java EE 5. Tuve mis dudas, pensé que sería lo mismo que ant

Spring + iBatis + DataSource

Este es un extracto de un .xml para Spring Framework que crea un DataSource y lo pone al iBatis para implementar DAO. <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd"> <!-- obtengo el .properties con las variables que tiene los datos de la conexion --> <bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"> <property name="locations"> <value>classpath:net/andesconsulting/resources/database.properties</value> </property> </bean> <!-- creo el datasource --> <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method=&

DBF 2 Java Library

He creado una biblioteca que maneja archivos DBF desde Java. Las funciones básicas que se puede hacer son: Abrir (claro está) archivos DBF, ya sea de Fox 2.x ó 3. Agrega registro en blanco Lee y escribe datos en los registros. Obtiene un registro Navega de registro en registro Obtiene los tipos de cada campo Se puede obtener la biblioteca aquí http://dbf2java-library.googlecode.com/ También se dispone del código fuente para descargar usando subversion. Ah! y está bajo licencia GNU General Public License v3 para quien quiera que desee colaborar, bienvenido sea. ¡ACTUALIZACIÓN! He mudado el proyecto a otro espacio. Más información aquí:  https://www.apuntesdejava.com/2015/05/dbf2java-library-mudado.html

El problema del AUTO_INCREMENT con el API de Persistencia

Al crear una clase entidad utilizando el API de persistencia (JPA) con Netbeans, el IDE creará por omisión los ID con las siguientes anotaciones @Id @GeneratedValue(strategy = GenerationType.AUTO) Con ello creará una tabla llamada SEQUENCE donde almacenará el valor del último ID utilizado. Es lo más estándar posible, ya que sabemos que existen RDBMS que no tienen la capacidad de generar un ID autoincrementado (como el Firebird, que necesita de un generator). Pero ¿si uso MySQL, Apache Derby (o un RDBMS que pueda permitir valores de ID autoincrementales)? Pues, si revisamos la documentación de Java http://java.sun.com/javaee/5/docs/api/javax/persistence/GenerationType.html#SEQUENCE dice textualmente " Indicates that the persistence provider must assign primary keys for the entity using database sequence column." entonces, la anotación que necesitamos es @GeneratedValue(strategy = GenerationType.SEQUENCE) Para salir de las dudas, al ejecutar nuestra aplicación, veremos

Persistencia de Java: Clave Primaria compleja con objeto

Como se vió, con el API de Persistencia de Java (Java Persistence API - JPA) se puede mapear todas las tablas de una base de datos como entidades para ser manipuladas desde objetos java. Ahora, ¿qué pasa con entidades débiles? Una entidad débil es aquella que depende su existencia de otra entidad. Por ejemplo, el detalle de una factura no puede existir sin una factura. Si se traslada este concepto a una base de datos, entonces, la clave primaria del detalle de factura será: la clave primaria de la factura a quien pertenece, y el número de orden que se muestra en la lista. Mapear la entidad FACTURA es simple: @Entity public class Factura implements Serializable { @Id @GeneratedValue(strategy = GenerationType.AUTO) @Column(name="ID_FACTURA") private Long id; La entidad DETALLE_FACTURA tiene la clave primaria compuesta por dos campos: ID_FACTURA y NRO_ORDEN. En java, toda la clave primara es un objeto con el mismo nombre de la clase primaria más el sufijo "PK". Pero ad