Edgar Maucourant - Expert / Formateur SharePoint

Aller au contenu | Aller au menu | Aller à la recherche

mercredi 11 mars 2009

Vue en mode feuille de données (Access Web DataSheet) et répertoires : attention !

Par Edgar le mercredi 11 mars 2009, 18:05 - SharePoint 2007

Bonjour à tous,

Ce post fait suite au précédent (non ??? si si) sur le problème des répertoires et des éléments dans les listes SharePoint.

Pour l'édition en masse des éléments dans les listes SharePoint il existe le mode "feuille de données" qui permet grâce à un composant ActiveX de voir le contenu de la liste au travers d'une interface type 'Microsoft Access'. Ce mode fonctionne très bien pour l'édition y compris avec les répertoires. Ainsi lorsque je me déplace dans un répertoire je ne vois que les éléments de ce répertoire dans la feuille de données, ce qui est parfait.

"Et donc ?" ce disent les plus perspicaces d'entre vous...

Et donc, le problème vient d'ailleurs (comme la vérité...ouais facile je sais...). Le soucis c'est lors de l'ajout de nouveaux éléments. Dans ce cas le comportement est plutôt frustrant puisque peu importe où je me trouve dans la liste les éléments sont créés à la racine...

Après plusieurs recherches et tentatives diverses et infructueuses, je me suis résolu à faire un gestionnaire sur l'évènement ItemAdded qui me permet de déplacer mon élément dans le bon répertoire en fonction de la valeur d'un champ de l'item (oui je sais c'est moche mais là je ne savais pas vraiment quoi faire d'autre à part changer complètement le développement...).

Voici donc le gestionnaire d'évènement :

public override void ItemAdded(SPItemEventProperties properties)
{
   using(SPWeb web = properties.OpenWeb())
   {
      SPListItem item = properties.ListItem;
      SPFile dummyFile = web.GetFile(item.Url);
      this.DisableEventFiring(); 
      dummyFile.MoveTo(web.Url + "/Lists/" + properties.ListTitle + "/" + item["RepName"].toString() + "/" + item.ID + "_.000");
      this.EnableEventFiring();
   }
}

A présent mes créations d'éléments au travers des feuilles de données fonctionnent correctement, mais je n'ai pas testé cette action sur une montée en charge importante donc le code est "fournis tel quel" sans garantie aucune :p

Bon code à tous !

PS : 3 posts dans la même journée je viens de péter mon record :)

2 commentaires aucun rétrolien

Déplacement d'un SPListItem dans un répertoire d'une SPList

Par Edgar le mercredi 11 mars 2009, 15:11 - SharePoint 2007

Bonjour à tous,

Quand il s'agit d'organiser l'information dans des bibliothèques de documents ou des listes SharePoint, il vaut mieux recourrir à des Content Types qu'utiliser des dossiers. Cependant parfois il est tout de même nécessaire d'utiliser des dossiers, notamment quand on nombre important d'items seront à terme stockés dans la liste (à cause de la fameuse barrière des (environ) 2000 items et de la chute de performance induite).

Le soucis lorsque l'on travaille avec des dossiers c'est que la création et le déplacement des éléments depuis le code SharePoint ce n'est pas si simple. On trouve un peu partout sur le net des exemples et des articles pour la création d'éléments dans une bibliothèque ou une liste (c'est la même procédure), par contre pour le déplacement c'est pas la même histoire.

Dans le cadre d'une bibliothèque le problème est assez simplement résolu via l'utilisation du SPFile associé à l'item (SPLIstItem.File) et plus précisement de la méthode MoveTo de cet objet. Par contre dans le cas d'une liste la propriété SPFile de l'objet SPListItem est null, donc impossible de faire le transfert...

Impossible ? non ! Un petit village d'irreductibles développeurs SharePoint (et bloggeurs) a percé le secret de ce déplacement. La méthode est pour le moins inattendue, complètement non documentée (à ce jour je n'ai trouvé qu'un post sur tout le net qui en parle) et très franchement capillotractée !!!

En réalité, en interne même pour les éléments d'une liste il existe bien un objet SPFile, mais celui-ci n'est tout simplement pas associé à l'item via la propriété File... Il faut le récupérer en utilisant la méthode GetFile() de l'objet SPWeb. Une fois que l'on a une référence à cet objet on peut utiliser la méthode MoveTo. Mais là aussi il y a une subtilité, il faut utiliser une URL de destination un peu particulière : URLduSite/Lists/NomListe/Rep/itemID_.000

Oui, oui vous avez bien vu "ID_.000", ce n'est pas très éloquent comme syntaxe mais cela fonctionne (ça sent un peu la bidouille quand même... si quelqu'un a une autre méthode...)

