Implementando front-end no Sharepoint sem Sharepoint Designer

Sempre que converso com alguém sobre implementar o front-end do Sharepoint, recebo uma cara torcida, pois logo vem a mente o Sharepoint Designer.

Um pouco de história

O Sharepoint Designer é uma ferramenta criada pela Microsoft, sendo uma evolução do antigo Front Page, ferramenta destinada a diagramadores.

Como o Sharepoint é um CMS e todos os seus binários estão armazenados em banco, apenas o Sharepoint Designer consegue acessá-los. Nada impede que criemos um mapeamento de rede apontando para o Sharepoint para emular uma unidade de disco, mas ainda assim é banco.

Para a sua função básica o Sharepoint serve, mas para produção mais massiva, com vários desenvolvedores trabalhando com o mesmo binário sem versionamento, aí complica.

Trabalhando com os binários localmente

Uma possibilidade que temos é baixar os binários do Sharepoint para a nossa máquina, modificá-los usando a ferramenta de sua escolha, no meu caso, o Visual Studio Code, e depois subir os arquivos alterados usando o próprio site do Sharepoint.

Mas isso é bem trabalhoso, e pode acontecer de outro desenvolvedor alterar o mesmo arquivo que você alterou.

Com isso, já temos 2 problemas: 1) Como trabalhar com os arquivos localmente? 2) Como evitar que o seu trabalho seja perdido por que outro desenvolvedor alterou o mesmo arquivo?

Neste post, vou explicar como resolvemos a questão da alteração local sem precisar acessar o site do Sharepoint para fazer o upload. Agora a questão dois é mais simples, usando uma ferramenta de controle de versão.

Preparando o seu ambiente com o Gulp

Quando acessamos página do Gulp recebemos logo de cara a frase “Automate and enchance your workflow”, ou seja, automatize e aprimore seu fluxo de trabalho.

E qual é o meu fluxo de trabalho para alterar binários do Sharepoint localmente? 1) Alterar os dados localmente; 2) enviar para o servidor.

Não tenho a pretensão de ensinar a usar o Gulp neste post, mas você pode encontrar maiores informações em https://gulpjs.com/

Partindo do pressuposto que você tem tudo que precisa para rodar o Gulp, você vai precisar ainda do SPSave e Gulp-SPSave.

Você pode também definir um arquivo package.json, como o abaixo, e rodar simplesmente npm install.

{
   "devDependencies": {
      "gulp": "^3.9.1",
      "gulp-spsave": "^3.1.0",
      "spsave": "^3.1.0"
   }
}

Criando a sua task de publicação

Uma das coisas mais bacanas do Gulp é que você pode criar as suas próprias tarefas, e é isso que vamos fazer. Vamos criar a nossa tarefa de publicação alterando o gulpfile.js. Caso não saiba como criar o gulpfile.js, dê uma olhada nesta página.

Começamos pelo básico, carregando gulp e definindo a tarefa:

var gulp = require('gulp');
gulp.task('publish', function() {
});

A tarefa de publicação deve ler o binário que deve ser publicado e enviá-lo para o Sharepoint, é aqui que entra o SPSave. Usaremos como exemplo a página Home.aspx que deve estar na biblioteca Site Pages.

var gulp = require('gulp');
gulp.task('publish', function() {
  var spsave = require('gulp-spsave');
  return gulp
     .src(['./Home.aspx'])
     .pipe(spsave(
        {
           siteUrl: '<url do site>',
           folder: 'Site Pages',
           flatten: false
        }, 
        {
           username: '<usuário>',
           password: '<password>'
        }));
});

Publicando mais do que um arquivo

Na minha equipe atual, temos a necessidade de implementar páginas, CSS, JSs, …, mas sempre usando as duas bibliotecas que temos disponíveis no Sharepoint, a Site Pages e Site Assets.

Considere agora que você tem na sua máquina a mesma estrutura do seu site no Sharepoint, ou seja, duas folders que representam as duas bibliotecas do Sharepoint.

Agora precisamos fazer algumas alterações no nosso gulpfile, para ler todos os arquivos das duas pastas, considerando o caminho que será utilizado para a publicação usando o gulp-path.

var gulp = require('gulp');
var path = require('path');
var currentFolder = path.resolve("./").split('\\').join('/');
gulp.task('publish', function(cb) {
  var spsave = require('gulp-spsave');
  return gulp
     .src(['./SiteAssets/**/*.*', './SitePages/**/*.*'])
     .on('data', function (file) {
        sendFileToSharepoint(file.path);
     })
     .on('end', function () {
        cb();
     });
});
var sendFileToSharepoint = function(file) {
   var folder = file.split('\\').join('/');
   folder = folder.substring(folder.lastIndexOf('/' + currentFolder + '/') + currentFolder.length + 2);
   folder = folder.substring(0, folder.lastIndexOf('/'));
   return gulp
     .src(file)
     .pipe(spsave(
       {
          siteUrl: '<url do site>',
          folder: folder,
          flatten: false
       }, 
       {
          username: '<usuário>',
          password: '<password>'
       }));
};

Publicando automaticamente o arquivo assim que ele é salvo

Já temos uma tarefa que publica todos os binários, mas podemos ter outra que faz a “sincronia” automática. Para isso precisamos de outro plugin to Gulp o gulp-watch.

Depois de instalado o gulp-watch basta criarmos uma nova tarefa para monitorar os mesmos arquivos publicados anteriormente, e sempre que sofrerem uma modificação, esse arquivo deve ser enviado para o Sharepoint. Mas ainda usando a mesma função sendFileToSharepoint implementada anteriormente.

gulp.task('sync', function() {
  var watch = require('gulp-watch');
  watch(['./SiteAssets/**/*.*', './SitePages/**/*.*'])
    .on('change', function(file) {
      sendFileToSharepoint(file);
    });
});

Concluindo

Com apenas três plugins do gulp (spsave, path, watch) e duas tasks (publish e sync) podemos tornar a nossa vida muito melhor implementando no Sharepoint sem o Sharepoint Designer.