marcorosi / regola-kit Goto Github PK

Se si eseguono i test di regola-jdo con Java 6 si ottiene questo messaggio:

org.springframework.orm.jdo.JdoUsageException: The class
"org.regola.model.Customer" is not Persistence-Capable. This means that it
either hasnt been enhance
d, or that the enhanced version of the file is not in the CLASSPATH (or is
hidden by an unenhanced version), or the Meta-Data for the class is not
found.; ne
sted exception is org.jpox.exceptions.ClassNotPersistenceCapableException:
The class "org.regola.model.Customer" is not Persistence-Capable. This
means that 
it either hasnt been enhanced, or that the enhanced version of the file is
not in the CLASSPATH (or is hidden by an unenhanced version), or the
Meta-Data for
 the class is not found.

La versione di Java 6 testata:
Java(TM) SE Runtime Environment (build 1.6.0-b105)

Realizzare dei piccoli (brevissimi) tutorial su questioni pratiche come:

1- creare un nuovo progetto con regola-kit
2- configurare il data source e l'orm
3- localizzazioni
4- creare una pagina master
5- creare una pagina di detail
6- usare il plugin di eclipse per fare tutto in fretta

Bisogna aggiungere le icone mancanti e ridurre l'uso dei bottoni. 

Inoltre lo stile della tabella nell'aggiornamento delle ice-faces è andato
perso :-).

Probabilmente non farebbe neanche schifo aggiungere una pagina di welcome
che chiarisca cosa si sta guardando.

In alcuni casi di join con ulteriori condizioni di filtraggio sulle entità
in join vengono fuori delgi alias insesistenti (con progressivo maggiore
del numero di entities coinvolte).

Il bug è stato fissato (si veda BaseQueryBuilder).

Porting da RESTDom dei metodi finder di interfaccia realizzati tramite
named query (o mappend statement iBATIS).

Porting da RESTDom dell'implementazione iBATIS del GenericDao.

Valutare l'utilizzo di @Id per discriminare in save() fra insert o update.

Valutare il porting delle annotazioni @Cascade.

Testare tutte le annotazioni di filtro.

