Tecnologias Client-Side - APIs
Independentemente do CMS escolhido, ou mesmo se optarmos pela construção de raiz, teremos sempre em conta que este projecto irá utilizar uma ferramenta de edição vectorial online. Criar uma de raiz foi um desafio que foi já posto de parte. Sendo assim, foi feito uma pesquisa no sentido de encontrar soluções possíveis de serem implementadas na aplicação. As opções que temos neste aspecto são:
SVG-EDIT:
AVIARY:
Ambas as ferramentas cumprem os nossos requisitos funcionais e têm uma facilidade de integração relativamente semelhante.
Se optarmos pelo svg-edit, teremos acesso a todo o código da ferramenta (desenvolvido em Javascript e open source) e o controlo completo da sua implementação, funcionalidades e interacção com o resto da aplicação. Há o senão de não haver nenhum módulo, em qualquer dos CMS considerados, que faça a integração com este API, ficando a mesma a nosso cargo.
Com o Aviary, estaríamos a utilizar uma ferramenta proprietária e desenvolvida em Flash. Isto levanta vários problemas: os documentos vectoriais gravados seriam armazenados na base de dados da Aviary - seria necessária a conexão entre as contas do Aviary e as contas de utilizadores da nossa plataforma. Também há o aspecto de utilizar funcionalidades de um aplicação efectivamente “concorrente”, que iria guardar na sua base de dados todas as criações dos nossos potenciais utilizadores, com potencial desvio de parte do nosso público-alvo para uma aplicação concorrente. Essa dependência também significa a perca de controlo de um dos pilares da nossa aplicação: a existir, por exemplo, uma falha na aplicação do Aviary, a nossa aplicação ficaria comprometida sem que nada pudesse ser feito do nosso lado para repor a funcionalidade. Por outro lado, o Aviary garante-nos uma ferramenta de qualidade superior ao svg-edit, para além de que a implementação, a nível do Drupal, está já assegurada por parte de um módulo existente.
Conclusão
Todo o trabalho de levantamento de requisitos e de soluções técnicas serviu, para ancorar o projecto que ainda se encontrava pouco definido. O desenvolvimento da lista de requisitos funcionais ajudou a definir melhor e é, salvo revisões futuras pontuais (como sempre acontecem), o documento orientador para as escolhas finais.
A nível das soluções técnicas, avançamos com as soluções que melhor respondem aos critérios estipulados para as prioridades dos diferentes perfis de utilizador, implementação técnica da ferramenta de desenho e integração na comunidade. Uma vez que o grupo não tem experiência de trabalho em muitas das tecnologias consideradas (CMSs, APIs), só na fase de prototipagem é que será possível averiguar qual é a solução mais adequada. Sendo assim, decidimos apresentar por ordem os conjuntos de soluções mais realistas, tendo em conta todas as análises acima apresentadas. Como já foi referido, a tecnologia a usar, de forma genérica, para todo o aspecto client-side da aplicação, será o conjunto HTML+CSS+Javascript. A partir daí, surge um número de “combinações” possíveis, entre os CMS e APIs considerados.
Solução escolhida
A nossa primeira opção passa pela combinação do CMS Drupal com a API de desenho vectorial svg-edit. O foco está na manutenção do controlo sobre todos os aspectos da aplicação.
Esta é a solução mais ambiciosa, mas que representa um desafio técnico mais interessante, enquanto experiência de aprendizagem, uma vez que estas plataformas nos podem fornecer um know-how inovador.
Alternativas
Caso algum desses elementos (CMS ou API) não seja viável, irá ser usada a solução alternativa de Joomla como CMS (caso seja o Drupal a falhar) ou então de Raven (a API do Aviary) como ferramenta de desenho.
A última opção centra-se, não na utilização de um CMS, mas na criação do código manualmente recorrendo às tecnologias de PHP/MYSQL, apoiadas por CSS e Javascript. Relativamente à API irá se manter como na primeira opção, dando-se prioridade à API svg-edit e em segundo lugar à API do Aviary (Raven).