Voici donc un exemple de code (qui suppose que vous ayez déjà récupéré un SPListItem nommé item) :

using(SPWeb web = item.Web)
{
    SPFile dummyFile = web.GetFile(item.Url);
    dummyFile.MoveTo(web.Url + "/Lists/" + item.ParentList.Title + "/NomduRepertoire/" + item.ID + "_.000");
}

Et hop, votre item est transféré dans le bon répertoire, mais j'avoue quand même que cette technique me semble douteuse et j'émets les plus vives craintes sur la pérennité d'une telle méthode avec la future version de SharePoint (2010 ?). En attendant cela fonctionne et m'a tiré une belle épine du pied... (voir le prochain post...)

Bon code à tous !

aucun commentaire aucun rétrolien

CustomSiteAction.xml pour site de publication : fichier de ressource obligatoire !

Par Edgar le mercredi 11 mars 2009, 10:35 - SharePoint 2007

Bonjour à tous,

La plupart des développeurs .Net le savent bien, lorsqu'il s'agit de faire des sites multilingues, en dehors des fichiers de ressources point de salut ! C'est encore plus vrai lorsque vous travaillez avec les fichiers CustomSiteAction.xml, CustomQuickAccess.xml ou CustomEditingMenu.xml.

Ces fichiers que vous pouvez trouvez dans le répertoire EditingMenu de la gallerie de page maîtres (lorsque le site est un site de publication) servent respectivement à modifier

  • le menu "Actions du site" (pour un site de publication),
  • la barre d'outils de modification de page (appelé aussi Authoring Console en anglais)
  • et enfin les menus de cette même barre (Page, Flux de travail, Outils,...).

Vous pouvez y ajouter, remplacer ou supprimer des entrées grâce à des noeuds "ConsoleNode".

Tout ce passe bien tant que vous n'utilisez pas directement d'accents ou de caractères autres que ASCII dans le fichier. En effet le fichier est au format XML mais ANSI par défaut. Si vous indiquez un caractère accentué (par exemple dans une description de menu) le fichier n'est plus conforme (et refuse de s'afficher dans IE par exemple). De plus si vous tentez de l'insérer tel quel dans SharePoint vous obtiendrez un joli message : "L'index se trouve en dehors des limites du tableau" (notez au passage la pertinence du message d'erreur).

"Qu'à cela ne tienne" me diront les plus aguérris, "Enregistre donc ton fichier en UTF-8 !" Et d'autres de rajouter : "banane !"

"Oui mais," rétorquerais-je (pratiquement du tac au tac, le temps de finir mon pain au chocolat...), "là c'est SharePoint qui n'est plus d'accord", il nous renvoit d'ailleurs ce message (encore une fois très explicite...) : "Le noeud spécifié ne peut pas être inséré comme enfant valide de ce noeud, car le noeud spécifié n'est pas du type correct"

"Mais crévindieu" s'exclament-t-alors les plus aguerris de naguerre, "comment qu'cé ti qui font chez Microsoft pour n'en n'avoir des accents dans leurs descriptions, eux ?".

La réponse est simple : fichier de ressource !

En l'occurence le fichier cms.resx que vous pouvez trouvez dans le répertoire "c:\inetpub\wwwrroot\cheminversvotrewebapp\App_GlobalResources\".

