MiddleHeaven Pré-Alfa

Uma versão utilizável do MiddleHeaven já está disponivel. A versão é a 0.0.1 o que significa que é pre-alfa.

Este release não é de produção, nem muito menos está em estado de completo, mas isso é porque estou tomando em consideração todos os toolboxes.  Alguns toolboxes estão 90% terminados e alguns já são utilizáveis mesmo sem estarem completos.

O objetivo é deixar um jar disponível para que as pessoas possam experimentar o MiddleHeaven sem o esforço de baixar tudo do SVN e compilar em casa. Note-se que o MiddleHeaven tem muitas dependências externas. É bom dar uma olhada no arquivo POM dentro do jar.

É claro que nem todos os bugs foram corrigidos, mas tentei deixar corrigidos todos os que encontrei.

O blog de desenvolvimento do MiddleHeaven está aberto aos comentários de todos assim como os foruns.

Anúncios

14 opiniões sobre “MiddleHeaven Pré-Alfa”

  1. O blog é um projeto de apoio porque não quis “poluir” este meu blog. Mas dependendo da demanda posso falar do middleheaven aqui. A ideia é que sendo em inglês atinge o mundo, enquanto que em português atinge alguns países 😉

  2. a barreira da lingua é triste mesmo =/ … sei que todo programador tem obrigação de saber inglês, para poder estudar bem, mas se alguem tivesse um tempinho de traduzir os textos para o o bom e velhor portugues seria otimo =x

  3. Kd o source-code ?? sergio ?´fica dificil tentar usar a versão pre-alpha sem o código fonte, dificl ate de dar feedback …

  4. O código fonte está hospedado no Google Code http://code.google.com/p/middleheaven/source/checkout

    E o jar da versão alpha em
    http://sourceforge.net/project/showfiles.php?group_id=211558

    Lembrando que o código é um processo em andamento e é alterado constantemente. O projeto ainda não é viável para uso. A versão alpha é apenas para poder brincar e se inteirar do escopo do projeto.

    O site de apoio http://middleheaven.sourceforge.net/ é onde estão os javadocs e outras infos. Esta informação também pode mudar conforme o código é alterado.

  5. Estou pensando se não seria mais util abandonar o blog em inglês e criar um em português. Se houver interesse posso explorar essa ideia.

  6. Como ando vasculhando para entender o seu Criteria ^^, pois estou querendo montar um, ou usar o de alguem que me sirva… verifiquei algo no pacote model, relativo a entidades, onde é preciso declarar fields e etcs…

    vc não pensou em usar @interface annotations ??? de EJB ?? que é um padrao que muita gente usa, e assim ser unificado e não ter q montar uma estrutura propria para o seu framework ??

  7. gostaria de saber como fazer pesquisas em Collections com o seu framework ?? consegui montar a pesquisa e tal, so não sei como executar… veja o código abaixo


    public static void main(String ... args) {
    List<Cidade> cidades = ENTITY_MANAGER
    .createNamedQuery("Cidade.findAll")
    .getResultList();

    Estado paraiba = (Estado)ENTITY_MANAGER
    .createNamedQuery("Estado.findByNome")
    .setParameter("estado", "Paraíba")
    .getSingleResult();

    Criteria<Cidade> pesquisa = CriteriaBuilder.search(Cidade.class)
    .and("nome").startsWith("João")
    .or("estado").eq(paraiba)
    .orderBy("nome").asc()
    .all();

    //a quem envio a pesquisa ?? para filtrar a lista cidades ???
    }

    espero que o código saia diretinho =x

  8. Pelo que pude ler… em NaiveCriteriaQuery
    @Override
    public Collection<T> list() {
    // TODO filter with criteria
    return (Collection<T>)manager.getBulkData(criteria.getTargetClass().getName());
    }

    a funcionalidade não ta pronta…

    e o pior, pelo que pude ler, tenho que preparar minha Entity para que possa ser pesquisa, e guarda… isso complica muito… visto que o padrão EJB é bem difundido, se ele pudesse ser implementado, tudo seria mais facil …

    fico no agurado de respostas… vlw ai sergio ^^

  9. Em relação às anotações padrão do EJB 3 / JPA ha sim a intensão de possibilitar que sejam usadas para criar o modelo. contudo o framework não pode depender delas diretamente já que um dos objetivos é ter um framework independente. Estou trabalhando em um mecanismo que permita criar o modelo com base em qualquer conjunto de anotações, dessa forma é possível usar as do EJB e até misturar anotações de conjuntos diferentes.

    Os dados são guardados em objetos DataStorage. Os objetos são mantido por StoreKeeper . No caso de usar a memoria vc precisa usar o InMemoryStoreKeeper. A classe de teste em org.middleheaven.test.storage.NaiveStorageManagerTeste mostra como montar o DataStorage e trabalhar com ele.

  10. É mas vc fala em Framework independente, porem pelo que vi, pra usar, tenho que me amarrar arduamente a ele… minhas entidades tem que implementar uma seria de mecanismos de gets e setters de fields para que os repositorios possam manipular…

    é isso mesmo ? entendi errado ?

    e se for assim, há intenção de posteriormente desacoplar isso ?? pq inserir esse monte de métodos em minhas classes é inviável =[

    1. Quando vc usa um framework vc sempre se amarra a ele. Isso é a própria definição de framework.
      A ideia por detrás disso é que embora o framework funcione em cima do java e api de terceiros, você não trabalha com essas API diretamente. Isso provê encapsulamento, e o encapsulamento provê flexibilidade. Tanto para que o framework use API diferentes conforme a tecnologia avança, tanto para que vc não tenha nunca que se preocupar com isso. Se vc usa as anotações do EJB 3 e elas mudaram (como irão mudar com JAP 2.0) o framework terá que mudar e a sua aplicação terá que mudar. Se vc usar as anotações do framework apenas ele terá que mudar e não as sua aplicação.

      As suas entidades devem implementar getter e setters para manter um bom isolamento do estado da classe. Acesso direto aos atributos da classe é uma violação clara do principio de encapsulamento e o MiddleHeaven não faz isso por default ( seria como violar a lei por default). Existem casos especiais onde isso é necessário, como na injeção automática, mas não na parte de dados. Se a sua classe não usar acessores e modificadores então é ela que está mal desenhada. O MiddleHeaven segue boas práticas e regras e não atura quem gosta de POG ou de subverter as regras ( como acessar atributos sem passa pelos acessores). Aliás isso tem outras ramificações importantes relativas a segurança. Com acesso direto ao campos existem muitas violações que são possíveis. Existem frameworks que violam o encapsulamento por default. Experimente ativar o security manager enquanto usa um desses framework e veja o que acontece.

      O MH não existe para dificultar a vida de ninguem. Sim existe a intenção de desacoplar (embora muitos argumentem que anotações não são real acoplamento) como já tinha dito. É preciso entender também que ainda estamos em uma fase pré-alfa, ou seja, a coisa está muito longe de estar pronta para uso diário. Por outro lado o MH é constuido como uma plataforma de aplicação. Da mesma forma que quando vc quer usar Hibernate vc programa para a API do Hibernate usando as anotações e classe do Hibernate, no MH você programa para o MH usando as anotações e classes do MH. A possibilidade de reaproveitar coisas que vc já tem é um objetivo, mas não é o primeiro objectivo.

      Finalmente, no exemplo que lhe dei é mostrado o uso da toolbox de storage sem usar nenhuma anotação, logo, tb não entendo qual está sendo o seu problema já que não é exigido que usem anotações, nem mesmo as do MH , para as coisas mais simples.

  11. Bom, acho que a parte do getters n setters não foi entendido…

    abrindo suas classes apis, javadoc e sources, eu verifiquei, que o modelo de entidade, implementa alguns métodos, que são usado pelo seu framework, esses método são getters n setters da minha classe, uma lista das propriedades dela, para que vc possa acessar e saber quais propriedades da minha classe são relevantes, era esse ponto que estava falando…

    Posso estar enganado, mas o javax.persistence.* não é algo so do hibernate, diversas plataformas usam o mesmo padrão, para mapear entidades, e era nesse ponto que comentava em usar o mesmo padrão, que o toplink usa, que o hiberante usa, e que esta la para qualquer 1 usar…

    sei que acessar violando o modificador de acesso é algo estranho, mas da um puco mais de liberdade em modelar a classe, sem se preucupar com o injetor, e desenhando os modificadores apenas para o seu projeto e não para dar acesso ao framework…

    por exemplo, minhas entidades, quando uso hibernate, tem poucos métodos setters, um exemplo claro é o ID, setId() de toda as minhas entidades tem acesso private, visto que quem conhece como ajustar o Identificador da classe é so a propria classe e o Hibernate, assim não libero acesso para outras areas do meu programa, evitando que qualquer outro programador, venha a usar setId() … sei que estranho o hibernate passar pelo acesso e modificar diretamente o campo private, mais nesse aspecto me da 1 pouco de liberdade para setar o modificar de acesso…

    minhas entidades não são de todos pojos, gosto de dar 1 pouco de inteligencias pra elas, e não vejo tanto mau nisso… por exemplo veja essa entidade… http://pastebin.com/f5eb62139

    1. javax.persistence é o JPA. O JPA é uma especificação geral, mas incompleta. O MH poderia usar o JPA , mas o JPA não serve porque é incompleto.
      Assim o MH oferece algo mais completo e despresa o JPA. O JPA só funciona com banco de dados os DataStorage do MH funciona com qualquer coisa. (neste momento, memoria, bando e xml). Vc perde o fato de não usar o padrão JPA, mas ganha em flexibilidade de repositorios de persistencia. Isso pode parecer inutil se vc só usa banco, mas se vc faz testes e gosta que eles executem depressa e sem efeitos secundários (i.e. testes como deve ser) então a vantagem de usar a memória é imensa. Mas como ja disse, no futuro ( bem lá no futuro) o MH poderá entender as anotações do JPA , por agora, esqueça isso.

      O id é private, mas o set é publico. O MH não precisa que defina o ID explicitamente, mas se vc faz aplicações web, vc precisa do ID explciitamente.
      O MH associa dados de persistencia ao objeto que vc persiste, entre eles esá o id. Portanto, se a sua classe não define o ID, o MH usará internamente o ID, mas vc não vai ver.
      Por outro lado, o mecanismo de storage está sendo repensando para não depender de ids nenhuns. Desta forma um POJO comum pode ser usado como elemento persistente.

      Vc pode ter quanta inteligencia quiser nos métodos. Se o método não é de estado ele não deve ter um get/set mas se vc quiser nomear como get vc precisa usar @DomainMethod para que o MH o ignore.

Deixe uma Resposta

Please log in using one of these methods to post your comment:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão /  Alterar )

Google+ photo

Está a comentar usando a sua conta Google+ Terminar Sessão /  Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão /  Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão /  Alterar )

w

Connecting to %s