Teman är väl skräp?
...lite provocerande rubrik kanske, men det är lite så jag känner.
Hos oss designar vi alltid med masterpages och css:er. Det gör att man kan checka ut filerna, göra ändringa, titta hur det blir och sedan checka in när man är nöjd.
Vi fick ärva ett projekt som hade lagt all design i teman istället. Det var helt hopplöst att underhålla. CSS:erna fick editeras blint på servern, sedan kopieras manuellt till de andra servrarna i farmen, sedan iisreset och då fick man se om det blev rätt, samtidigt som besökarna...
Nu skulle man förstås kunna börja i utvecklingsmiljön, där saker ändras och testas och där solutionpaket sedan byggs och deployas till produktionen. Men det gör det knappast enklare och inte direkt såsom redaktörer av publika webbsiter förväntar sig att jobba med små designändringar.
Ändå ser jag ständigt dessa teman dyka upp. I de officiella kurserna, och nu senast som gratisdownloads hos Microsoft. Vad är poängen?
Hos oss designar vi alltid med masterpages och css:er. Det gör att man kan checka ut filerna, göra ändringa, titta hur det blir och sedan checka in när man är nöjd.
Vi fick ärva ett projekt som hade lagt all design i teman istället. Det var helt hopplöst att underhålla. CSS:erna fick editeras blint på servern, sedan kopieras manuellt till de andra servrarna i farmen, sedan iisreset och då fick man se om det blev rätt, samtidigt som besökarna...
Nu skulle man förstås kunna börja i utvecklingsmiljön, där saker ändras och testas och där solutionpaket sedan byggs och deployas till produktionen. Men det gör det knappast enklare och inte direkt såsom redaktörer av publika webbsiter förväntar sig att jobba med små designändringar.
Ändå ser jag ständigt dessa teman dyka upp. I de officiella kurserna, och nu senast som gratisdownloads hos Microsoft. Vad är poängen?
Inlägg i den här diskussionen
-
Permalänk Svar från Ola Oredsson hos -
Jag håller med om att det är betydligt snyggare att anpassa sina sajter med hjälp av egna master pages och css:er, men det som ändå gör teman väldigt användbara är att de är det klart enklaste sättet att anpassa alla systemsidor. Alternativet är att göra ändringar i application.master och det är inget som supporteras av Microsoft.
-
Permalänk Svar från Wictor Wilén hos -
Håller med båda (delvis). Teman fungerar bra och jag upplever det inte problematiskt att underhålla om man gör det som ett WSP paket. Använder man de tio exempel solutions som MS släppt så har man ju 10 bra exempel på hur man löser det snyggt, flytta över dessa solutions till en VS solution och används WSPBuilder istället så funkar det smidigt.
Just application.master är ju den som ställer till det om man lägger allt i master pagen. Man får väl hoppas att kommande version har stöd för en custom application.master :-)
/WW
-
Permalänk Svar från Tobias Zimmergren hos -
Hej,
Teman är bra till en del saker, men har givetvis en del drawbacks precis som de flesta approacher.
Vad jag brukar göra är att göra en provisioning feature som helt enkelt publicerar mina custom master pages tillsammans med min CSS, sen när jag aktiverar featuren så "deployas" mina ändringar på siten (och ev. subsiter) - Då kan man enkelt använda t.ex. SharePoint Designer för framtagningen av masterpagen och css'en, men att man sedan paketerar upp det snyggt med ett .wsp paket och deployar som features. All testning etc. sker på en staging eller utvecklingsmiljö - inte direkt i produktion.
Teman har jag gjort på precis samma sätt, och även en mix av custom themes + provisioning features som deployar mitt tema när man klickar på knappen.
Att arbeta med SPD (SharePoint Designer) direkt mot portalen är så klart också en variant jag gjort. Men oftast när jag gjort det så extraherar jag ändringarna och plockar in i en feature när det ärklart - för att ha det paketerat och då finns också möjligheten att replikera just de ändringarna överallt (alla servrar i farmen, med ett klick - eller på en helt ny SharePoint installation).
-
Permalänk Svar från Wictor Wilén hos
-
Håller med Z.
Gör alltid alla ändringar i prod miljö med solution packages, inget xcopy eller manuellt redigerande. Detta är just en av SharePoints styrkor att har man deployat en solution så kan man enkelt lägga till och ev. flytta en front-end och alla anpassningar flyttas över. Redigerar man på servern blir det problem om man skall skala ut lösningen.
Sedan skall väl man väl helst inte låta redaktörer hålla på att redigera master pages och CSS:er utan detta tas fram på ett kontrollerat sätt som sedan deployas, vilket gör att det inte borde vara något problem. Att låta redaktörer ta hand om "mindre designändringar", är inte så lyckat (talar av erfarenhet). Som vi vet så har alla browsers till exempel sina egna egenheter, och jag tror inte det är många redaktörer som hanterar detta.
Så poängen är att om man använder teman, med tillägg som Z beskriver, så kan man hantera det på ett kontrollerat sätt. SharePoint är ju en stor och komplex men oerhört kraftfull produkt om man nyttjar dess funktioner.
/WW
-
Permalänk Svar från Mattias Nordvall hos
-
Självklart ska inget hamna i 12-hiven utan att det kommer från en solution, det är inget snack om den saken. I det projekt jag beskrev var det från början inte så, men nu är det ordning på torpet.
Men hur som helst så känns det så oerhört besvärligt med teman om vi utgår från problemet "det är för litet radavstånd i ingresserna" och jämför arbetssätten:
* Då måste vi först göra ändringen i Visual Studio, som inte är ett dugg visual i det här fallet, sedan bygga ett nytt solutionpaket, deploya det i en testmiljö, testa hur det blev. Sedan bestämma en tid när man kan deploya i produktion, eftersom deployen iisresettar hela farmen. (Redaktörer som kommer från andra publiceringsverktyg skulle gapa över förfarningssättet)
* Checka ut css:en i Sharepoint Designer, göra ändringen, se direkt hur det blir, testa i olika browsers, låta redaktören godkänna osv. Sedan bara checka in så är det klart.
Application.master är ju ett argument där man faktiskt måste använda teman för att komma åt mallarna. Men det blir ju i så fall av den anledningen att det inte går på något annat sätt, hellre än att det är ett praktiskt sätt.
Men båda sätten överlappar ju helt klart varandra, och css:er kan ju solution-deployas vare sig det är i teman eller i Style library. Hur brukar ni kombinera dem? Använder ni alltid både teman och "vanliga" css:er, och vilka modifieringar lägger ni vart?
-
Permalänk Svar från Tobias Zimmergren hos
-
Tjena Mattias,
Jag skrev tidigare: "Då kan man enkelt använda t.ex. SharePoint Designer för framtagningen av masterpagen och css'en". Jag skulle kanske vart lite tydligare där.
Det innebär att även i en produktionsmiljö använder jag ibland SharePoint Designer - men jag publicerar aldrig ändringarna med SharePoint Designer.
Jag gör ändringarna, kontrollerar hur det blir utan att publicera - på så sätt kan jag modifera och hacka loss tills jag är nöjd utan att behöva bygga några paket - när allt är klart tar jag css'en och drar in i mitt Visual Studio projekt och tjötar igång ett bygge vid tillfälle.
Jag antar att det handlar om en preferens mer än vad som är "bäst". Det arbetssätt som fungerar, är enkelt att replikera och framförallt enkelt för medarbetare att ta över eller förstå - det är det man ska utgå ifrån :-)
Jag gillar att paketera ihop allting så man har en bra revisionshistorik på paketen också - samt att om det temat/designen som tagits fram ska användas på andra ställen så är det på tok mycket enklare att deploya ett paket och få allting färdigt än att behöva ladda upp filerna manuellt :-)
När det kommer till temat's egen CSS vs. custom css som ligger utanför temat så gör jag det lite olika från gång till gång. Ibland använder jag inte teman alls, utan bara en custom .css som jag t.ex deployar till /12/TEMPLATE/LAYOUTS/Zimmergren/myStyle.css och har en feature som talar om för siten att använda den CSS'en som alternate CSS eller dylikt.
För pyttesmå ändringar kan jag köpa att man använder SharePoint Designer - men inte utan att man sedan tar de ändringarna och får med i sitt paket så man har det färdigt vid behov.
© 2010 Skapad av Andreas Kviby
Powered by 
.
