Utilização do Scriptcase para manutenção de projetos desenvolvidos por terceiros

Programação
#1

Pessoal estou com uma dúvida que diante de algumas respostas no fórum me deixou instigado, sobre a utilização do Scriptcase para manutenção de projetos antigos desenvolvidos por terceiros na própria plataforma, visto que recebi respostas que é INVIÁVEL utilizá-lo ara fazer até mesmo novos relatórios pelo Scriptcase e depois acrescentarmos o código no projeto do antigo.

Então se somos contratados por outros clientes para poder dar assistência a projetos a qual eles compraram, mas não possuem mais ligações com o antigo programador, então não podemos utilizar o Scriptcase nem mesmo para poder adicionar um relatório, se for dessa forma a ferramenta como um todo mostra-se ineficaz para manutenção de projetos em PHP, e estamos falando de projetos desenvolvidos dentro da mesma plataforma.

Então fica a pergunta, em projetos já prontos não podemos acrescentar nem um relatório, mesmo tendo acesso ao banco de dados, não podemos adiciona-lo ao menu? Mesmo que seja fazendo a integração direto no código?

#2

Se não fosse assim, não teria comprado o SC

#3

Fazer integração você pode, mas esta não era a questão no seu outro tópico. A questão era sobre a viabilidade de se fazer isso.
Como já explicado o Scriptcase é uma gerador de codigo, para tanto ele tem seus padrões de geração.
Nada te impede de alterar o código, você só precisa ser paciente o bastante para estudar e editar manualmente os projetos do Scriptcase com mais de 5 mil linhas só na camada php de cada aplicação.

#4

Tá bom pessoal, vou comprar a “briga”, pois acredito não ser tão tão difícil acrescentar novas funcionalidades em projetos publicados. Já identifiquei a chamada das aplicações no código php dos menus gerados pelo Scriptcase, agora somente preciso fazer testes com a biblioteca (_lib) para saber como mesclar a biblioteca do novo relatório com a do antigo Projeto. Nada que um programa comparador de códigos não possa achar. A resposta que estou precisando somente é como o Scriptcase faz a verificação de acesso (segurança) da guia do menu ao clicarmos em um dos links, se alguém souber poste ai, se não, vou estudar o código, no final se conseguir vou postar aqui o passo a passo, posteriormente.

#5

E o projeto ‘original’ que o outro programador que criou o sistema o cliente não tem o backup dos fontes do scriptcase? caso tivesse você poderia comprar e usar o próprio scriptcase para abrir o projeto e altera-lo ao seu gosto.

#6

Pessoal como prometido consegui utilizar o Scriptcase para dar manutenção em um projeto do qual eu somente possuo o código fonte, O processo é relativamente simples, (Pelo menos para o meu caso) aqui vão os passos que utilizei:

  1. Criei um novo Projeto utilizando o Banco de dados do Projeto que dei manutenção.

  2. Gerei as nova aplicações solicitadas pelo Cliente.

  3. Copiei as Fontes, pasta _lib e Prod (Ambiente de Produção) para uma nova pasta Chamada Custon dentro das Fontes do Projeto Original.

  4. Substitui a pasta css (que ficam na pasta _lib) das novas aplicações pela pasta css do projeto antigo. (Para anular o conflito de endereço de .css entre às Versões 7 e 8).

  5. Abri e Editei Manualmente o arquivo Index.php da pasta da fonte do aplicativo do menu do projeto original. (Para Localizar com facilidade onde editar era somente dá Crt + F e Buscar na linha de código o nome da aplicação já existente no menu que antecederia a nova aplicação criada, copiar e colar a linha que dá o comando para abrir o nome e o link da aplicação anterior, e substituir o nome da aplicação e o endereço da pasta, pela nova aplicação a ser instalada no menu).

  6. Acrescentei na tabela aplicações do banco de dados as aplicações criadas. (dessa forma as aplicações novas aparecem em todas as configurações de segurança).

Parece ser complicado mas depois que entendi o processo é relativamente simples, mas isso por causa da organização das fontes dos aplicativos de menu e segurança gerados pelo ScriptCase, parabéns a plataforma.

