40 | | Abaixo, segue uma lista de melhorias desejáveis para a nova versão. |
41 | | |
42 | | == Propostas para o Módulo == |
43 | | |
44 | | * Definir uma nova árvore de diretórios para o módulo que contemple: |
45 | | * Isolar o código acessível pelo Expresso (inc); |
46 | | * Separar o código interno do módulo (lib); |
47 | | * Separar o código de terceiros (php e js); |
48 | | * Prever local (custom) para o código das organizações: hooks, plugins, especializações de classes, templates. |
49 | | |
50 | | * Revisar o código do engine |
51 | | * Remover métodos desnecessários; |
52 | | * Encapsular as classes e atributos, segundo orientação por objetos (private, public, protected); |
53 | | * Remover o design pattern Observer; |
54 | | * Transferir para o módulo as classes que são de estrutura dos processos e deixar no engine apenas as funcionalidades relativas ao andamento das instâncias; |
55 | | * Eliminar a sobrecarga de métodos do engine que está sendo feita na pasta inc do workflow. Por exemplo a classe workflow_processomanager; |
56 | | * Eliminar o parâmetro link do banco de dados passado na construção da classe; |
57 | | * Documentar o engine com um diagrama de classes e um diagrama entidade-relacionamento; |
58 | | * Verificar se é possível documentar o engine com algum diagrama comportamental. |
59 | | |
60 | | * Criar uma nova factory estática para o workflow |
61 | | * Fazer o registro das classes que podem ser utilizadas; |
62 | | * Avaliar o design pattern registry e ver como pode ser aproveitado; |
63 | | * Encapsular objetos do array $Globals; |
64 | | * Criar um cache na factory; |
65 | | * Avaliar como pode ser feito um cache de objetos que perdure após um recarregamento da página, por exemplo utilizando sessão ou memcache; |
66 | | * Definir um hook para implementar o cache personalizado de um organização. Se inexistente, usa o padrão do workflow; |
67 | | * Aproveitar esta factory também para os processos, e prover uma forma de isolar as classes que são do módulo. Uma possibilidade seria criar uma factory abstrata e uma especialização para o workflow e outra para os processos; |
68 | | * Verificar se é possível utilizar o autoload para identicar a localização dos arquivos fontes; |
69 | | |
70 | | * Reorganizar o código do workflow utilizando plugins |
71 | | * Definir uma estrutura de plugins que possibilite a separação do núcleo do workflow e suas funcionalidades periféricas; |
72 | | * Entende-se por núcleo do workflow toda a estrutura responsável pela execução de atividades, controle do fluxo dos processos, controle de plugins e segurança; |
73 | | * Cada plugin deve ter um identificador único que será cadastrado no banco de dados e que possibilite a sua habilitação ou desabilitação; |
74 | | * No banco de dados devem ser inseridos dados como: o identificador, localização do arquivo da controller, nome da classe e status; |
75 | | * Os plugins devem estender uma classe geral que defina métodos padrão para registro, instanciação e execução daqueles; |
76 | | * Em determinados lugares dentro do módulo devem ser definidos hooks. Ex. Menu lateral de administração, aba na interface de usuário, etc.; |
77 | | * Deve-se criar uma estrutura padrão para os plugins que siga o design pattern MVC; |
78 | | * Deve existir algum controle de acesso para liberar os plugins para usuários; |
79 | | * Possibilitar aninhamento de plugins; |
80 | | * Possibilitar a criação de plugin na área custom da organização. |
81 | | |
82 | | * Pesquisar e implantar uma ferramenta para design dos fluxos dos processos |
83 | | * Atualmente os processos são cadastrados através de formulários, onde o desenvolvedor informa as atividades, transições, perfis, etc. Depois pode exibir um gráfico do processo. A proposta é encontrar uma ferramenta que faça o contrário: desenhe o fluxo e este sirva de entrada para registrar a estrutura do processo. Possivelmente o fluxo será descrito em uma linguagem de definição que pode ser lida pelo módulo workflow, ou então a nova ferramenta poderia acessar diretamente o banco de dados; |
84 | | * Reformular a interface administrativa para que as operações possam ser feitas sobre a imagem do processo. Por exemplo, clicando sobre ícone de uma atividade tem-se acesso às suas propriedades e perfis; |
85 | | * Impedir que modificações sejam feitas no fluxo quando existirem instâncias dependentes das atividades. |
86 | | |
87 | | * Implantar um gerador de código |
88 | | * Com este novo recurso, quando o gráfico do processo estiver concluído, será gerado o código básico para que o processo funcione. Assim sendo, o desenvolvedor ficaria com a tarefa de preencher lacunas no código, como por exemplo os formulários e métodos associados aos botões. |
89 | | |
90 | | * Criar um mecanismo autenticado para inclusão de instâncias |
91 | | * Com esta funcionalidade, sistemas externos poderão iniciar instâncias no workflow, sem passar pelas atividades Start dos processos; |
92 | | * Considerar o uso de web-service autenticado; |
93 | | * Considerar a possibilidade de uso de certificado. |
94 | | |
95 | | * Criar boletins para processos |
96 | | * Implementar uma área, em cada processo, para divulgar as novidades, melhorias e correções. Isso é útil para os usuários acompanharem a evolução dos processos. |
97 | | |
98 | | * Avaliar as bibliotedas de javascript utilizadas no Expresso e escolher aquelas que serão as oficiais |
99 | | * Dentre as bibliotecas existentes, que sejam de mesma natureza, optar por uma delas e modificar o código do módulo. |
100 | | |
101 | | * Substituir o conector Ajax |
102 | | * Trocar o atual conector Ajax (connector.js / controller.php) usado na interface do módulo, pelo framework nanoAjax, que já é utilizado nos processos. Substituir todas as chamadas do antigo conector pelo novo. |
103 | | |
104 | | * Criar um controle de tempo de execução para atividades |
105 | | * Implementar uma nova funcionalidade para atividades em que possa ser definido um tempo máximo de permanência da mesma com o usuário que detém a posse; |
106 | | * Criar um job genérico que rode diariamente e selecione as atividades que expiraram os prazos, e de alguma forma comunicar o usuário ou um administrador designado; |
107 | | * Se ficar inviável criar o job, porque o atual modelo exige configuração do cron do servidor, criar ao menos um página que mostre o resultado das pesquisas com opção de envio de email; |
108 | | * Verificar a possibilidade de gravar buscas no monitoramento por processo, e efetuar envio de email automático a partir do resultado da busca. |
109 | | |
110 | | * Prover uma auditoria de queries executadas nas tabelas do módulo Workflow. |
111 | | * Quando alguma alteração nos dados do processo for realizada, na interface de administração, registrar o evento em banco de dados para se ter um histórico dos acontecimentos. Por exemplo, ativação/desativação de processo, alteração de configuração, inclusão/exclusão de elementos, etc; |
112 | | * Verificar a possibilidade de executar triggers nas tabelas do módulo Workflow, para logar a atividade sql. Cuidar para não impactar na performance geral do banco; |
113 | | * Outra abordagem pode ser inserção de código nos principais eventos administrativos, para logar as modificações; |
114 | | |
115 | | * Pensar em uma maneira de fazer um acompanhamento por processo, onde um usuário possa visualizar qualquer instância, e não somente as que detém a posse; |
116 | | * Uma solução pode ser a criação de um perfil especial [Leitor] e associar os usuários que podem visualizar instâncias do processo; |
117 | | |
118 | | * No menu 'mais ações' da instância, criar hooks para possibilitar inclusão de código a ser executado quando a ação for acionada; |
119 | | * Por exemplo, ao abortar uma instância, realizar também alguma manutenção no banco de dados do processo; |
120 | | |
121 | | * Modificar o template padrão de processos para: |
122 | | * Definir um hook para personilizar o template de processos por organização; |
123 | | * Criar parâmetros para incluir as bibliotecas de javascript. |
124 | | |
125 | | * Implantar uma ferramenta de automação de testes e deploy |
126 | | * Considerar a experiência do Serpro-BA com os softwares phpunit, phpdocumentor, codesniffer, ant, hudson (integração contínua); |
127 | | * Verificar a possibilidade de expandir as funcionalidades do Processo de Transferência; |
128 | | * Estudar uma maneira de realizar o deploy completo do processo, envolvendo o código fonte e a estrutura de atividades, transições e perfis. |
129 | | |
130 | | * Executar o código do módulo sob tratamento de exceções (try/catch); |
131 | | |
132 | | == Propostas para o MVC == |
133 | | |
134 | | * Definir uma nova estrutura de diretórios para os processos |
135 | | * Considerar a experiência do Serpro-BA; |
136 | | * Analisar a estrutura de outros frameworks como o Cake e Simphony; |
137 | | * Prever áreas para: |
138 | | * Model-View-Controller; |
139 | | * Ajax; |
140 | | * Templates; |
141 | | * Js; |
142 | | * Imagens; |
143 | | * Jobs; |
144 | | * Classes de Negócio; |
145 | | * Config; |
146 | | * Facade (opcional); |
147 | | * Dao; |
148 | | * Serviços |
149 | | * Log. |
150 | | * Isolar os dados variáveis como log, documentação, compiled, smarty, graph, para facilitar a automação de deploy e a integração com IDEs; |
151 | | * Substituir a função wf_include por factory. |
152 | | |
153 | | * Criar um novo modelo de execução de atividades |
154 | | * Suprimir o arquivo php da atividade; |
155 | | * Dividir a atividade em model-view-controller |
156 | | * Deverá existir um classe mãe para cada camada, com métodos para inicialização, finalização, cancelamento, execução, continuação de uma instância, execução de ajax, comunicação com o engine, etc; |
157 | | * A classe da atividade deverá implementar os métodos que forem necessários; |
158 | | * Criar uma nova classe run_activity, que será responsável por instanciar a classe controller da atividade e executá-la; |
159 | | * Impedir que a controller tenha acesso aos atributos e métodos da run_activity; |
160 | | * Usar uma função global para obter este objeto, de modo a garantir que somente o código da classe seja carregado; |
161 | | * Testar se é seguro incluir o código da controller diretamente na run_activity; |
162 | | * Criar um mecanismo que impeça o código do usuário criar objetos das classes do módulo e do engine. Como sugestão poderia ser uma análise no call_back procurando a origem da instanciação; |
163 | | * Acomodar os processamentos pré e pós execução das atividades (agente de correio) em outro local do código; |
164 | | * Criar plugins para processos; |
165 | | * Transformar a conexão mainframe da Celepar em um plugin; |
166 | | * Tranformar a factory do processo em estática |
167 | | * Instanciar os objetos hoje pré-carregados, sob demanda; |
168 | | * Eliminar a código compilado; |
169 | | * Pensar se é viável liberar para o processo gravar dados na sessão; |
170 | | * Prover uma maneira do workflow diferenciar o código do mvc antigo e do novo e executar corretamente cada ambiente. |
171 | | * Executar a atividade com tratamento de exceções (try/catch). |
172 | | |
173 | | * Criar uma camada de visualização |
174 | | * Criar componentes para os diversos elementos de formulário, como textarea, inputs, etc; |
175 | | * Prever inclusão da validação do componente; |
176 | | * Implementar um componente container, que agrega componentes em uma mesma linha do template; |
177 | | * Criar componente de ocultação; |
178 | | * Criar um controle de acesso por componente, para ocultar elementos que não estejam disponíveis para um usuário; |
179 | | * Prever também o encapsulamento dos plugins smarty criados para o workflow (select users, etc); |
180 | | * Carregar no template os arquivos javascript indicados pelo desenvolvedor. Possibilitar associar funções javascript aos componentes; |
181 | | * O objeto view deverá carregar os dados preparados na camada model e mesclar no template; |
182 | | * A criação do objeto smarty ficará ao encargo da camada view; |
183 | | * Criar uma função Js (goAjax) padrão para criar o objeto !NanoController e adicionar a chamada virtual (addVirtualRequest); |
184 | | * Simplificar os arquivos css e usar div ao invés de tabelas; |
185 | | * Pensar na possibilidade de aproveitar os frameworks de css 960 ( http://960.gs) e blueprint ( http://www.blueprintcss.org) na camada de visualização. |
186 | | |
187 | | * Tratamento e exibição de erros |
188 | | * O submit fará uma chamada ao dispatch: |
189 | | * O dispatch fará a verificação prévia de campos obrigatórios (1o. passo); |
190 | | * Caso não tenha erros fará a validação dos componentes, via ajax (2o. passo); |
191 | | * Caso não tenha erros irá chamar o método de validação em php, via ajax (3o. passo); |
192 | | * O método de validação php terá um nome padrão e será responsável por validações de negócio; |
193 | | * Caso existam erros na validação ajax, será polulado um array Js para exibição das mensagens no template (prever uma área para mensagens); |
194 | | * Caso sem erros, será montado o array request na model e feita a submissão. Validar novamente pela model php; |
195 | | * Existindo erros, estes serão adicionados a uma variável smarty, recarregado o template e as mensagens exibidas pela mesma função Js da validação ajax; |
196 | | * Incluir no template padrão uma função Js para exibir os erros encontrados. |
197 | | |
198 | | * Camada Model |
199 | | * Criar métodos para verificação de segurança sobre dados entrados pelo usuário: sqlinjection, xss; |
200 | | * Avaliar o htmlpurify e as soluções já utilizadas na run_activity e personalizadas nos processos já desenvolvidos; |
201 | | * Revisar e padronizar as classes utilitárias: tratamento de datas, expressões regulares, tipos de dados; |
202 | | * Incluir tratamento de erros na classe wf_db. Atualmente o workflow delega esta ação para o desenvolvedor; |
203 | | * Retornar o erro produzido pelo adodb ou o resultado da operação (resultset); |
204 | | * Criar automação de relatório genérico com a classe fpdf; |
205 | | |
206 | | * Criar uma biblioteca Js para funções úteis para os processos que não existam nas biblioteca de terceiros acessíveis pelo workflow. |
207 | | |
208 | | * Criar um local para definição das constantes do processo |
209 | | * Utilizado para array de mensagens; |
210 | | * Constantes operacionais; |
211 | | * Schema de banco de dados; |
212 | | * Qualquer outro parâmetro de configuração global do processso que seja necessário. |
213 | | * Verificar as possibilidades: pode ser no arquivo shared.php, ou em um arquivo config do processo, ou ainda em uma nova aba na adminstração do processo; |
214 | | |
215 | | * Padronizar os índices do array Requests com um prefixo, para facilitar a transferência entre as camadas; |
216 | | |
217 | | * Criar uma camada para mapeamento objeto-relacional |
218 | | * Considerar a experiência do Serpro-BA com o Propel. |
219 | | |
220 | | == Utilizando branches == |
221 | | |
222 | | Como descrito acima, tickets que exijam grandes modificações devem ser implementados em branches separados, ao invés de utilizar diretamente o trunk. O primeiro passo é criar um novo branch: |
223 | | {{{ |
224 | | svn copy https://svn.expressolivre.org/sandbox/workflow/trunk \ |
225 | | https://svn.expressolivre.org/sandbox/workflow/branches/1001 \ |
226 | | -m "Ticket #1001 - Criando novo branch para implementação do ticket." |
227 | | }}} |
228 | | O comando '''svn copy''' é utilizado para a criação de branches. Na forma que é mostrado acima, este comando não precisa ser executado a partir de um repositório svn, todo procedimento é realizado no servidor. O primeiro parâmetro é o branch de origem, de onde serão copiados os dados. Os branches criados para os tickets da versão experimental do Workflow devem sempre utilizar o repositório /sandbox/workflow/trunk como origem. O segundo parâmetro especifica o endereço do novo branch. O novo branch deve seguir o padrão /sandbox/workflow/branches/{#ticket}. Já o terceiro parâmetro, opcional e especificado pela opção ''-m'', especifica a mensagem do commit que criará o novo branch. É importante notar que o commit inicial de criação do branch, será visível apenas ao novo branch, mas não através do branch de origem (trunk). Desta forma, a partir do repositório de origem, não é possível determinar o momento exato de criação dos branches. |
229 | | |
230 | | Após criado, o branch pode ser acessado de duas formas: |
231 | | {{{ |
232 | | svn checkout https://svn.expressolivre.org/sandbox/workflow/branches/1001 |
233 | | }}} |
234 | | para criar uma nova cópia local do repositório já em seu novo branch, ou: |
235 | | {{{ |
236 | | svn switch https://svn.expressolivre.org/sandbox/workflow/branches/1001 |
237 | | }}} |
238 | | para mudar o branch de sua cópia local. Todos os commits subsequentes serão acessíveis apenas através do seu branch, devendo seguir o mesmo padrão das mensagens de commit adotados no restante do ambiente. |
| 42 | * [http://trac.expressolivre.org/milestone/Sandbox%20-%20Workflow Milestone Sandbox - Workflow] |
| 43 | * [wiki:WF/propostasmoduloworkflow Propostas para o Módulo Workflow] |
| 44 | * [wiki:WF/propostasmvcworkflow Propostas para o MVC do Workflow] |
| 45 | * [wiki:WF/utilizandobranches Comandos SVN úteis (inclui svn merge)] |