[SPC14] Developing an Intranet on Office 365

Mail de Felipe Mercredi 05/03/13 à 09:00

Speaker, Eric Shupps – SharePoint Server MVP

//Résumé
Pas vraiment de nouveautés, mais beaucoup du déjà vu,
Il nous montre les option disponible pour développer et customisé certains élément SharePoint avec client-side solution et le model oAuth utilisé par SharePoint

//Intro

La session est animé par le cowboy SharePointer, avec son fort accent texan,
Il commence nous disent qui c’est une session pour les développeurs et qui les IT Pro et administrateur peuvent sortir.
Eric nous ressort les famous slide de Apps pour Office 365, donc encore l’emphases sur les apps et office api’s
Après il nous fait une petit introduction sur le concept d’intranet
• Objective, fournit une site avec basée sur le règles métiers pour aider les collaborateurs et augmenté la productivité
• Audience, la solution doit s’adapter à différent types d’utilisateurs
• Expérience, le design doit pas affecté l’interface, donc il doit etre intuitive et facile d’utiliser
• Challenges, haute performance fonctionnel et adoption d’utilisateur final

//Navigation

Selon Eric un de plus grand défi sur Office 365,
Après il nous présente les composants, de façon très basic, (les même qui SharePoint On prem):
• Suiter Bar
o Peut-être customisé avec JavaScript, il nous montre un petit snipet de jQuery, qu’injecte un html avec un lien
• User Menu
o Customisé via JavaScript et Sandbox solution,
o Petit commentaire sur sandbox, pas « depricated » mais c’est la direction choisie par Microsoft dans l’avenir
• Site Settings
o Customisé avec JavaScript et Sandbox solution
• Quick Access
o Customisé via JavaScript et Sandbox solution
• Ribbon
o Customisé via JavaScript, Sandbox et Apps !
o Il nous fait une demo avec un lien dans le ribbon qui nous rediriger vers l’app
o Eric nous montre comme modifier le rubban via an App,
un simple custom actions qui nous avons déjà l’habitude de le faire avec le RegistrationType et RegistrationID
Et nous pouvons utiliser le token « ~appWebUrl » pour avoir l’url de l’app
En contrepartie nous ne pouvons pas ajouter de javascript comme « Command »
• Fil d’ariane
o Cache par défaut dans la master page
o Ne marche pas entre diffèrent site collection
o Customisé via JavaScript
• Top Navigation
o Navigation par métadonnées
 Il marche seulement dans collection de site curent
 Petit demo sur le « custom properties » de la métadonnées
et un code snippet qui montre qu’on peut accéder au termstore via l’api javascript
il profité aussi pour nous montrer qu’on peut utiliser des librarie javascript pour utiliser MvvC où MVC

//Agrégation de contenu
Comme nous savons déjà on peut toujours utiliser CQWP avec de XSLT,
On peut utiliser l’App Part avec CSOM, mais il n’y pas de cross-list site query, donc pour croiser le données nous sommes obligée de requêter chaque list individuellement
Social API, qu’on peut requêter via oData
la CSWP et display templates qui permet de customisé le rendu du résultat,
et finalement il nous mentionnés Search API’s

//Cross Site Publishing,
Ecrire une fois et lire en différents site, en utilisant In place Catalog, mais nous pouvons aussi utiliser la recherche et la search api’s
Eric nous lance une demo qui nous montre une liste avec beaucoup de données qui est affichée dans une app part ajoutée dans une deuxième collection des sites.

//Composed Look
Il nous montre comme déployer un composed look avec un sandbox solution, rien de vraiment nouveau.

//Design Packages
Qui permet de modifier l’interface du SharePoint et ajouter quelques customisation via code.

// Solutions packaging
Un sujet qui pourrait être vraiment intéressant mais pas assez détaille pour qu’on puisse avoir vraiment quelques choses de concret.
• Web Templates disponible sur office 365
• Déploiement de modules
• Déploiement de package via Sandbox solution (easy) mais aussi via une App(challenge)

//Authorization
Il nous explique que oAuth n’est pas une authentification, mais un protocole d’autorisation,
Donc en gros
• l’utilisateur accède l’app,
• l’app demande un token
• Le provider envoi un token au utilisateur
• L’app accède à diffèrent ressource en utilisant le token fournit au utilisateur

//Apps
Ils n’ont plus de temps, il passé très très vite sur l’app model et structure, qu’on connait déjà, donc rien de nouveau
Juste un point important mentionné, l’azure auto-hosted n’est pas conçu pour la production mais plutôt pour les POCs et tester qui permet d’avoir très rapidement un contexte de provider-hosted app

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s