[Build 14] – Building a Converged Phone and PC App using HTML and JavaScript

Mail de Mehdi
Vendredi 4 avril 2014 10:25

Building a Converged Phone and PC App using HTML and JavaScript
// Speakers : Ryan J. Sakva et Josh Williams
Le sujet de la session est la création d’une universal app (Windows 8.1 et Windows Phone 8.1) avec WinJS

Au début de la session on nous montre qu’il faut deux defaut.html pour référencer les deux versions de WinJS (phone 2.1 et Windows 2.0)

Le dom explorer fonctionne avec le simulateur windows phone exactement comme avec windows 8.

// Première partie :
Le cycle de vie d’une application avec les différents événements (activeted, checkpoint, settings et error)
Dans l’event checkpoint c’est là où généralement c’est le moment où l’application passe en suspend, on doit donc enregistrer les données de l’appli ici pour pouvoir les restaurer à la réactivation de l’appli (dans l’event activeted)
Settings
Error

// Démo :
– Création d’une listView avec un template pour les items on nous montre comment brancher l’event clique sur un élément de la liste et comment passer un objet dans la navigation (exactement le même code que pour Windows 8.1)
– On nous explique comment styler un item dans une listeView (aucun changement par rapport à WinJS 2.0)

– Maintenant on passe à l’appBar toujours le même code

– On nous rappelle qu’il faut bien scopé les css, parce qu’au fur et à mesure de la navigation les pages de styles se chargent dans le dom sans se décharger (single page).

