A estrutura básica do Anak Krakatoa - Anak Krakatoa Delphi Framework Wiki - Anak Krakatoa Delp...

1.0 - Estrutura de pastas

<p align="justify">Nosso prefixo é *KRK*. A idéia da estrutura é imitar a estrutura existente na pasta Source do Delphi, só que de uma forma mais inteligente, isto é, cada coisa realmente em seu lugar. Dentro de "KRKLIB" (KRAKATOA LIBRAY) estão os fontes de nossa biblioteca.</p> <p align="justify">A seguir está a estrutura básica de diretórios. Ela vai crescer à medida que for necessário.</p> {{{ TRUNK

DOC KRKCOMPONENTS

ADDITIONALCONTROLS

DCU PRJ

DELPHI 15 (DELPHI XE)

RES SRC

DATACONTROLS

(IDEM)

SHELLCONTROLS

(IDEM)

STANDARDCONTROLS

(IDEM)

WEBAPIWRAPPERS

(IDEM)

WIN32CONTROLS

(IDEM)

KRKLIB

DCU PRJ

DELPHI 15 (DELPHI XE)

RES

DOC

SRC

DB

MIDAS

DCPCRYPT

CIPHERS HASHES

DIUCL

UCL_WIN32 UCL_WIN64

REGEXP

PCRE

RTL

COMMON SYS WIN

TOOLSAPI VCL

KRKTOOLS

STORED PROCEDURE MAKER

BIN

DCU EXE

PRJ RES SRC

KRKWIZARDS

FORMTEMPLATES

DCU PRJ

DELPHI 15 (DELPHI XE)

RES

IMG

SRC

}}} = 2.0 - Nomenclatura das units = <p align="justify">O nome das units deve seguir o modelo de namespaces proposto para a programação .NET. Não acho uma boa desenvolver para .NET e sim apenas Win32 e posteriormente Win64, no entanto a notação de namespaces é bem útil e funciona corretamente em Win32, por exemplo, uma unit dentro do caminho "KRKLIB\SRC\Rtl\Common" na estrutura acima poderia ser:</p> {{{ KRK.Lib.Rtl.Common.Classes.Interposer.pas }}} Este nome de arquivo é dividido em duas partes {{{ KRK.Lib.Rtl.Common.Classes = namespace Interposer.pas = nome da unit propriamente dita }}} O namespace seria formado da seguinte maneira {{{ KRK = nosso prefixo Lib.Rtl.Common = mapeamento para uma estrutura de pastas real (veja a estrutura) Classes = namespace propriamente dito, em outras palavras, sufixo do namespace }}} = 3.0 - Detalhes sobre a estrutura de diretórios = <p align="justify">A proposta da estrutura de diretórios é prover um espaço organizado hierarquicamente para os arquivos fonte e binários gerados pelo delphi após a compilação. Alguns diretórios podem não fazer muito sentido, no entanto todos eles tem um propósito. A divisão dos diretórios como é apresentada vai, inclusive, tornar a configuração do Delphi mais correta, pois cada coisa fica em seu devido lugar, evitando assim a recompilação de fontes que já estão compilados, problema muito comum com pacotes de componentes que não foram corretamente planejados</p> <p align="justify">Tentarei explicar a seguir o significado de alguns diretórios na estrutura</p>

