dimecres, 22 d’octubre del 2008

VALID_YEAR versió cakephp 1.2

Estic adaptant a la nova RC3 de cakephp una aplicació web realitzada per la versió 1.1 del framework i, aplicant les noves regles de validació en un model, m’he trobat amb un aspecte amb el que fins ara no m’hi havia topat. A la versió 1.1 hi havia 4 regles que ara estan marcades com a deprecated:

  • VALID_NOT_EMPTY
  • VALID_NUMBER
  • VALID_EMAIL
  • VALID_YEAR

L’equivalent de la primera amb la nova validació de la versió 1.2 és ‘notEmpty’, la segona ‘numeric’, la tercera ‘email’ i la quarta...ei! la quarta com?

La meva primera idea ha estat provar sense èxit amb la regla date

'year' => array('rule' => array('date', 'y'))

Però no accepta un format amb només l’any. Llavors he acabat recorrent a l’expressió regular

'rule' => array('custom', '/^[12][0-9]{3}$/')

'rule' => array('date', null, '/^[12][0-9]{3}$/')

Ambdues opcions fan exactament el mateix –date ignora el segon paràmetre si se li passa una expressió regular-, però potser sembla que passant l’expressió regular a date queda més clar.

Alguna opció millor?

dimarts, 21 d’octubre del 2008

PFC vs ModelBaker

A través d'un dels meus feeds de CakePHP he descobert una aplicació semblant a l'aplicació que vull pel meu projecte anomenada ModelBaker, que pinta molt bé tot i ser només per Mac. De moment es poden veure algunes imatges i un parell de screen casts que donen una idea de les funcions del programa.

Tot i tenir una idea similar no és exactament el mateix que el meu PFC. Podriem dir que ModelBaker afegeix una interfície gràfica molt amigable per construir aplicacions CakePHP, com el bake de consola que proporciona el mateix cakephp però amb GUI (i més opcions per personalitzar també).

La meva idea vol arribar al mateix punt però des d'un punt de partida diferent, a partir d'un esquema conceptual UML. Però no seria mala idea afegir un pas intermig similar al que fa ModelBaker per pulir les opcions del codi a generar segons el framework. I és que una de les intencions és no restringir-ho a un framework concret però certament, aquest punt està per veure. El que no crec que pugui aconseguir pas és una interfície tan clara i ordenada.

dijous, 16 d’octubre del 2008

Començant a parlar del PFC

Aprofitaré el bloc per anar deixant constància dels avenços que pugui realitzar amb el meu Projecte de Final de Carrera, per tal d'acabar l'enginyeria informàtica a la FIB. El PFC que vaig proposar realitzar tracta de desenvolupar una aplicació que, a partir d'un diagrama UML, generi l'esquelet d'una aplicació web.  

Què vol dir això?
Doncs bàsicament una eina CASE específica per a aplicacions web que et generi codi per començar un projecte a partir d'esquemes UML. Però parlar d'aplicació web és massa genèric ja que en realitat el codi generat serà per a un framework PHP.  

Un framework PHP?
Si, concretament per a CakePHP. CakePHP és un framework que evidentment està desenvolupat en PHP i agafa moltes idees de Ruby On Rails. A més aplica patrons com ara el patró MVC, és object-oriented, té una llicència MIT i per si era poc, també és el que conec millor. No obstant, l'aplicació pretén ser el màxim modular possible per a acceptar altres frameworks.
Per desenvolupar l'aplicació he decidit utilitzar C++. La interfície gràfica serà en QT 4, on considero que em puc trobar un dels grans problemes per a generar una interfície suficientment intuitiva on realitzar diagrames de classes en UML. Ja veure'm com va. El que tinc clar és que m'esperen dies de picar tecles i esprémer el cervell... Ah, sabeu quin és el títol?
Desenvolupament d'una eina de traducció UML a esquelet d'aplicació web (per a CakePHP).
No estava gaire inspirat aquell dia, no.