– On créer une nouvelle page avec un HubControl, des HubSections et un repeater (pour l’instant la page est dans le projet Shared (je pense que cela ne marchera pas pour l’appli Windows Phone et on va probablement déplacer cette page dans les projets spécifiques et créer une page spéciale avec un Pivot)

– On nous parle très rapidement des promises avec la fonction join mais rien de nouveau cela fonctionne exactement de la même manière que dans WinJS 2.0
Le speaker lance l’appli Windows 8.1 => tout fonctionne correctement.

// Ensuite le speaker lance l’appli sur le simulateur Windows phone et j’avais presque raison : l’application marche correctement, mais le hubcontrol n’est pas adapté pour Windows phone (le speaker dit qu’ils n’ont pas eu le temps de l’adapter) et donc comme prévu il crée une copie de cette page dans chaque projet (Windows et WP) et le supprime du projet shared. Il utilise pour la page WP le control pivot. Il essaye de le styler en JavaScript directement mais la démo ne marche pas (probablement une erreur de syntaxe dans la media query).

Fin de la session.
Mehdi

 

 

 

[SPC14] SPC305 // SharePoint Web Templates On-premises and in the Cloud

Mail de Christian

Mardi 04/03/2014 à 17h00

Speaker
Mirjam van Olst – SharePoint Architect @ Avanade Netherlands // MVP

Résumé
Très bonne session sur les WebTemplate que Mirjam conseille d’utiliser à la place des SiteDefinitions.
Que ce soit pour créer des sous-sites ou des collections de sites, c’est l’approche à utiliser.
Pour les sous-sites, il est possible d’utiliser ça dans le cloud. Même pour les collections de sites, c’est possible même si cela nécessite un peu plus de configuration à la création.

// Agenda
Site provisioning options
Web Template fundamentals
WebTemplates and App Webs
Custom solutions for site provisioning

// Site definitions
En SharePoint 2003 et SharePoint 2007, on ne pouvait faire que ça.
Depuis 2010, elle déconseille maintenant cette utilisation qui est faisable que côté full trust solutions.
Pour des questions de changement d’avis de clients (de quoi parle t-elle ? 🙂 ou de lourdeur de migrations etc.

// Web Templates
Introduit en 2010.
On peut créer les webtemplates en full trust ou en sandbox.
Ils ont un mécanisme de mise à jour.

// Site Templates
Créé en save site as template. Faisable en sandboxed.
Utilise les Webtemplates mais contient les fonctionnalités du site originel.
Ils sont faciles à créer mais ne sont pas stables (ne serait-ce quand on créé les champs ou types de contenus custom).

// Custom solutions for site provisioning On peut maintenant créer des Apps (en provider hosted) pour faire du remote provisionin.
On utilise alors les webservice full trust.
Voir la session de mercredi correspondante.

// Web Templates features
On utilise l’élément XML WebTemplate.
La feature qui la déploie est de scope Site ou Farm.
En Site, on peut créer que des sous-sites.
En Farm, on peut créer des collections de sites basées dessus.
On peut faire du on-premise et faire un full trust WSP.
En faisant du Sandbox, on peut déployer en Office 365, mais on ne peut plus mettre du code behind.
Pour ce faire, on va sur Visual Studio, on ajoute un Empty Element dans le projet SharePoint 2013.
On ajoute un fichier onet.xml. Dans le Elements, on va mettre les métadonnées du WebTemplate.
Si nous sommes en Farm Solution, le onet.xml sont stockés dans la feature.
Si nous sommes en Sandbox, on stocke tout en base de données.
Les WebTemplate sont basés sur un site définition, mais ils n’héritent PAS de leur site définition de base.
L’avantage des WebTemplate est qu’ils peuvent être changés après coup.
Dans l’Eléments, dans le noeud <WebTemplate> on a bien un BaseTemplateName, BaseTemplateID, BaseConfigurationID correspondant aux informations de la site def de base.
A noter, on ne peut avoir qu’une seule configuration dans le WebTemplate. Il faut donc créer plusieurs WebTemplates si on veut plusieurs « configurations ».

// Web Template provisioning
Processus de provisioning d’un site avec le Webtemplate.
Le système crée une URL pour le site.
Il lui applique la site def de base (le GLOBAL).
Si on crée une collection de sites : il active les features de scope Site dans l’ordre défini.
Si on crée un sous-site, il vérifie que les features de site collections sont activées.
Ensuite les features de scope Web sont activés.
Ensuite les listes instances du onet.xml sont créées.
Attention donc avec cet ordre, à l’ordonnancement des événements.

// Limitations des WebTemplate
On ne peut créer qu’une seule Configuration.
On ne peut utiliser de Module dans l’onet mais on peut créer des features avec des Module.
Feature Stapling ne fonctionne pas mais il n’y en a pas besoin car les WebTeampltes peuvent être mise à jour même en cours d’utilisation – il faut juste éviter les dépendances.
Les hiérarchies de variations ne sont pas possible, celle-là n’est pas contournante et il faut passer par la site définition – c’est un cas plus rare.

// Web Templates best practices
Il n’y a pas d’information sur les WebTemplate.
La parade : créer une feature scope web cachée. La rajouter au onet. Stocker le WebTemplate ID et son nom dans un property bag (ou une liste).

// DEMO
Elle a créé des solutions farm et sandbox avec des WebTemplate.
// En Farm solution. Le Name du WebTemplate doit matcher.
Elle créé une feature scope Farm où elle met son WebTemplate.
Elle copie le onet qui est dans le hive 15, elle supprime ce qu’elle n’avait pas besoin comme les DocumentTemplates. Elle a laissé une seule configuration.
Elle a copié depuis la feature BaseSiteStapling, les feature staplée à son site.
Elle a ajouté une feature scope Site qui ajoute une WebPart à la galerie, et un property bag qui enregistre en property bag sur la version de son WebTemplate.
Enfin elle a une feature scope Web qui ajoute la WebPart à la page.
Debug —> En déployant, elle peut maintenant créer une collection de sites basée sur son WebTemplate. Une fois créée, elle utilise SharePoint Manager // En Sandbox Elle fait globalement la même chose mais basé sur un PROJECTSITE. Elle s’aperçoit alors que dans l’onet, un module est présent pour la homepage. Elle copie ce module pour l’extraire dans un Module à part entière, qu’elle ajoute à une feature de scope Site.
Pour cette sandbox, il est aussi possible de créer un WebTemplate pour une collection de sites même si cela nécessite plus de travail de configuration. Effectivement il suffit de créer une collection de sites sans modèle (à choisir plus tard). On arrive sur le site, ajoute la solution sandbox, l’active, puis sélectionnons le modèle développé.

// AppWebs
Elle explique le fonctionnement des Apps et des sous-sites créés pour stocker les fichiers de l’App.
On peut créer l’App basée sur un custom WebTemplate.
Le WebTemplate se déploie en scope Web, dans l’App même.
Dans l’AppManifest, on spécifie WebTemplate dans les Properties avec un attribut ID=[GUID de la feature App Web]#[WebTemplate name].

// Custom solutions for Site Provisioning Une App provider-hosted qui provisionne le site et modifie à nos volontés. Jusque à on devait faire un webservice pour créer des collections de sites on-prem.
Maintenant on peut faire du site provisioning de collections de sites sur Office 365 en revanche.
Pour du on-prem, il faut attendre l’évolution de remote provisionning.
Il faut aller voir la session parlant de ça.

Christian