grails gerando pacote com nome do projeto
19/05/2010 00:00
0
Olá, sou novo por aqui e to iniciando no mundo grails/groovy e to fascinado com as facilidades.

A minha duvida:
todos os comando estão criando minhas classes dentro de um pacote com o nome da aplicação.
Por exemplo: eu tenho uma aplicação chamada Escola e faço "grails create-domain-class aluno" e ele cria minha classe Aluno dentro de um pacote chamado escola.
ele ta criando os controles e os dominios assim.

ja aconteceu isso com alguem? vlw
Tags: Grails


0
MayogaX, é uma série de 5 partes da revista java magazine escrita pelo kicolobo.

LucasDie, dentro do pacote domain, ta sendo criado outro pacote com o nome da aplicação.
19/05/2010 00:00


0
Erick, realmente eu ainda não entendi, talvez você não tenha conhecimento, mas não é necessário que você importe os pacotes de uma classe criada no domain nem nos controles nem nos serviços.
Por Exemplo:
grails create-app teste

Temos a aplicação teste.
Agora criamos uma classe AlgumaCoisa do domain no pacote teste.
grails create-domain-class teste.AlgumaCoisa
se não adicionarmos o'teste.' o grails 1.3 cria automaticamente neste pacote
Agora geramos tudo
grails generate-all teste.AlgumaCoisa

Da para visualizar que não tem import da classe 'teste.AlgumaCoisa', ai para instanciar vc faz um " def algumaCoisaInstance = new AlgumaCoisa()", e na utilização do gorm "AlgumaCoisa.list(params)".
Não há a necessidade de importar classe do domínio.

edit: Desculpe , entendi agora o problema, o que você disse realmente passou a ser padrão a partir do grails 1.3, inclusive até prejudicou o plugin de portlets que já não funcionava muito bem!
19/05/2010 00:00


0
Eu achei que era padrao, sabe?

Tambem sou novata e sempre aconteceu isso comigo. Quando eu nao quero que crie naquele pacote (estou usando Netbeans agora) eu troco o nome no campo de pacote e ele cria em outro pacote. Por linha de comando deve ter um jeito parecido.


Isso e' um problema muito importante pra vc?
19/05/2010 00:00


0
Não é um problema muito importante.
Só gostaria que não fosse assim. Gostaria que foce igual aos exemplos que eu vejo por aí.

E é chato na hora de usar o GORM: pacote.Classe.findyBy() ou new pacote.Classe(), etc
19/05/2010 00:00


0
na Versao anterior a 1.3 do grails usando o STS (SpringSource Tools) quando eu usava esse comando:
grails create-domain-class aluno


ele criava a classe sem pacote. talvez essa modificação seja da versão mais nova do Grails.
Mas não é boa prática você ter suas classes de domínio sem pacote.

voce pode dar o import do pacote onde vai usar, assim vc nao precisa invocar pelo pacote.
19/05/2010 00:00


0
vlw, entendi.

mas é estranho, vou ficar usando import em varios lugares por causa desse pacote com nome de aplicação rs
19/05/2010 00:00


0
Oras, entao deixe todas as classe em um pacote so'.

Realmente e' ruim se voce deixar elas sem pacote. Se nao quer usar import deixe todas no mesmo pacote.

E que exemplo que vc viu? Ele nao tinha pacotes? So' para entender o que vc quer
19/05/2010 00:00


0
Lendo o tópico eu fiquei em duvida, o que você quer "importar" ? até onde eu sei todas as classes que pertencem ao pacote domain são dinamicamente injetadas, ou seja, não é necessário realizar o import em nenhum controle ou serviço.
E se no caso for classes java, você pode configurar para adicionar as classes no arquivo os pacotes no arquivo conf/Config.groovy ou no conf/spring/resources.groovy, mas a configuração é diferente em casa um.
19/05/2010 00:00


0
[quote="lucasDie"]Erick, realmente eu ainda não entendi, talvez você não tenha conhecimento, mas não é necessário que você importe os pacotes de uma classe criada no domain nem nos controles nem nos serviços.
Por Exemplo:
grails create-app teste

