Por falta de familiaridade, ou mesmo por pouca experiência, alguns tem dúvidas quanto a se o MS Office pode ser considerado uma plataforma robusta de desenvolvimento. Muitos desejam saber se o MS Office propicia a construção de aplicativos completamente novos?
O Office permitiu que pelo menos dois perfis de usuários pudessem despir-se dos seus preconceitos, mesmo estando em lados bem opostos: Os desenvolvedores e os usuários.
Muitos desenvolvedores estão desenvolvendo um olhar mais respeitoso para o Office por perceber que a interação e velocidade com que boas soluções são desenvolvidas, libertam-lhes para focarem o seu tempo em projetos com um alcance mais amplo. permitiram-se resolver as questões mais preementes do dia a dia com a integração já propiciada pelo pessoal de Redmond.
Diversos usuários do Office, no mundo todo, especializaram-se e aprenderam a automatizar os seus processos repetitivos nos seus departamentos. Perceberam que podiam compartilhar as suas experiências e resultados. Estes transformaram-se em serviços, produtos e consultorias especializadas.Todos ganhamos! A Microsoft, vendo o seu produto agigantar-se, os usuários desenvolvendo novos nichos de mercado, e os clientes finais, que puderam ter produtos e soluções maduras, sem muito investimento. Com soluções que poderiam receber manutenção por parte de uma crescente base de desenvolvedores VBA (Visual Basic for Applications).
Tradicionalmente o MS Office é visto como um conjunto de aplicativos independentes tais como o MS Word®, MS Excel®, MS Outlook®, MS Access®, MS Powerpoint®. Cada um destes softwares foi desenvolvido para fornecer um rico e extenso conjunto de funcionalidades. E como estas funcionalidades estavam focadas em tarefas específicas no produto que o usuário usava, a interoperabilidade entre os diferentes produtos tornava-se mínima. Por exemplo:MS WordCada usuário sabia escrever texto, fazer malas diretas, criar índices nos seus livros, formular contratos. Conseguia inserir imagens e corrigir os seus textos.
MS ExcelO usuário sabia criar as suas tabelas, formatar os seus dados, alguns conseguiam criar tabelas dinâmicas, outros usavam PROCV, PROCH, etc...MS PowerpointCriar apresentações simples, inserir alguma animação, inserir alguns gráficos.Mas muitos ainda não tinham aprendido a conectar-se a um banco de dados MS Access e a partir dele preencher as suas malas diretas. Outros ainda não usufruíam a facilidade de conectarem as suas planilhas a views do SQL Server que atualizassem os seus gráficos ou as suas tabelas dinâmicas de modo consolidado, sem que precisassem preocupar-se com a limitação de linhas. Muitos outros, até hoje, não fazem ideia de que podem conectar os seus gráficos diretamente num banco de dados, atualizando-os diretamente na apresentação, ao invés de colar dezenas de gráficos em outras dezenas de slides na suas respectivas apresentações.Como o passar do tempo o Office evolui e estendeu a sua estrutura de aplicativos e tecnologias que incluíam os serviços cliente/servidor. Desse modo pôde incorporar mais tecnologias vindas dos produtos: InfoPath®, SharePoint® Services, Content Management® Server e o Exchange® Server.É importante compreendermos que o MS Word®, MS Excel®, MS Outlook®, MS Access®, MS Powerpoint®, além dos demais produtos da suíte, foram projetados intencionalmente para expor explicitamente a maior parte das suas funcionalidades para o consumo externo, como servidores COM. É claro que os arquitetos do Office tinham o desenvolvimento de soluções personalizadas em mente. Como resultado, é possível criarmos facilmente uma solução que conecte de forma transparente vários aplicativos. Além de tudo, um dos componentes do Office, o SharePoint® Services, fornece serviço de portal, serviço de equipe, funcionalidades de fluxo de trabalho e o gerenciamento de conteúdo. Tendo isso em vista, podemos argumentar tranqüilamente que o Sharepoint já é uma plataforma de desenvolvimento bastante abrangente em si mesmo.Uma plataforma de desenvolvimento precisa atender a alguns requisitos básicos, e todos temos as nossas próprias ideias sobre isso. Mas um conjunto mínimo provavelmente incluiria:Serviços Comerciais Genéricos,Pontos de extensibilidade para conectar as soluções aos Serviços Comerciais Genéricos,Um conjunto de ferramentas consistente,Um nível básico de atributos não funcionais que permitam que os Serviços Funcionais sejam úteis na criação de soluções corporativas (Fig. 01).O MS Office não só atende a esses requisitos, como também tem mais dois pontos a nosso favor:Os desenvolvedores que já trabalham com o Windows® tem o conhecimento e a experiência suficientes para tirarem proveito da plataforma Office.A Microsoft lançou várias ferramentas que ajudarão os desenvolvedores a criarem aplicativos com base nessa plataforma.Fig. 01 - Características da plataforma
Fundamentos da plataforma Office
Podemos mapear os requisitos de uma plataforma de desenvolvimento para o Office e começarmos a preencher alguns dos recursos específicos, conforme mostrado na Fig.02. Existe uma série de requisitos básicos que precisam ser atendidos pela plataforma Office:
- Confiabilidade,
- Escalabilidade,
- Segurança,
- Implantação,
- Atualização,
- Reutilização através de divisão em componentes,
- Um modelo de objetos consistente, e
- Compatibilidade de versão.
Fig. 02 Panorama da plataforma de desenvolvimento Office
O Office oferece CONFIABILIDADE de três maneiras:
1º - Os próprios aplicativos do MS Office foram construídos com um alto grau de robustez.
2º - O Office usa várias etapas para proteger-se contra personalizações indevidas. Por exemplo, se um suplemento causar uma falha no nosso aplicativo host, o Office detectará esse problema e colocará o suplemento na lista negra para que não seja carregado no futuro . A maioria das exceções que podem ser geradas por uma personalização ou um suplemento do Office será tratada de modo a não desestabilizar o host. Em alguns casos o aplicativo gerará uma caixa de diálogo informando uma mensagem de erro adequada para que o usuário saiba que o Office está funcionando corretamente, mas que o o suplemento pode estar em um estado indefinido.
3º - O Microsoft® Office SharePoint Server (MOSS) foi construído com os mesmos padrões que outros softwares de servidores da Microsoft. Desse modo, os serviços baseados no Sharepoint também têm esse alto nível de confiabilidade.
Existem duas dimensões para escalabilidade e desempenho: o lado do Cliente e o lado Servidor.
No Cliente, cada aplicativo do Office impõe determinados limites, como o número máximo de linhas e colunas por planilha do MS Excel. Isso torna a escalabilidade previsível - Não podemos simplesmente criarmos uma solução personalizada que exceda esses limites. No entanto, é possível implantarmos soluções que excedam os limites práticos em um contexto em que não haja nenhum limite rígido definido. Por exemplo, não há nenhum limite específico para o número de suplementos que podem ser registrados para um único aplicativo, mas é claro que há os limites práticos. Considere a demanda no desempenho para carregar 15.000 suplementos ao iniciar o Excel. Esse é um bom exemplo de decisão que uma plataforma de desenvolvimento não deve tomar em nome dos consumidores desta.
Quanto ao Servidor, não deveríamos automatizar aplicativos de Cliente do Office no servidor, pelo mesmo motivo que não carregaríamos 15.000 suplementos: simplesmente não é prático, apesar de ser tecnicamente possível. A partir da versão MS Office 2007 os mecanismos de cálculo e outros recursos do Excel no servidor do Sharepoint e dos Serviços do Excel são expostos (Fig. 03).
O Windows SharePoint® Services (WSS) fornece suporte integrado ao fluxo de trabalho, suporte para o ASP.NET, suporte a blogs, wikis e RSS. O MOSS é somado a essa base, introduzindo gerenciamento de conteúdo, inteligência comercial (BI), recursos de planilhas de Serviços do Excel baseados na Web, suporte a formulários do InfoPath, fluxos de trabalho centrados em documentos e listas, e aprimoramentos de pesquisa. Além disso, os serviços do MOSS Business Data Catalog (BDC) permitem a recuperação de informações de sistemas back-end, como aplicativos CRM e ERP.
É verdade que a segurança do Office, no passado, era um tanto difícil de entender por parte dos usuários e difícil de gerenciar pelos administradores. A partir da versão 2007 o modelo de segurança foi completamente reformulado para ser mais compreensível para os usuários, e mais transparente e fácil de administrar, sem perder os seus pontos fortes. O Visual Studio Tools para Office implantou um modelo de segurança mais rígido, mas essa rigidez dificultou a sua administração.
As soluções tradicionais baseadas no Office automatizavam o Office externamente, registravam suplementos de algum tipo (suplementos COM, marcas inteligentes ou dados em tempo real) ou forneciam soluções baseadas em documentos em que a automação era tratada no processo, utilizando o Visual Basic for Application (VBA) incorporado ao documento. A implantação e as atualizações para soluções de automação externa são bem diretas; qualquer solução que precise ser registrada no registro do Windows geralmente tem um conjunto bem definido de processos de implantação ao seu redor, e a atualização simplesmente envolve a instalação de uma nova versão.
Figura 3 Componentes dos Serviços do Excel
A implantação é um problema real somente com as soluções baseadas em documento. A maioria dos documentos é inútil, a menos que os usuários possam modificá-los, mas a modificação de documentos abre a possibilidade de alterar o VBA. Mesmo que você possa evitar isso, o código do VBA ainda pode (e provavelmente irá) se comportar de forma diferente, dependendo dos dados do documento. Você poderá acabar com várias versões da solução, sendo que controlá-las poderá se tornar um pesadelo; o VBA não pode ser usado para controlar a fonte, e a auditoria e a conformidade normativa tornam-se praticamente impossíveis.
O Visual Studio Tools for Office aborda essas questões fornecendo um modelo de implantação muito flexível. As soluções do Visual Studio Tools for Office — tanto suplementos no nível do aplicativo quanto personalizações no nível do documento — permitem que o código seja implantado local ou remotamente, e ambas incorporam atualizações automáticas. Se a implantação for remota, a tarefa administrativa é simplificada, já que os assemblies estão em um servidor em vez de propagados nos desktops dos usuários. Quando o Office carrega uma solução, o tempo de execução do Visual Studio Tools for Office verifica se há uma versão atualizada e, se localizar alguma, baixa automaticamente as atualizações na máquina local.
O modelo de objeto do Office
Conforme observado anteriormente, os aplicativos do Office apresentam interfaces COM. Por exemplo, apesar de você poder focar o objeto Documento do Word e criar uma instância de forma lógica desse objeto independentemente, na prática o processo do Word será executado para atender a esse objeto. Mas, se você realmente quiser uma plataforma de desenvolvimento, desejará que o restante da plataforma esteja disponível, apesar de precisar usar somente um componente em um cenário específico. O componente deve usar quaisquer outros serviços da plataforma necessários, sem que você precise criar uma instância desses serviços manualmente.
Qual é o lugar certo para a divisão em componentes em um contexto de soluções do Office? Muitos clientes constroem seus próprios componentes reutilizáveis específicos do domínio em camadas sobre o Office. Por exemplo, um componente específico de alguma funcionalidade bancária de investimento pode usar o mecanismo de cálculo do Excel. A interface do lado da solução desse componente é específica do domínio, enquanto a interface do lado da plataforma é específica do Excel. Essa abstração permite que o componente funcione em várias versões do Excel, o que é geralmente uma exigência do cliente.
Como alternativa, é possível criar um componente genérico reutilizável que seja neutro em relação ao aplicativo host. Considere, por exemplo, um UserControl que utilize serviços da Web para exibir dados em um painel de tarefas personalizado. O mesmo controle poderia ser reutilizado em vários aplicativos do Office.
Os aplicativos do Office evoluíram ao longo do tempo e têm conjuntos de funcionalidades muito diversificadas; portanto, eles apresentarão inevitavelmente diferentes modelos de objetos. Isso posto, há uma certa consistência entre os aplicativos. O modelo de objeto é principalmente hierárquico, por exemplo, e há geralmente um objeto Aplicativo na raiz. No Word, você pode começar com o objeto Aplicativo, localizar a coleção Documentos, entrar nos detalhes de objetos Documentos individuais e, depois, em objetos Intervalos individuais. De forma semelhante, no Excel você pode começar com o objeto Aplicativo, ir para a coleção Pastas de Trabalho, localizar os objetos Pasta de Trabalho dentro da coleção e obter objetos Intervalos individuais em uma pasta de trabalho.
Além disso, o Visual Studio Tools for Office é baseado em um modelo de objeto consistente com rigidez de tipos. Você precisa simplesmente observar duas soluções muito diferentes do Visual Studio Tools for Office — ou seja, uma solução baseada em um documento do Excel e uma solução baseada em um aplicativo do Outlook — para ver a consistência. Ambas as soluções apresentam métodos simples de inicialização e encerramento, assim você pode se concentrar nos requisitos comerciais sem se preocupar com as características individuais do aplicativo host. Apesar de ainda ter acesso completo aos modelos de objeto subjacentes, você também pode optar por trabalhar em um nível mais alto de abstração.
A cada nova versão, o Office mantém um nível bem alto de compatibilidade com versões anteriores. Os aplicativos do Office são servidores COM, e o COM impõe várias regras, como a imutabilidade de interfaces, o que garante a proteção contra a incompatibilidade entre versões. O Office, em geral, segue as regras. Todas as interfaces do Office são interfaces duplas ou interfaces puras de despacho. Interfaces vtable puras (e, por extensão, as interfaces duplas) são imutáveis, mas as interfaces de despacho não são, pois o conjunto de funções disponíveis e suas assinaturas podem ser descobertas no tempo de execução (portanto, com ligação tardia). Freqüentemente, a equipe do Office tira proveito disso, incluindo métodos e propriedades adicionais no final de uma interface quando uma nova versão é lançada. Geralmente, os membros da equipe também incluem novos parâmetros opcionais nos métodos existentes. Utilizando essas técnicas, o Office pode preservar a compatibilidade com versões anteriores.
Outra técnica para manter a resiliência da versão é utilizar a tipificação fraca. O exemplo clássico é a interface IDTExtensibility2 que os suplementos COM devem implementar. Quando um aplicativo do Office carrega um suplemento, o aplicativo chama IDTExtensibility2::OnConnection e transmite um objeto sem rigidez de tipos que representa o aplicativo host. No código .NET, esse parâmetro é tipificado como um System.Object, enquanto no C++, é um indicador IDispatch genérico. No tempo de execução, será efetivamente um indicador para o objeto Aplicativo exposto pelo aplicativo host. Quando você cria um suplemento compartilhado tradicional, o código gerado pelo assistente é completamente neutro em relação ao host. Isso fornece dois benefícios: permite que o suplemento seja executado em qualquer aplicativo que forneça suporte a suplementos COM e permite que o suplemento seja executado em qualquer versão desses aplicativos.
O preço pago para esse modelo neutro em relação ao host é o padrão para tipificação fraca e ligação tardia: não há nenhum suporte para o tempo de design ou de compilação para os tipos específicos envolvidos, pois são desconhecidos até o tempo de execução. Isso facilita muito a gravação de código que falhará no tempo de execução. Além disso, a ligação tardia prejudica o desempenho, pois cada chamada ao método precisa passar pelo processo de descoberta para ver se um método coincidente pode ser localizado em tempo de execução.
Ao desenvolver suplementos com o .NET Framework, é possível continuar a usar essa tipificação fraca, mas as vantagens são poucas, a menos que o próprio suplemento forneça somente funcionalidade neutra em relação ao host. Assim que o suplemento precisar fornecer funcionalidade específica do host, você provavelmente usará assemblies de interoperabilidade primária (PIAs), que são específicos da versão. Além disso, é possível usar o Visual Studio Tools for Office para criar suplementos com código .NET. O Visual Studio Tools for Office obriga a tipificação forte, oferecendo os benefícios de IntelliSense® no tempo de design e preenchimento automático, além da verificação de tipos em tempo de compilação. A tipificação forte evita a sobrecarga no desempenho da ligação tardia.
A tipificação forte significa que você perde a resiliência da versão? Não necessariamente. É possível criar um suplemento sem rigidez de tipos em alguma versão do Office e o suplemento muito provavelmente funcionará perfeitamente em versões posteriores do Office. Com o .NET Framework, é possível obter os mesmos resultados, apesar de o comportamento ser ligeiramente mais complicado. Um suplemento .NET criado para uma versão específica dos PIAs do Office também deve funcionar em versões posteriores. Há, na verdade, duas maneiras de se tornar isso possível: o suplemento usa a versão dos PIAs para a qual foi construído ou você implanta um redirecionamento de ligação para os PIAs, de forma que, no tempo de execução, o suplemento utilize uma versão posterior dos PIAs que corresponde à versão instalada do Office.
Pontos de extensibilidade
Desde os primórdios do Office, sempre foi possível estender sua funcionalidade em virtude de os aplicativos cliente do Office serem servidores COM e, assim, eles expõem suas funcionalidades para automação externa. Essa automação pode até mesmo ser incorporada no processo com o aplicativo host, tradicionalmente, utilizando VBA. O Office oferece uma ampla gama de pontos de extensibilidade e podemos entrar nos detalhes do nosso diagrama para fornecer a lista na Figura 4.
Figura 4 Pontos de extensibilidade do sistema Office
Há um grande número de pontos de extensibilidade. É claro que, se você desenvolver um conjunto de aplicativos ao longo do tempo, inevitavelmente terá vários comportamentos — e isso também é verdadeiro para os pontos de extensibilidade. Se você projetasse uma plataforma de desenvolvimento do zero, obviamente projetaria os pontos de extensibilidade para serem os mais consistentes possíveis. Todos nós conhecemos o histórico do Office, mas os pontos de extensibilidade são consistentes em todo o conjunto de aplicativos? Ou seja, é possível conectar-se à mesma parte funcional da mesma forma nos diferentes aplicativos?
Até certo ponto, as técnicas que envolvem algum tipo de automação dos modelos de objeto do Office são consistentes por definição. Ou seja, a maneira como os modelos de objeto são usados tem o escopo definido pelas regras padrão COM e de automação. Os modelos de objeto de aplicativo individuais do Office têm um grau de consistência, mas, na verdade, diferentes conjuntos de funcionalidades. Descendo um nível, a maneira como você codifica um suplemento COM é diferente da maneira como você codifica uma marca inteligente, por exemplo. Isso ocorre porque um suplemento precisa implementar IDTExtensibility2, enquanto a marca inteligente precisa implementar ISmartTagRecognizer ou ISmartTagAction. Obviamente, a única maneira de tornar esses dois conjuntos de funcionalidades mais consistentes seria combinar as interfaces. Embora a idéia de uma única interface de extensibilidade para todos os tipos de funcionalidades de extensibilidade possa parecer atraente, seria muito limitada ou teria um escopo pouco definido.
Em vez de combinar as interfaces, a versão do Office 2007 introduz cinco novas interfaces de extensibilidade que cobrem quatro áreas funcionais. O ponto interessante em relação a essas novas interfaces é que, embora elas sejam muito diferentes em termos de funcionalidade, podem ser todas implementadas através de um suplemento COM padrão. Essa foi uma decisão de design consciente e também é um indicador para o futuro roteiro de extensibilidade do Office. A tecnologia de suplemento COM foi experimentada e testada, é bem compreendida e as ferramentas de desenvolvimento oferecem suporte a ela. Os processos para implantação e manutenção de suplementos também estão bem definidos e são familiares para os administradores. Faz muito sentido fornecer um ponto de extensibilidade consistente dessa forma — não projetando alguma interface única de extensibilidade, mas permitindo que uma única implementação empregue uma ou mais das cada vez mais numerosas interfaces de extensibilidade. Usando essa abordagem, os desenvolvedores e administradores teriam somente um modelo com o qual se preocupar.
Essa convergência de técnicas de extensibilidade no modelo de suplemento parece ser o design para todas as interfaces de extensibilidade do futuro. Ela também poderia ser aplicada em interfaces existentes? Por exemplo, seria possível implementar uma marca inteligente através de um suplemento? Seria possível implementar uma função do Excel através de um suplemento? Tecnicamente, isso pode realmente ser viável, mas provavelmente não é a melhor coisa a fazer. Para as novas interfaces, isso faz sentido, mas a desvantagem de tentar aplicar essa técnica em interfaces antigas é que já existem muitas soluções que utilizam a abordagem antiga. Se fosse possível implementar funções do Excel por meio de suplementos regulares, assim como por meio de suplementos de automação, então você teria duas maneiras diferentes de obter os mesmos resultados. Portanto, o ideal do design convergente trás com ele a implantação divergente. Isso pode ser aceitável em uma fase de transição durante a qual os desenvolvedores migram suas soluções do modelo antigo para o novo. Hoje em dia, os suplementos não oferecem suporte a nenhuma das outras interfaces de extensibilidade antigas, mas este é um caminho possível para o futuro — talvez dependendo da demanda dos clientes.
Enquanto observamos os pontos de extensibilidade, também devemos considerar os formatos de arquivo de documento. Uma maneira de o Office ser extensível é fornecendo acesso programático a seus documentos. Nas últimas versões, o Office introduziu algum nível de suporte para XML. Por exemplo, o Excel 2000 fornecia suporte mínimo para leitura e gravação de XML. Esse suporte foi incrementado e também disseminado para outros aplicativos, principalmente para o Access, o InfoPath, o PowerPoint® e o Word. A versão do Office 2007 fornece suporte para formatos de arquivo XML totalmente abertos para o Excel, o PowerPoint e o Word.
Os formatos XML abertos criam novas oportunidades para desenvolvedores, pois é possível estender soluções através da integração profunda com o conteúdo dos documentos. Isso acompanha o envio de formatos XML abertos à EMCA International como uma proposta de padrão aberto. A Microsoft está trabalhando para fornecer suporte às oportunidades de desenvolvimento independente em várias áreas promissoras. Há até uma nova comunidade técnica de desenvolvedores de código aberto, conhecida como Open XML Formats Developer Group, que inclui 40 líderes de mercado, como a Intel, a Apple, a BP e a Toshiba.
O uso de XML oferece os benefícios de maior transparência e abertura do que era possível com os formatos de arquivos binários anteriores. Os novos formatos permitem que os documentos do Office integrem-se facilmente a sistemas existentes e futuros de linha de negócios, já que o conteúdo agora está aberto e acessível. Isso aborda claramente questões do servidor e de escalabilidade: para muitas soluções, não é necessário automatizar o Office no servidor, pois os arquivos podem ser manipulados diretamente. Os novos formatos também são projetados com robustez e acessibilidade de longo prazo em mente, de forma que danos aos arquivos serão facilmente reparados, e não há nenhuma dependência de nenhum aplicativo de software específico para fornecer acesso ao conteúdo do documento. Os arquivos da versão 2007 também são muito mais eficientes, ocupando muito menos espaço do que os formatos anteriores, permitindo tempos de transmissão mais rápidos e um menor impacto no armazenamento.
Os novos formatos de arquivo representam um grande passo à frente e serão disponibilizados não apenas aos clientes que adotarem a versão 2007, mas também aos clientes que utilizarem versões anteriores do Office. Ferramentas de conversão gratuitas permitem que usuários do Office 2000, Office XP e Office 2003 abram e salvem nos novos formatos, para que todos possam se beneficiar dessa inovação.
O conjunto de ferramentas de desenvolvimento do Office
Um ponto de vista é o de que uma plataforma de desenvolvimento precisa meramente expor seus pontos de extensibilidade e não precisa fornecer também um conjunto de ferramentas. Até certo ponto, a questão é acadêmica, já que a Microsoft, na verdade, fornece ferramentas para desenvolvimento no Office. A questão relevante passa a ser a seguinte: o conjunto de ferramentas fornecido oferece suporte adequado à plataforma?
Usando as ferramentas, é possível criar soluções do Office com várias estruturas e linguagens. Pode-se usar qualquer linguagem que reconheça COM para a automação externa do Office. Você pode usar VBA para a automação interna (baseada em documento) do Office. Ao trabalhar com o .NET Framework, os desenvolvedores poderão usar o Visual Studio Tools for Office se quiserem um conjunto de ferramentas e um tempo de execução estruturados e consistentes.
O VBA abrange um pequeno subconjunto dos pontos de extensibilidade disponíveis, principalmente porque o VBA está restrito a soluções baseadas em documento. As soluções tradicionais de suplementos compartilhados e as do Visual Studio Tools for Office cobrem a maioria dos pontos de extensibilidade. O Visual Studio Tools for Office cobre ligeiramente mais, pois também abrange alguns dos tipos de extensão exclusivos — por exemplo, não é possível criar uma marca inteligente como um suplemento tradicional, mas é possível criá-la como um DLL exclusivo ou um suplemento do Visual Studio Tools for Office.
O tempo de execução do Visual Studio Tools for Office fornece serviços essenciais otimizados para um grande número de soluções. Como alternativa, você terá a flexibilidade de criar soluções sem o Visual Studio Tools for Office se precisar projetar uma infra-estrutura de tempo de execução personalizada. Considere, por exemplo, os suplementos COM: agora, há duas opções de conjunto de ferramentas principais para a criação de suplementos: os tipos de projetos de suplementos compartilhados tradicionais e os suplementos do Visual Studio Tools for Office.
Essa situação está aquém do ideal, no entanto. Uma solução melhor seria um único tipo de projeto com todos os recursos dos suplementos compartilhados e dos suplementos do Visual Studio Tools for Office. Isso é claramente difícil de se obter, considerando que os suplementos compartilhados fundamentalmente não têm rigidez de tipos, enquanto os suplementos do Visual Studio Tools for Office fundamentalmente têm tipo forte. Essa diferença fornece aos suplementos compartilhados a capacidade de funcionar em várias versões do Office e aos suplementos do Visual Studio Tools for Office uma melhor experiência de tempo de design e uma maior robustez de tempo de execução.
Apesar de não ser o ideal, o conjunto de ferramentas otimizado racionalizaria esses dois tipos de projetos para torná-los o mais consistente possível e para facilitar a opção do desenvolvedor. Por exemplo, os suplementos do Visual Studio Tools for Office estão organizados como todos os outros tipos de projetos no Visual Studio, com nós raiz que correspondem à linguagem de programação. Por outro lado, os suplementos compartilhados oferecem ao desenvolvedor a opção de linguagem como uma etapa do assistente de projeto. Outro exemplo é que os suplementos do Visual Studio Tools for Office não oferecem ao desenvolvedor uma opção para a cadeia de texto a ser utilizada no valor de descrição do Registro, pois é possível definir ou alterar isso a qualquer tempo após o assistente ter gerado o projeto. Esse valor, na verdade, nunca é usado pelo Office. Os suplementos compartilhados, por sua vez, solicitam o fornecimento dessa cadeia e, em quase todos os casos, isso é redundante.
Onde o VBA se encaixa no conjunto de ferramentas do desenvolvedor do Office? O VBA foi introduzido originalmente para fornecer suporte ao desenvolvimento não-profissional — ou seja, usuários avançados (profissionais em sua própria área, mas não necessariamente em desenvolvimento de software) que precisavam expandir o conjunto básico das funcionalidades do Office para fornecer soluções mais específicas do domínio. Ele nunca foi destinado ao uso para soluções profissionais altamente sofisticadas, mas tem sido usado nessa função por falta de uma boa alternativa. O Visual Studio Tools for Office está posicionado na outra extremidade do espectro. É uma ferramenta de desenvolvimento profissional que leva todo o potencial do Visual Studio e do desenvolvimento gerenciado para o Office.
É claro que o VBA e o Visual Studio Tools for Office podem coexistir, e há uma sobreposição considerável dos tipos de soluções criadas com essas tecnologias. Para muitas soluções, é possível usar qualquer um dos dois ou, até mesmo, ambos (apesar de essa abordagem provavelmente se limitar a projetos de transição que estão sendo migrados ao longo do tempo a partir do VBA).
O Visual Studio Tools for Office certamente cobre o ponto mais alto da escala e estende-se até o mais baixo, mas não oferece gravação de macro. Essa é uma área em que o VBA ainda é a única ferramenta para soluções não profissionais baseada em interação com o usuário. Novamente, o ideal seria um conjunto de ferramentas para cobrir todo o espectro. Com isso em mente, a Microsoft está se dedicando intensamente ao problema e considerando maneiras nas quais o Visual Studio Tools for Office possa ser usado para cobrir os recursos de gravação de macro de nível mais baixo do VBA.
Benefícios adicionais do Office
Até o momento, defendemos o Office como uma plataforma de desenvolvimento, mas, na verdade, ele oferece muito mais. Considere que a principal interface do usuário do operador de informações é o Office. Isso não é um requisito para uma plataforma de desenvolvimento, mas é claramente um enorme bônus. Os operadores de informações exigem aplicativos criados em torno do Office. A interface do usuário do Office é familiar, o fluxo de trabalho do aplicativo do Office é conhecido e muitas tarefas requerem funcionalidade específica do Office. Mais do que isso, esses profissionais precisam de aplicativos que permitam a interação transparente entre o host do Office e a funcionalidade da solução personalizada.
É possível criar soluções com o Office nas quais sua funcionalidade personalizada funcione de forma transparente com a funcionalidade do aplicativo nativo? As soluções personalizadas parecem fazer parte do host? Considere a interface do usuário de comandos — ou seja, a faixa de opções na versão do Office 2007 e as barras de comandos equivalentes nas versões anteriores. Se você fornece personalização para a faixa de opções ou para as barras de comandos, esses controles e itens de menu personalizados comportam-se da mesma forma que os controles internos. Se você criar uma função do Excel definida pelo usuário, ela poderá ser usada exatamente da mesma forma que uma função interna, apesar de haver uma limitação no nível do suporte da ajuda contextual que pode ser fornecido. As regiões de formulário personalizadas do Outlook foram projetadas para integração transparente com os formulários internos e, na verdade, há várias opções de como essa integração é representada.
A equipe de programação do Office esforçou-se muito para assegurar que os recursos de extensibilidade implementados pelas soluções personalizadas sejam integrados ao aplicativo host da forma mais direta possível. O resultado disso é que o usuário final vê a solução personalizada como uma extensão natural do Office.
Um ponto que vale a pena ressaltar aqui é que o Office expõe pontos de extensão de forma aberta, levando a abusos em potencial. Por exemplo, a exibição de pastas do Outlook permite colocar HTML na janela do Outlook, e o HTML pode incluir controles ActiveX®. Você pode ver como isso pode ser levado ao extremo, já que o Outlook não tem nenhum conhecimento dos controles colocados aqui e não pode impor nenhuma restrição no comportamento desses controles. Em geral, os recursos de extensibilidade do Office fornecem toda a flexibilidade necessária, mas a plataforma deve ser usada de forma sensata.
Plataforma de desenvolvimento séria
Vimos que o Office tem todos os atributos de uma plataforma de desenvolvimento empresarial séria. O Office oferece um amplo conjunto de funcionalidades de linha de base, uma gama de pontos de extensibilidade e a opção de conjuntos de ferramentas para o desenvolvedor. Ele não é perfeito, e há anomalias e inconsistências curiosas. Mas, considerando o histórico do Office, é realmente incrível como o conjunto de aplicativos evoluiu para se tornar uma plataforma coerente. A funcionalidade de linha de base é extremamente abrangente. Os pontos de extensibilidade são um pouco irregulares e poderia haver mais deles. Os conjuntos de ferramentas para o desenvolvedor ainda estão evoluindo e poderiam ganhar com um pouco de racionalização. Portanto, ainda há algum caminho a percorrer, e o conjunto de ferramentas de suporte precisa evoluir no mesmo passo que a própria plataforma, mas as indicações são que a direção estratégica para o futuro do Office é fazê-lo se transformar em uma plataforma de desenvolvimento de nível internacional.
Nenhum comentário:
Postar um comentário