Testare i metodi Finder (dipende da issue #6).

Testare mapping più complessi dei dati di test (Customer, Invoice, Item,
Product).

Documentare il parsing delle annotazioni nel ModelPattern.
Precisare il comportamento con annotazioni multiple.
Precisare il comportamento con valori null nelle proprietà del ModelPattern.
Precisare comportamento e formato della stringa di @Like.

E' stata aggiunta una nuova annotazione (@IsNull) per gestire condizioni di
filtraggio di tipo "is null" e "is not null".

L'annotazione è applicabile a proprietà di tipo Boolean e come valore deve
avere il path alla proprietà dell'oggetto di modello.
Il suo comportamento dipende dal valore della proprietà del modelPattern:
- null: non viene fatto nessun filtraggio su quella proprietà;
- true: viene applicato "is null";
- false: viene applicato "is not null".

Regola utilizza Hibernate Validator per convalidare le proprietà di un
oggetto. Dobbiamo però affrontare anche due problemi:

integrazione con i validator jsf: infatti questi scattano prima di
Hibernate Validator ed in caso di cast sbagliato (ad esempio una stringa
inserita in una proprietà numerica) avremmo un eccezione non gestita. E' il
problema della validazione sintattica contro una validazione semantica.

emendamenti: la stessa classe deve poter essere validata in modo diverso in
parti diverse dell'applicazione. E' necessario aggiungere un sistema che,
partendo dalle annotazioni sulla classe, consenta di aggiungere o rimuovere
regole di validazione 

Creare una pagina di wiki (tipo "GettingStarted") con una descrizione
dell'interfaccia e degli esempi d'uso.

Chiarire anche alcuni aspetti di competenze e responsabilità: transazioni,
attach/detach, flush, eccezioni e nulls, ecc.

Rimuovere la copia dei dati di test via maven antrun.

Realizzare l'inizializzazione del db in @BeforeClass tramite jdbcTemplate.

Reimplementare la logica di handling delle annotazioni di filtro in base ad
un registro inizializzato con le annotazioni standard.

Cominciamo ad avere delle situazioni in cui la sola possibilità dell'AND
tra le clausole di un certo filtro è un limite.

In particolare inizia a sentirsi l'esigenza di poter comporre in OR le
clausole o fare delle negazioni.

Ci possono essere due modi di procedere (se ve ne vengono in mente altri
proponente pure):
- creare nuove annotazioni, ad esempio con semantica negata, in modo che la
loro composizione in AND produca una clausola logicamente equivalente a
quella desiderata (col le regole della logica del primo ordine) (questa
proposta non sembra portare molto lontano...);
- implementare quell'idea venuta fuori tempo fa sul fatto dare la
possibilità allo sviluppatore di scrivere clausole connesse da operatori
logici.

Problematiche:
mantenimento della retrocompatibilità? (lasciare come comportamento di
default la composizione in AND delle clausole)

Spostare le implementazioni di GenericDao sotto il multimodulo regola-dao
(valutare se renderlo anche parent).

Assegnare dei nomi più appropriati alle classi coinvolte nella creazione di
un filtro dal ModelPattern.

I nomi dovrebbero rispecchiare meglio i ruoli e gli intenti.

Il builder dovrebbe produrre (anche) una Query e non (solo) un Criteria (in
termini Hibernate).

Implementare un HibernateCriteria che produce HQL?

Rivedere l'astrazione Criteria api. Introdurre l'astrazione Query?

Rivedere la relazione Dao/CriteriaBuilder.

Vedi anche issue #1.

Reimplementare JpaCriteria come JdoCriteria (ed eventualmente
HibernateCriteria, vedi issue #5).

Premessa: in una query sql nella quale si sta proiettando almeno un CLOB
non è consentito l'uso della clausola distinct.

Il QueryBuilder di Regola-kit inserisce sempre il distinct (o almeno così
mi è parso di capire dal codice e dai test che ho fatto), causando
sistematicamente dei fallimenti nel caso in cui almeno una delle colonne
che si stanno proiettando è un CLOB.

Che fare? Ricordo male o quel distinct era proprio stato aggiunto per
fissare una precedente anomalia?

Implementare le funzionalità di base di ModelPattern e ModelPattern$Property.

Predisporre un sistema standard per i test web. Utilizzeremo Canoo webtest.
Bisogna adeguare regola-jsf, l'esempio e l'archetipo. 

Implementare nel ModelPatternParser la logica di gestione delle
informazioni di paginazione ed ordinamento presenti nel ModelPattern.

migliorare la pagina di errore (error.xhtml) in modo che riporti lo stacktrace

eliminare i file 403,404,500?

Aggiungere all'interno di regola-jsf l'autenticazione di default con acegi.
Ovvero tutte le configurazioni necessarie  più una semplice classe che
confronta username e password con delle stringhe fisse.

Bisogna poi aggiungere queste classi all'esempio ed all'archetipo. 

Tentare con static weaving (enhancement) delle classi via antrun (come per
Jdo).

L'attuale implementazione del modelpattern si comporta in maniera scorretta
quando si cerca di filtrare su proprietà di entità associate.
Trovate un esempio in CustomerPattern, campo invoiceId e nel relativo test
case: testFindByModelPattern_relationBug().

Ho iniziato a modificare HibernateCriteria ma la mia modifica ha corrotto
il funzionamento di alcuni test. Nello specifico quelli in cui si filtrano
proprietà di un componente (Address).

Per il momento abbiamo 2 proposte:
1) ricavare a runtime la configurazione e applicare un sistema di
filtraggio corretto
2) specificare con caratteri diversi nelle annotazioni le relazioni tra
entità e componenti.

es.

    @Equals("invoices$id")
    private Integer invoiceId;

    public Integer getInvoiceId() {
        return invoiceId;
    }