Temos a aplicação teste.
Agora criamos uma classe AlgumaCoisa do domain no pacote teste.
grails create-domain-class teste.AlgumaCoisa
se não adicionarmos o'teste.' o grails 1.3 cria automaticamente neste pacote
Agora geramos tudo
grails generate-all teste.AlgumaCoisa

Da para visualizar que não tem import da classe 'teste.AlgumaCoisa', ai para instanciar vc faz um " def algumaCoisaInstance = new AlgumaCoisa()", e na utilização do gorm "AlgumaCoisa.list(params)".
Não há a necessidade de importar classe do domínio.

edit: Desculpe , entendi agora o problema, o que você disse realmente passou a ser padrão a partir do grails 1.3, inclusive até prejudicou o plugin de portlets que já não funcionava muito bem![/quote]

Acho que o que ele quer e' ter tudo em um pacote so' ou sem pacote, pois quando usamos dois pacotes diferente e um precisa da classe que esta' no outro pacote agente coloca importe pacote daquela tal classe.

Mesmo assim, e' desaconselhavel deixar tudo sem nenhum pacote. Mas ja' tive, seguindo um exemplo, tirar todas as classes de seu pacote e deixa-las livres.
20/05/2010 00:00


0
A "pedidos" da MayogaX. Pacotes: uso ou não? Eis a questão.

Como boa prática, é interessante usar pacotes sim, inclusive é incentivado tanto pelas ferramentas de linha de comando do Grails a partir da versão 1.2 quanto por IDEs como no caso do Netbeans. No entanto na minha série de artigos em nenhum momento criei algum. Por que isto? Este Kico é um incompetente louco? <!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) --> Nenhum dos dois.

A questão é: pra que servem pacotes? Servem para organizar o nosso código fonte de uma forma lógica, separando os módulos de nossa aplicação de acordo com a sua função. Você tem por exemplo um pacote para suas classes de entidade, outro para seus DAOs, classes de serviço, etc. Além disto, são usados também para se evitar conflitos entre nomes de classes.

Voltemos então para a organização de uma aplicação Grails. As nossas classes ficam armazenadas em diretórios específicos, certo? Temos o diretório grails-app/domain para classes de domínio, grails-app/controller para nossos Controladores, etc. Neste caso, pode-se dizer que os próprios diretórios, a própria estrutura física de uma aplicação Grails já está executando a função normalmente exercida pelos pacotes.

Ai entra a questão: e os conflitos que podem ocorrer devido ao nome das classes? Na esmagadora maioria dos fatos, será resolvida graças às próprias convenções adotadas pelo Grails. Por exemplo: toda classe de controlador possui seu nome finalizado com a palavrinha Controller. Sendo assim, você tem de ser MUITO doido pra criar uma classe de domínio usando esta mesma convenção.

E, para uma aplicação pequena, pode-se dizer com boa margem de segurança que os pacotes são realmente dispensáveis. No caso da série de artigos, nossa aplicação (um gerenciador de blogs) é muito pequena, e incrívelmente simples. Tá: eu poderia ter criado pacotes para enfatizar a boa prática, mas visto que um dos objetivos do Grails é valorizar a simplicidade, fazer uso de um recurso que já está implícito não seria ir contra este princípio? Neste caso com certeza sim.

A questão é a seguinte: aplicações feitas em Grails normalmente são auto contidas no sentido de que são normalmente projetadas visando um fim muito bem especificado. Você não vê por exemplo muitos exemplos de ERPs (cujo escopo é imenso normalmente) em Grails (existem um ou dois, mas é raro), porque *normalmente* aplicações criadas usando o framework visam um objetivo especifico. (Lembrem-se deste paragrafo quando chegarem ao final deste post ok?). Isto não quer dizer que não existam aplicações complexas usando Grails. Elas existem (eu trabalho em uma privada, por exemplo), e a partir DESTE momento pacotes passam a se mostrar fundamentais.

Se sua aplicação é de complexidade média ou alta, pacotes já passam a ser obrigatórios na minha opinião, porque você não pode mais contar com diretórios do Grails ou convenções de nomes. Seu sistema vai ser composto pro subsistemas igualmente complexos. E ai sim, pacotes passa a ser obrigatórios.