Vous savez donc maintenant ce qu'il vous reste à faire... Non ? Et bien, ajouter un nouveau fichier de ressource que vous déploierez grâce à une solution (en utilisant un noeud : ApplicationResourceFile) et faire référence à cette ressource dans vos fichiers de configuration, et vous voilà à présent roi de la modif des menus d'un site de publication.

Bon code à tous !

aucun commentaire aucun rétrolien

samedi 21 février 2009

VSeWSS 1.3 CTP : beaucoup de nouveautés et compatibles x64 :)

Par Edgar le samedi 21 février 2009, 16:09 - SharePoint 2007

Bonjour à tous,

Un message rapide pour vous dire que les Visual Studio extensions for WSS 1.3 en version CTP (Community Technology Preview) sont disponibles à cette adresse :

http://www.microsoft.com/downloads/details.aspx?FamilyID=b2c0b628-5cab-48c1-8cae-c34c1ccbdc0a&DisplayLang=en

J'avais été assez déçu lors de la release de la version 1.2 qui apportait le support pour Visual Studio 2008 mais pas en version x64. Cette version préliminaire 1.3 montre que Microsoft a travaillé dans ce sens, ce qui ne peux que me ravir :p

Beaucoup d'améliorations en vue dans le descriptif. Je n'ai pas encore testé tout ça mais ça à l'air bien fourni :)

Bon code à tous !

aucun commentaire aucun rétrolien

vendredi 13 février 2009

Windows Update, Framework.Net 3.5 SP1, et moteur de recherche MOSS : Pas Bon !

Par Edgar le vendredi 13 février 2009, 10:24 - SharePoint 2007

Bonjour à tous,

Vous l'avez peut-être remarqué, mais Windows Update a modifié la façon d'installer les .Net Framework ces jours-ci. En effet il y a peu encore vous deviez installer le FrameWork 2.0 puis 3.0 puis les SP1 de chaque et ensuite le .Net Framework 3.5 par un installeur à part.

A présent il n'y a qu'une entrée .Net Framework 3.5 SP1 dans WU qui installe les FrameWorks 2.0 SP2, 3.0 SP2 et 3.5 SP1 : wunderbar ! (Comme dirait nos amis d'outre rhin).

Oui mais, il y a un problème connu avec le .Net FrameWork 3.5 SP1 qui empêche l'indexeur du moteur de recherche de MOSS de fonctionner correctement si celui-ci essaie d'indexer le serveur où il se trouve. Ce cas est fréquent pour nous autres consultants qui faisont des machines toute en un, mais aussi pour certains clients qui n'ont qu'un serveur. Du coup plus d'indexation possible et donc plus de recherche :s

Heureusement le problème est connu depuis quelques temps comme en témoigne ce post d'Octobre 2008 (en anglais) :

https://blogs.msdn.com/ronalg/archive/2008/10/27/crawling-issue-with-net-3-5-sp1.aspx

Et la solution aussi !

Elle passe par la modification de la base de registre du serveur, le tout étant expliqué ici (en anglais) :

http://support.microsoft.com/kb/896861/en-us

A noter que cet article de la KB n'est pas réellement rédigé pour corriger ce problème, mais le problème est similaire et la solution fonctionne.

Attention donc à vos prochaines machines toute en un ! Car vous ne pouvez plus installer les Frameworks par WU sans installer le SP1 du 3.5 !

Bon code à tous !

aucun commentaire aucun rétrolien

vendredi 23 janvier 2009

Développement d'applis x86 et SharePoint x64 : pas bon !

Par Edgar le vendredi 23 janvier 2009, 09:13 - SharePoint 2007

Bonjour à tous

Après avoir perdu 1 h de mon temps sur un message d'erreur peu éloquent (étonnant non, de la part de SharePoint ?), je vous livre une info qui après coup semble logique mais qui ne m'a pas sauté au yeux au début.

Si vous avez un SharePoint en x64 (64bits) et que vous développez une application Windows ou console pour utiliser le modèle objet de SharePoint, cette application doit aussi tourner en x64 sinon vous ne pourrais pas vous connecter à SharePoint par le modèle objet. L'erreur arrive lors de la connexion à la collection de site en utilisant :

SPSite siteCol = new SPSite("http://urldemacollectiondesite");

Cette ligne renvoie l'erreur : "L'application Web est introuvable à l'adresse http://urldemacollectiondesite, vérifiez patati, patata...). Ce qui n'est pas du tout explicite.

Dans mon cas, après vérification de l'url, des accès de substitution, des différents paramètrages, tout était conforme et mon application aurait du trouver la collection de site.

En réalité, j'avais passé mon application en cible x86 (32 bits) car j'utilisais le composant d'accès à Access (AccessDataSource) qui ne fonctionne pas en x64. En repassant mon application en x64 (je vous passe les détails de l'investigation :p) tout fonctionnait pour SharePoint mais plus pour Access... Grrrrrrr !!!!

