Creo que en Linking hemos hecho muchas cosas bien (alguna mal también) en los dos años que llevamos, entre ellas el no obcecarnos ni renunciar a lo que realmente queríamos hacer. En Enero comenzó un proceso de reflexión que ha acabado con este fin, y es que de nada sirve una aventura si no te lleva dónde quieres ir.
Las circunstancias nos han llevado a vivir de proyectos en lugar de seguir la idea inicial de orientarnos a productos. Cosas que pasan. Vivir de proyectos (y de formación) ha resultado aceptablemente fácil para una empresa pequeña como la nuestra, pero es una rueda que no se puede parar, una rueda de la que no queremos formar parte porque no queremos ser una empresa más. Nos obliga a dejar demasiadas cosas a medias, como Examinia, The Tabula o incluso la locura de ApuestoQue. Y ya que estamos metidos en esto, queremos disfrutarlo al 100%.
Desde Febrero los clientes y los amigos conocen esta situación, los miembros de Linking desde Enero, este tiempo hemos ido cerrando cosas y el pasado día 30 de Abril cesamos la actividad oficialmente mientras preparamos lo que se podría considerar Linking Paths 2.0, porque no dudeis de que llegará. Es lo malo de que te entre este veneno empresarial.
Gracias a todos los que nos han apoyado en el pasado y sobre todo a quiénes han confiado en nosotros. Nos vemos. Pronto.

original

—–

La M de MVC, y la definición del patrón lo deja claro, debería entenderse como “modelo de negocio”. Es decir, tanto los datos como las acciones que se ejecutan sobre ellos. Es decir, no deberíamos en el controlador, por ejemplo una acción de Struts, realizar estas operaciones (por ejemplo: calcular los costes de envio de un pedido), sino que deberíamos convertir los datos de entrada, etc. para después llamar a la parte del modelo que se encarga de eso. Esta división, que es más o menos la que aparece en la figura, nos permite además aislar las distintas partes favoreciendo la reutilización, las pruebas, los cambios, etc.

original

—–

> Alberto Molpeceres escribió:
> Hola,
> Umm… no, no sé como se hacen los forward en Struts2 (pero la
> solución la has dado tú, es con el forward!), porque nunca he usado
> Struts2.
> Sobre spring…. bueno, no es complicado. Aunque aún no tengo claro
> que es lo mejor desde un punto de vista profesional (Struts2 o
> SpringMVC). Ha habido tanta confusión sobre Struts2, que simplemente
> me plantea dudas.

> On 4/4/07, xxxxx wrote:
> La teoría es esa, con el forward, el problema es que creo que cada vez
> que
> hago el submit en la jsp de marras vuelve a instanciar el Action que
> utilizo
> y donde tengo la colección de TOs que quiero mantener sin tener que volver
> a
> pedirla a Hibernate.
> Bueno, seguiré investigando, gracias de todos modos.

> Alberto Molpeceres escribió:
> Ah!.
> Nope, entonces no te había entendido .
> Pensaba que pasabas el control de una acción a otra en la misma
> petición. Si quieres hacer eso que comentas, tienes que usar la
> sesión, que para eso está. Struts es “famoso” de toda la vida por
> seguir la idea de “one-action-instance-per-request”.
> Umm… en serio, yo te recomendaría echarle un ojo al contenedor (y
> sólo al contenedor!) de spring, en esto te iba a ayduar “infinito”.

> On 4/4/07, xxxxx wrote:
> Ok, no quería guardarlo en sesión precisamente para que no se llene de
> datos descontroladamente y así no relentizar la aplicación.
> Recuerdo que con Struts 1.x, supongo que al tener los formularios en
> diferentes clases, podía acceder a los datos del formulario cada vez que
> llamaba al mismo action y continuaba ejecutando los forwards. Esto se debe
> haber perdido al fusionar el formulario y el action en Struts 2…
> empezamos
> bien… hehe.
> Seguiré tu consejo y me miraré el contenedor de spring.

> Alberto Molpeceres escribió:
> Hombre. Ya sabes que existen tres contextos: request, session y
> application, que es dónde se pueden dejar las cosas.
> Últimamente muchos frameworks (seam, myfaces, spring mvc, shale, etc)
> están incporporando un cuarto, llamado “diálogo” o “conversación”.
> Esta pensado para agrupar varias request en un contexto, pero sin
> llegar a ser la sesión. Vamos, por ejemplo, para hacer un wizard de
> tres pantallas. Espero haberme explicado.
> El de Spring se llama Webflow, y aunque no sé decirte que tal va,
> existe una integración para Struts2:
> http://cwiki.apache.org/S2PLUGINS/spring-webflow-plugin.html
> Ya me contarás. Si sale bien espero unas entradas en javaconganas!. Y si no
> sale, también, entradas en JCG!!!!!!.>
> al.
> On 4/4/07, xxxxx wrote:
> Ostras gracias, me miro el plugin enseguida a ver que tal va.
>

original

—–

otros por menos se han muerto

maneras de vivir.
Descuélgate del estante
y si te quieres venir
tengo una plaza vacante

maneras de vivir.

original

—–

original

—–

original

—–

detachable=”true”>
<field name=”id” primary-key=”true”
value-strategy=”increment”

dependent=”true”/>
<field name=”history”>
<collection element-type=”TaskChange”/>

</field>
<field name=”bugs”>
<collection element-type=”Bug” />

</field>
<field name=”workReports”>
<collection element-type=”WorkReport” />

<join />
</field>
<field name=”comments”>

<collection element-type=”Comment” />

<join />
</field>

<field name=”taskType” />

<field name=”status” default-fetch-group=”true”/>

<fetch-group name=”detailsPage”>
<field name=”taskType”/>

<field name=”status”/>

<field name=”bugs”/>
</fetch-group>

</class>
Esta es la definición de una clase Task, que tiene varias relaciones (los campos primitivos no hace falta definirlos si nos valen los valores por defecto). La parte interesante es la del final, la llamada fetch-group.
Y es que por defecto se cargan las relaciones de forma perezosa, como en casi todas partes (y por tanto tendríamos el mismo problema). En JDO podemos definir distintos fetch-groups, para distintos usos normales de la clase, definiendo que queremos que se cargue en esos casos. Por ejemplo, en este caso, cuando cargamos un grupo de Task para un listado, se cargará el grupo por defecto (primitivos + String + Date, pero no relaciones, salvo status porque así lo hemos definido), pero cuando queremos mostrar una página de detalle, nos interesa tener a mano información sobre el tipo de tarea que es (taskType), su estado (en este caso es un objeto, no un valor, status), o si tiene añadidos varios fallos (bugs). Dejamos sin cargar los partes de horas, historial de cambios, etc.
Simplemente a la hora de hacer la consulta haremos algo así como (escribo de memoria):
query.getFetchPlan().addFetchGroup(“detailsPage”);
Limpíto, ¿no?.

original

—–

Hace ya tiempo conocí Campfire, pero no ha sido hasta hace relativamente poco cuando lo he empezado a utilizar regularmente gracias a mi autodeclarado familiar, y hay que reconocer que es otra cosa. Una aplicación que de simple es ridícula, que cualquier informático podría hacer sin demasiados problemas, pero tiene algo que hace va más allá de la mensajería.
O quizás yo soy muy raro.

original

—–

original

—–

original

—–