Sendo assim, via de regra eu costumo adotar a seguinte convenção: sua aplicação é composta por mais de um subsistema funcional? ADOTE pacotes. Não? Use apenas se quiser.

E sim Mayoga... &quot;that is serious&quot; <!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) -->


0
[quote=&quot;kicolobo&quot;]A &quot;pedidos&quot; da MayogaX. Pacotes: uso ou não? Eis a questão.

Como boa prática, é interessante usar pacotes sim, inclusive é incentivado tanto pelas ferramentas de linha de comando do Grails a partir da versão 1.2 quanto por IDEs como no caso do Netbeans. No entanto na minha série de artigos em nenhum momento criei algum. Por que isto? Este Kico é um incompetente louco? <!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) --> Nenhum dos dois.

A questão é: pra que servem pacotes? Servem para organizar o nosso código fonte de uma forma lógica, separando os módulos de nossa aplicação de acordo com a sua função. Você tem por exemplo um pacote para suas classes de entidade, outro para seus DAOs, classes de serviço, etc. Além disto, são usados também para se evitar conflitos entre nomes de classes.

Voltemos então para a organização de uma aplicação Grails. As nossas classes ficam armazenadas em diretórios específicos, certo? Temos o diretório grails-app/domain para classes de domínio, grails-app/controller para nossos Controladores, etc. Neste caso, pode-se dizer que os próprios diretórios, a própria estrutura física de uma aplicação Grails já está executando a função normalmente exercida pelos pacotes.

Ai entra a questão: e os conflitos que podem ocorrer devido ao nome das classes? Na esmagadora maioria dos fatos, será resolvida graças às próprias convenções adotadas pelo Grails. Por exemplo: toda classe de controlador possui seu nome finalizado com a palavrinha Controller. Sendo assim, você tem de ser MUITO doido pra criar uma classe de domínio usando esta mesma convenção.

E, para uma aplicação pequena, pode-se dizer com boa margem de segurança que os pacotes são realmente dispensáveis. No caso da série de artigos, nossa aplicação (um gerenciador de blogs) é muito pequena, e incrívelmente simples. Tá: eu poderia ter criado pacotes para enfatizar a boa prática, mas visto que um dos objetivos do Grails é valorizar a simplicidade, fazer uso de um recurso que já está implícito não seria ir contra este princípio? Neste caso com certeza sim.

A questão é a seguinte: aplicações feitas em Grails normalmente são auto contidas no sentido de que são normalmente projetadas visando um fim muito bem especificado. Você não vê por exemplo muitos exemplos de ERPs (cujo escopo é imenso normalmente) em Grails (existem um ou dois, mas é raro), porque *normalmente* aplicações criadas usando o framework visam um objetivo especifico. (Lembrem-se deste paragrafo quando chegarem ao final deste post ok?). Isto não quer dizer que não existam aplicações complexas usando Grails. Elas existem (eu trabalho em uma privada, por exemplo), e a partir DESTE momento pacotes passam a se mostrar fundamentais.

Se sua aplicação é de complexidade média ou alta, pacotes já passam a ser obrigatórios na minha opinião, porque você não pode mais contar com diretórios do Grails ou convenções de nomes. Seu sistema vai ser composto pro subsistemas igualmente complexos. E ai sim, pacotes passa a ser obrigatórios.

Sendo assim, via de regra eu costumo adotar a seguinte convenção: sua aplicação é composta por mais de um subsistema funcional? ADOTE pacotes. Não? Use apenas se quiser.

E sim Mayoga... &quot;that is serious&quot; <!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) -->[/quote]

Valeu cara, voce e' o cara!

Uhn, ate' para apps pequenas eu tava usando pacotes.. mais por boas praticas... Enfim, esse nini artigo dentro do fo'rum acrescentou muito ao pr'oprio fo'rum.
20/05/2010 00:00


0
Pacotes #FTW.

Sim, devemos usar pacote em qualquer tipo de aplicação, por menor que seja. Como várias pessoas já disseram aqui, além de uma boa prática, mantém a organização de qualquer projeto.

Apenas alguns pontos que li também:

1- Sim, antigamente não se criava o pacote por default.
2- Sim, hoje o nome da aplicação vai por default no pacote se não especificado com o grails create-domain-class
3- Dá pra criar usando o comando e pacotes, basta usar:
grails create-domain-class nome.do.meu.pacote.DomainClass