• _*KRKCOMPONENTS*_ - Este diretório contém diretórios que correspondem a um pacote de componentes relativo a uma paleta de componentes. A idéia é manter a nomenclatura "em sintonia" com a VCL.
• _*KRKWIZARDS*_ - Este diretório contém todos os "Experts" e "Wizards" que porventura criemos para facilitar o desenvolvimento de aplicações usando o Krakatoa.
• _*KRKLIB*_ - Este diretório vai conter todas as nossas bibliotecas (functions, procedures, classes, records, enums, constants, resourcestrings, interposers, etc).
• _*KRKTOOLS*_ - Este diretório vai conter fontes e executáveis gerados destes fontes para ferramentas externas de auxílo ao desenvolvimento. Tudo aquilo que não foi ou ainda não é expert contido em _*KRKWIZARDS*_ deve ser posto aqui.
• _*DOC*_ - Esta pasta contém a documentação do framework, bem como as documentações de componentes e bibliotecas de terceiros adicionadas ao framework == 3.1 - O diretório "KRKCOMPONENTS" == <p align="justify">Em nosso caso, ao instalar componentes na IDE, faremos isso em paletas nomeadas KRK Data Controls, KRK Shell Controls, KRK Standard, KRK Web API Wrappers, etc. Cada paleta correspondendo a um diretório na estrutura abaixo do diretório COMPONENTS. Quando novos componentes forem incluídos, se eles não encaixarem nas categorias (diretórios) existentes, novas deverão ser criadas (ADITIONAL, WIN32, etc.)</p> <p align="justify">Cada diretório de pacote de componentes tem a seguinte estrutura interna:</p>
• _*DCU*_ - Contém todos as units compiladas (dcu) geradas a partir da compilação dos arquivos de código-fonte (pas) existentes em SRC. Esta pasta somente contém units compiladas DCU e mais nada.
• _*PRJ*_ - Este diretório contém subdiretórios que correspondem a cada uma das versões de Delphi onde este componente poderá ser instalado. A nomenclatura destas pastas segue o padrão "DELPHI *versão* (*aka*)", onde *versão* é a versão incremental do compilador do Delphi e *aka* é o nome comercial da versão. A estrutura já está precarregada com "DELPHI 15 (DELPHI XE)", a versão do compilador é "15" e o nome comercial é "DELPHI XE". O nome destes diretórios é todo em MAIÚSCULAS. Dentro de cada diretório de versão do Delphi, há apenas o arquivo-fonte de pacote (dpk). Eventualmente outros arquivos serão criados automaticamente pelo Delphi nesta pasta, tais como arquivos cfg, bdsproj, dproj, local, res, drc, etc. Tais arquivos podem permanecer neste diretório pois não faria sentido apagá-los, já que eles seriam recriados sempre. Após criar um arquivo de projeto neste diretório, o mesmo deve ser configurado para usar um sufixo (LIB Suffix) que corresponde à versão do compilador do Delphi. Por exemplo, para o Delphi XE, o sufixo deve ser 150 (Delphi 15). Para o Delphi 2006 o sufixo deve ser 100 (Delphi 10).
• _*RES*_ - Contém todos os arquivos de recurso relacionados ao pacote de componentes em questão. O diretório RES contém dois subdiretórios, DOC e IMG. O primeiro serve para colocação de arquivos com documentação sobre o pacote de componentes e arquivos de ajuda (TXT, DOC, RTF, HTML, CHM, HLP, etc). O segundo serve para guardar imagens carregadas dinamicamente em designtime (ico, cur, bmp, jpg, etc). Imagens são carregadas em designtime normalmente por editores de componente ou de propriedades que precisem de algum retorno visual para o desenvolvedor. Na raiz da pasta RES ficam apenas os arquivos de recurso propriamente ditos (res, dcr, rc, etc.). Note que ao usar formulários em componentes (editores de componentes e de propriedades), estes precisam ser vinculados dinamicamente às suas units, pois vão ser colocados dentro da pasta RES, separados das units. Isso permite que ao configurar o Library Path não precisemos apontar para para o diretório SRC e sim apenas para o diretório DCU evitando assim que os fontes do componente sejam recompilado toda vez que compilamos um de nossos projetos. Para vincular dinamicamente um arquivo dfm a um arquivo pas leia o tópico mais adiante "Separando dfm e pas"
• _*SRC*_ - Este é o diretório que contém os fontes propriamente ditos (pas). Não recomendo criar subdiretórios para componentes, por isso, cada unit deverá ter um nome exclusivo e ser colocada dentro da pasta SRC. Ao contrário da nomenclatura das units do framework, as units colocadas neste diretório não devem conter referências a namespaces. Sugiro que se use a seguinte notação: UNomeDaUnit.pas. Este diretório deve conter apenas arquivos pas, nada de dfm, res ou outros arquivos. Para isso é necessário desvincular o DFM do PAS, para entendr como isso é feito, leia o tópico mais adiante "Separando dfm e pas" == 3.2 - O diretório "KRKWIZARDS" == <p align="justify">Na estrutura precarregada existe um diretório de nome "FORMTEMPLATES". A idéia é prover templates de formulários com propriedades adicionais. Penso em mudar o nome deste diretório porque também pretendo incluir templates de Datamodules, com opções adicionais para salvamento de SQL diretamente no DFM dentre outras facilidades ligadas a banco de dados.</p> <p align="justify">Dentro de FORMTEMPLATES existe a mesma estrutura contida nos diretórios de componentes descritos anteriormente. A forma de uso destes diretórios é a mesma.</p> == 3.3 - O diretório "KRKLIB" == <p align="justify">Este diretório é o coração do Anak Krakatoa e os arquivos-fonte são colocados em uma estrutura interna semelhante àquela existente na pasta Source do Delphi.</p> == 3.4 - O diretório "KRKTOOLS" == == 3.5 - O diretório "DOC" == == 3.6 - Separando dfm e pas == == 4.0 - Proposta de desenvolvimento em 3 camadas físicas == == 4.1 - Estrutura lógica do Servidor de Aplicação (Middleware) == == 4.2 - Estrutura lógica do Cliente Magro (Thin Client) == http://i1110.photobucket.com/albums/h457/carlosfeitoza/ThinClient.png <p align="justify">As setas com pontas nas duas direções indicam uso e visibilidade em ambas as direções entre os elementos ligados, por exemplo, um Form interno da aplicação (TKRKForm) _*não*_ pode acessar diretamente o Form Principal (TForm). Para fazer isso ele acessar primeiramente seu próprio DataModule (TKRKDataModule). Este por sua vez acessa o DataModule Principal (TDataModule), o qual finalmente acessa o Form Principal (TForm)</p> Continuo depois... Aguardem!