Heureusement Access 2007 dispose d'un module d'export très pratique qui m'a permis d'exporter ma base de données sur le serveur SQL qui fait tourner SharePoint, et du coup j'ai pu utiliser le composant d'accès à SQL Server qui lui fonctionne très bien en x64 ! Bon ça m'a pris juste 1h30 -<:o)

Moralité : ne mixez pas les environnements ou evitez autant que possible ! (qui a dit on le savait déjà ?)

Bon code à tous !

aucun commentaire aucun rétrolien

mercredi 21 janvier 2009

RadEditor et SharePoint (MOSS) "customisé" attention au DocType

Par Edgar le mercredi 21 janvier 2009, 12:16 - SharePoint 2007

Bonjour à tous,

Comme vous le savez peut-être déjà la société Telerik founi (en remplacement de l'éditeur de contenu fourni par Microsoft) un éditeur de contenu compatible avec plus de navigateurs que l'éditeur standand : RadEditor.

Ce contrôle fabuleux (même dans sa version lite), nécessite cependant que la page en cours utilise un DocType compatible XHTML, sinon les barres d'outils flottantes, le gestionnaire de liens et d'images apparaîtront en dehors de la page ce qui n'est ni pratique, ni esthétique, et encore moins professionnel.

Or les pages master par défaut de SharePoint n'utilisent pas un DocType XHTML mais HTML 4.01, donc si vous placez ce contrôle sur la page sans plus de modifications vous vous heurterez aux problèmes sus-mentionnés (wow qu'est ce que je parle bien !!!). Il est donc important (sinon impératif) que vous modifiez le DocType sur votre (vos) page(s) master.

Pour y arriver rien de plus simple, dans votre page master recherchez la ligne (ou quelque chose d'approchant) :

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

et remplacez la par :

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Attention, si votre mise en page est basée sur les CSS, le fait de passer en XHTML peut faire apparaître des défauts qu'il faudra corriger (pour tous les navigateurs...).

Une petite astuce ici : si des défauts apparaissent, avant de tout reprendre assurez vous que le nom de la classe ou de l'identifiant CSS soit bien écrit en respectant la casse. En effet, si une majuscule transfomée en miniscule ne gêne pas HTML 4.01, dans un DocType XHTML la classe ne sera pas du tout appliquée à votre élément ! (Ce qui vous en conviendrez est assez gênant tout de même...)

Morale : passer le plus tôt possible votre DocType en XHTML, cela vous évitera de devoir refaire votre mise en page...

Bon code à tous !

aucun commentaire aucun rétrolien

mardi 23 décembre 2008

WSS 4.0 : Tester la compatibilité de votre code maintenant (enfin bientôt !)

Par Edgar le mardi 23 décembre 2008, 09:51 - SharePoint 2007

Bonjour à tous,

Après un (long) moment d'absence je reviens pour blogger sur cette news quelque peu inquiétante pour tous ceux qui ont fait des views avec du code CAML perso. Le SP2 de WSS et MOSS devrait bientôt sortir (aux dernières nouvelles au mois de février...), il apportera son lot de correctifs et des nouveautés tel que le Pre-Upgrade Checker, un outil vous permettant de tester votre code pour savoir s'il sera compatible avec le futur WSS 4.0 (MOSS 2009/2010 ?). On peut déjà trouver sur la base de connaissance Microsoft quelques infos à ce sujet :

List of all Windows SharePoint Services and SharePoint Server Pre-Upgrade Checker knowledge base articles

A noter donc si on (je) lit correctement que Microsoft mettra l'accent sur le XSLT dans la prochaine version de WSS au détriment de CAML (mais ce n'est que supposition au regard de ces quelques article de la KB). Entre ceci et l'anonce faite par Bill Gate durant sa Keynote à la SharePoint Conférence, il semblerait que pour le développement sur la future plate-forme SharePoint il faudra mettre l'accent sur deux languages par forcement toujours maîtrisé par les développeurs SharePoint à savoir : XSLT et SQL (T-SQL surtout). Tous à vos bouquins / Tutoriaux / Webcasts !!!