4- Você não precisa usar pacote.Domain.find*, basta importar normalmente a classe, como qualquer import
5- Uma saída pra não ter que ficar importando, que é o que muita gente faz, é usar os domains, os controllers, services, taglibs e tudo dentro do mesmo pacote, mas ai fica a pergunta.... Pra onde vai a organização e a boa prática?

<!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) -->

Muito legal a discussão!

[]s,
20/05/2010 00:00


0
[quote=&quot;lucastex&quot;]Pacotes #FTW.

Sim, devemos usar pacote em qualquer tipo de aplicação, por menor que seja. Como várias pessoas já disseram aqui, além de uma boa prática, mantém a organização de qualquer projeto.

[]s,[/quote]

Lucas, mas pensando em aplicações pequenas e com foco ultra mega definido (itasks (<!-- m --><a class="postlink" href="http://www.itasks.com.br">http://www.itasks.com.br</a><!-- m -->)) por exemplo. Visto que o nome da aplicação já é em si um pacote, e que temos já a própria estrutura de diretórios da aplicação e as convenções de nomeclatura para organizar logicamente os seus módulos, o pacote ainda seria tão obrigatório assim? Afinal de contas, até o problema de conflitos de nome se resolve assim.

E aqui entra uma questão que acho muito interessante (e esta discussão vai ficar do caralho). Adotar boas práticas só por serem boas práticas é de fato uma boa coisa?

(O que achei interessantíssimo desta abordagem de se usar o nome do pacote padrão como sendo o nome da aplicação é que vemos aqui a influência do .net né? Aonde desde sempre foi assim.)


0
Eu concordo com a utilização de pacotes para a separação lógica e física da aplicação, até fica mais fácil visualmente na hora de encontrar algo que queremos.
Porém achei estranho utilizar a instrução 'import' de uma classe de domínio no grails onde não é necessário, o Spring já não faz isso por DI para nós? a menos que também seja uma boa pratica, ou, se no caso tivermos duas classes de domínio com o mesmo nome (acho que isso não é uma boa prática).
20/05/2010 00:00


0
[quote=&quot;kicolobo&quot;]
Lucas, mas pensando em aplicações pequenas e com foco ultra mega definido (itasks (<!-- m --><a class="postlink" href="http://www.itasks.com.br">http://www.itasks.com.br</a><!-- m -->)) por exemplo. Visto que o nome da aplicação já é em si um pacote, e que temos já a própria estrutura de diretórios da aplicação e as convenções de nomeclatura para organizar logicamente os seus módulos, o pacote ainda seria tão obrigatório assim? Afinal de contas, até o problema de conflitos de nome se resolve assim.
[/quote]
Só pra esclarecer, eu não queria q ficasse sem pacote. Só estava achando estranho que minha aplicação tava gerando um pacote. Pesquisei um pouco e em lugar nenhum eu vi essa informação.
E eu na minha limitação, achava que a propria estrutura de organização dos diretórios ja funcionaria como &quot;a organização com pacote&quot;.

Bem legal o tópico. Sempre fui leitor de fóruns mas nunca participava, só lia. Espero participar ativamente desse aqui.

abçs...
21/05/2010 00:00


0
no arquivo
grails-app/conf/Config.groovy

mude esse propriedade
grails.project.groupId = "com.empresa.projeto" // change this to alter the default package name and Maven publishing destination

é isso se eu entendi o que vc precisa

abs
Arian
13/07/2011 18:18



Ainda não faz parte da comunidade???

Para se registrar, clique aqui.


Aprenda Groovy e Grails com a Formação itexto!

Newsletter Semana Groovy

Assinar

Envie seu link!


Livro de Grails


/dev/All

Os melhores blogs de TI (e em português) em um único lugar!

 
Creative Commons
RSS Grails Brasil é mantido por itexto Consultoria.
Em caso de problemas contacte Henrique Lobo Weissmann (Kico) por e-mail: kico@itexto.com.br
Todo o conteúdo presente neste site adota o Creative Commons como licença padrão.
Ver: 4.14.0
itexto