Como dá para ver, eu preferir ficar com dois ambientes de produção e duas pastas _lib (Apesar que poderia me esforçar mais um pouco e mesclar as pastas) por ter achado mais simples.

#7

Parabéns.

#8

Legal, cara! Parabéns!!!

#9

Sinistro… vou rezar pra Zeus e o resto do Monte Olimpo te influenciar a querer gravar um vídeo mostrando como cê fez isso brow… Se Hércules vivesse na nossa era digital, esse COM CERTEZA estaria entre um dos 12 trabalhos do cara…

#10

Vocês irão usar a mesma versão do SC ?
E quando a outra parte atualizar o sistema e precisar atualizar todo o ambiente ?

#11

Não entendi nada, rs, e acho que prefiro continuar assim.

#12

Sim o sistema tá parecendo a barragem de rejeitos da mineradora Samarco, menos hora, mais dia e boom. heheh

#13

[ul]

Talvez eu não consegui ser claro, mas o código do o sistema ficou bem organizado, sem contar que por os dois sistemas que foram mesclados serem gerados no mesmo RAD(Scriptcase), o fluxograma das aplicações e do código foi mantido dando homogeneidade ao código. Há a questão da duplicidade de biblioteca e ambiente de produção, mas isso não impacta nem na estabilidade nem no desempenho já que é somente uma questão de dois endereços diferentes utilizados pelas aplicações para acessar sua respectiva biblioteca, e eu não configurei para que as conexões com o banco de dados fossem persistentes (o que geraria duas conexões abertas ao invés de uma).

Talvez a utilização por mim do Scriptcase seja diferente do usual, mas foi conforme as minhas necessidades, mas lança luz sobre algumas necessidades de alguns úsuarios:

[list]
[li]Utilização do Scriptcase para Manutenção direta no Código Fonte[/li][/list]

  Verifiquei que existia alguns posts onde os usuários tinham perdido os backups das aplicações do Scriptcase e a única solução indicada era refazer o projeto do zero, e apesar disso ser realmente a melhor ação, as vezes é inviável se você está com um prazo para entregar a nova alteração do sistema, ou se o contrato da criações de aplicações ou alterações no sistema são avulso (sem taxa de manutenção), assim você não necessitará fazer um projeto do zero para entregar ao cliente o que demandaria mais tempo em projetos grandes, tornando o preço do contrato não competitivo. (Não é o caso dá maioria mas pode acontecer)

[list][li]Mesclagem de Fontes de duas versões diferentes do Scriptcase.[/li][/list]

Verifiquei que o nome de algumas pastas das fontes geradas pelo Scriptcase são diferentes entre suas versões, o que no caso de arquivos css, gera conflito. Fica a dica para aqueles que precisarem corrigir problemas como esse.

[list][li]Erro de usuário não autorizado em aplicações em que o usuário está cadastrado[/li][/list]

Verifiquei que alguns usuários tiveram esse problema  e eu resolvi adicionando a tabela de aplicações, a nova aplicação que eu desejava que aparecesse na guia de configuração de acesso de aplicações, no grupos de acesso.

Assim não há necessidade de menosprezar o meu projeto, por pré-jugar que foi desorganizado. Repito tive o cuidado de que no final ficasse totalmente sólido, o que não foi coisa do outro mundo, visto que somente utilzei um RAD php para gerar um código complementar e depois integrei o código adjacente. (Reutilização de código de programas hoje é natural, contanto que não impacte no desempenho e organização do código).

Mas acredito que o meu esforço poderá ajudar outros a resolvem problemas menores.

“As vezes precisamos fazer uma viagem a lua e no processo descobrirmos a cola super-bond”.

Valeu Pessoal,

Um Abraço.[/ul]

#14

Eu acho inviável dar manutenção diretamente nos scripts gerados em php no ambiente de produção.

Eh mais fácil refazer o projeto.

Quando falamos em fontes aqui, são fontes Scriptcase ou seja o codigo guardado no banco de dados do SC. Script php gerado pelo SC não são as fontes são os códigos finais gerados.

Mais a cada versão do SC o código final gerado vai ter formatações internas modificadas por conta das novas implementações das releases liberadas.

Ainda vejo com um esforço sem sentido e sem propósito.