Bon code à tous !

aucun commentaire aucun rétrolien

dimanche 3 août 2008

L'install de Telerik Moss Editor a fusillé votre site ?

Par Edgar le dimanche 3 août 2008, 22:49 - SharePoint 2007

Bonjour à tous,

Avant de vous dire comment l'installation du MOSS Editor peut fusiller votre site et surtout comment régler le problème, je voudrais juste faire un rappel pour ceux qui ne connaitraient pas les contrôles Telerik. Ceux sont des contrôles en ASP.Net Ajax (depuis peu) à la norme XHTML 1.1 (un n'est pas compatible), compatibles avec SharePoint et avec tous les grands navigateurs (Firefox, IE, Opera, Safari). On y trouve vraiment des contrôles fantastiques comme des menus très bien faits, des éditeurs de texte puissants, des Combobox avancées, etc... le mieux est d'aller visiter leur site et de regarder les démos c'est assez impréssionant :) -> http://www.telerik.com

Parmis tous ces composants il y en a un qui a particulièrement été développé pour SharePoint : MOSS Editor. Une alternative à l'éditeur de texte fourni dans SharePoint par Microsoft mais compatible avec Safari (sauf liste et indentation, cf la doc). Une version lite (gratuite) regroupant l'intégralité des fonctions de l'éditeur SharePoint standard est dispo ! La version complète quand à elle fournit bien d'autres fonctionnalités très intéressantes.

Intéressons nous maintenant au probème mentionné dans le titre de ce post. Telerik a récement mis à jour ses composants pour ASP.NET Ajax en version Q2, les assemblies sont maintenant en version 2008.2.723.35. Or si vous avez installé ces composants et que vous essayer d'installer le MOSS Editor cela va fusiller votre site avec une erreur très bizarre qui ne donne pas du tout l'origine réelle du problème. Plus aucunes pages ne fonctionnent sur le site (pas même les pages d'application.) et vous vous dîtes que votre lit était finallement si douillet...

Mais ne désespérez point, en réalité le problème et très simple et vient de la modification du fichier web.config lors de l'installation du MOSS Editor. En effet lors de ce processus le programme d'installation modifie le web.config pour ajouter les DLL du MOSS Editor comme Safe de la façon suivante :

<SafeControl Assembly="Telerik.Web.UI, Version=2008.2.723.20, Culture=neutral, PublicKeyToken=121fae78165ba3d4" Namespace="Telerik.Web.UI" TypeName="*" Safe="True" />
<SafeControl Assembly="Telerik.Web.UI, Version=2008.2.723.20, Culture=neutral, PublicKeyToken=121fae78165ba3d4" Namespace="Telerik.Web.UI.Editor" TypeName="*" Safe="True" />
<SafeControl Assembly="Telerik.Web.UI, Version=2008.2.723.20, Culture=neutral, PublicKeyToken=121fae78165ba3d4" Namespace="Telerik.Web.UI.Design" TypeName="*" Safe="True" />
<SafeControl Assembly="Telerik.Web.UI, Version=2008.2.723.20, Culture=neutral, PublicKeyToken=121fae78165ba3d4" Namespace="Telerik.Web.UI.Widgets" TypeName="*" Safe="True" />

Classique me direz-vous, c'est le Delco ! Heu non... c'est la façon de faire, isn't it ? (Je parfais mon anglais :p). 

Oui mais si vous avez déjà installé les versions Q2 de Telerik, certaines DLL sont déjà enregistrées comme sûres. Et il semble que SharePoint n'aime pas du tout, mais alors pas du tout ça, et du coup vous le signifie avec une erreur qui ne signifie rien pour bien vous montrer l'absurdité de la situation :).

