fundo

Daqui a um ano, meus clientes portarão um serviço de portal de intranet relativamente complexo (programação, rastreamento e relatórios reais e muito mais) para o Drupal, porque a matriz diz isso. Muito pouco esforço foi feito para determinar se essa é a escolha técnica certa e está além do controle dos meus clientes ou de seus chefes.

O portal atual é uma abominação que está em processo de re-fatoração e acredito que o plano mais econômico será trazer uma camada de modelo de domínio via Doctrine 2 e colocar 99,9% de toda a lógica de validação de negócios e entrada nos modelos , destruindo a abominação até que ela seja uma camada esquelética da visão e da lógica de autenticação.

Questão

Para qualquer especialista em Drupal, isso parece uma abordagem viável? Poderia o Doctrine2 funcionar bem com o Drupal ou a lógica de nível superior do Drupal precisa de uma integração muito mais rígida aos dados?

Realizamos alguns sites nos quais conectamos sistemas externos ao Drupal, onde os dados precisavam ser mantidos no sistema externo. É com isso que passo a maior parte do tempo trabalhando.

Quando fazemos isso, normalmente criamos um tipo de conteúdo para "stub out" o conteúdo no outro sistema. O tipo de conteúdo contém apenas o título do nó e um campo CCK para o identificador exclusivo no outro sistema. Junto com isso, há muitas funções hook_nodeapi . Por exemplo, o loadgancho chamará o sistema remoto e adicionará os dados ao nó. Você também precisa criar um método para obter os dados externos nos resultados da pesquisa. Existem alguns métodos para isso, mas esses são muito longos para entrar aqui.

Embora existam algumas desvantagens, achamos que isso funciona bem e permite coisas normais do Drupal, como comentários, tags etc.

A única coisa sensata a ser feita, dada a linha do tempo, é criar isso no Drupal 7. Um dos recursos mais importantes do Drupal 7, são entidades, DBNTG e campos.

Uma rápida visão geral

• Entidades é uma maneira de definir uma estrutura de dados. Exemplos de entidades incorporadas ao Drupal são nós (conteúdo principal), usuários, termos de taxonomia.
• Campos é algo que pode ser anexado a uma entidade, que também contém dados. O uso de campos tem a vantagem de ter apenas um local para manipular os dados e eles podem ser estendidos de várias maneiras. Um exemplo de campo pode ser um anexo de arquivo ou uma referência a outra entidade.
• DBTNG (banco de dados da próxima geração) é o que a comunidade Drupal tinha codinome como nova camada de abstração de banco de dados. Antes disso, costumávamos fazer consultas com espaços reservados (que ainda são suportados), mas agora a maioria das consultas é criada com classe. Uma razão para isso também é que os campos obtêm suas tabelas de banco de dados criadas com base nas configurações. Isso ajuda a criar código que funcione, mesmo que os campos sejam criados com configurações diferentes.

Esses são apenas alguns dos recursos, mas isso significa que, a menos que você queira criar uma abominação Drupal, comece a pensar em como o Drupal funciona e use-o em vez de tentar fazer o Drupal funcionar de uma maneira para a qual não foi projetado.

Como o Drupal é PHP, você pode criar módulos personalizados e usar o Doctrine2 para fazer o que quiser. Mas acho que você vai acabar com um site que tem muito pouco em comum com a maioria dos sites Drupal.

Esta é uma pergunta bastante ampla, por isso darei uma resposta de alto nível. Se você tiver perguntas mais específicas, faça-as como perguntas separadas.

Eu sugiro que você mapeie o máximo possível a estrutura do site atual. Que tipos de coisas ele faz, quais fluxos de trabalho existem. Qual é o conteúdo, quais são os usuários.

Os tipos de conteúdo são uma maneira prática de dividir o conteúdo. Até a abominação teria tipos que eu (eu esperava) que mapeiam para URLs.

Depois de determinar os tipos de conteúdo, você poderá migrar o conteúdo para o seu novo site. Em seguida, você pode ver itens como fluxos de trabalho, agendas, usuários etc.

Eu preferiria mudar por atacado. Ter o conteúdo gerenciado por mais de um sistema é uma enorme dor de cabeça técnica. E dobra seu esforço de manutenção.

Uma coisa que eu diria é que pode valer a pena contratar alguém para fazer isso. Houve algumas migrações muito bem-sucedidas do Drupal com enormes conjuntos de dados. Mas se você não tem experiência no Drupal, pode dar vários passos errados e custar muito tempo. (Eu pessoalmente posso recomendar o cyrve , não tenho nenhuma afiliação atual com eles)