Alors ?

Alors que faire pour corriger ce problème ?

Sacré bon dieu va-t-il le dire ???

Oui, oui ca va on y vient, pour une fois que je vous tiens sur un article, je réserve mes effets :)

Donc disais-je pour corriger le problème il faut parler gentillement à SharePoint, et tout d'abord, il vous faut supprimer la première et la troisième ligne (celles comportant les namespaces : Telerik.Web.UI et Telerik.Web.UI.Design). En effet ces lignes ont déjà en principe étaient déclarée en tant que contrôle sûres. Il faut ensuite aussi remplacer la version de DLL (2008.2.723.20) pour les deux autres lignes par 2008.2.723.35. Et Tada ! Votre site refonctionne :) En tout cas pour moi cela a corrigé le problème.

Bien que je n'ai pas fais l'essai, le problème devrait se poser aussi si vous avec les Q1 de Telerik, car la version des DLL est 2008.1.619.35, et posera aussi un problème de conflit. Mais dans ce cas je pense que ce sont les déclarations pour les contrôle Q1 qu'il faudra supprimer (car MOSS Editor nécessite la version 2008.2.723.20 au minimum). Cependant encore une fois je n'ai pas tester ce cas là (ai-je dit que je ne l'avais pas testé ?)

N'hésitez pas à me faire part de vos remarques si cela fonctionne ou ne fonctionne pas chez vous ;). En attendant 'have fun" avec les contrôles Telerik (oui je parfais encore mon anglais ici aussi :)

Bon code à tous !

aucun commentaire aucun rétrolien

samedi 2 août 2008

Vas-y Matt danse danse !!!

Par Edgar le samedi 2 août 2008, 22:04

J'adore ce que fait ce gars !!!

Certains trouveront qu'il n'y a aucune utilité ni aucun intérêt à voir un gars danser un mélange de la stick polka et de la Soggy Bottom Boys Dance partout dans le monde, mais moi ça me fait rêver !

Un peu d'humanité, autre chose que la sempiternelle danse des missiles, des catastrophes et de la misère. Comprenons-nous bien, je ne me voile pas la face, je sais que dans la pluspart des pays du monde on souffre, on meurt et on subit des injustices toute la journée et je ne minimise pas ce fait bien au contraire. Mais ce n'est pas en nous bardant toute la journée de ces images que cela fera avancer les choses au contraire, on arrive à un effet d'accoutumance et comme toujours avec le genre humain à un effet de surenchère dans les images choc. Un temblement de terre au Yémen, des centaines de morts ? Peuh ! L'asie à fait plus de 150 000 morts avec un raz de marée ! Le Yémen aurait pu faire mieux, non !!! Triste réalité...

Voilà pourquoi j'adore ce que fait ce gars, il ramène un peu d'humanité et de joie de ces pays, des images vraies, loin des paysages et autre monument stéréotypés, loin des images choc sensées interpeler ou divertir la populasse...

Vas-y Matt ! Danse, danse et ramène nous tes images, fait nous rêver avec autre chose :)


Matt en 2008


Matt en 2006

Retrouvez le site de Matt : http://www.wherethehellismatt.com

Bon code (et pas de dance) à tous
PS : J'adore même les musiques :p

aucun commentaire aucun rétrolien

- page 3 de 5 -