Læs blandt andet om:

• Søgning i nyheder på tværs af alle nyhedskategorier
• Søgemaskinevenlige URL’er når man ser en enkelt nyhed
• Nyheder kan indgå i flere kategorier

Læs hele blog indlæget her: http://blog.bleau.dk/2011/nye-muligheder-i-nyhedsmodulet-i-dynamicweb-8/

It can be tricky to create newsletters in HTML, doing it from Dynamicweb CMS using the Newsletter v/3 does, I am sorry to say, not make things easier. Using the snippet below you get the skeleton of the central news item loop:

<p>Dear <!--@DWUserName--></p>
<table>
<!--@LoopStart(ItemsLoop)-->
<tr>
<td>
<a href="<!--@LoopStart(IsSetupDetailLink)--><!--@ModuleDetailLink--><!--@LoopEnd(IsSetupDetailLink)-->"><!--@NewsHeading--></a>
<br />
<!--@If Defined(NewsManchet)-->
<!--@NewsManchet-->
<!--@EndIf(NewsManchet)-->
<!--@If Not Defined(NewsManchet)-->
<!--@NewsText#100-->&#8230;
<!--@EndIf(NewsManchet)-->
<br />
<a href="<!--@LoopStart(IsSetupDetailLink)--><!--@ModuleDetailLink--><!--@LoopEnd(IsSetupDetailLink)-->">Read more</a>
</td>
</tr>
<!--@LoopEnd(ItemsLoop)-->
</table>

<link rel="stylesheet" href="Blueprint/screen.css" type="text/css" media="screen, projection" />
<link rel="stylesheet" href="Blueprint/print.css" type="text/css" media="print" />

As you might allready have guessed the screen.css will be choosen for screen (read: browser) and projection mode. When printing the print.css will be choosen if you print the webpage. So far so good.

Some times you will have a specific page for print, which say will render only a stripped down version of your content and prompt the user with a print dialogue (using a javascript window.print() line of code). But when you see the page in the browser you are in “screen” media, and the style shown will be as defined in the screen.css. You may confuse the user as he gets a screen version ready for print – and printing it wil result in a version based on the print.css. I have made a jQuery based fix for this situation.

The jQuery fix

The fix will disable any external stylesheets related to screen and make the print.css work on media types “all”. It is coded so that it will check for a “#print” added to the URL. So you should simply make the URL of the printversion have a “#print” in it. Here is the fix:

   1:  <script type="text/javascript" src="http://ajax.microsoft.com/ajax/jQuery/jquery-1.6.2.min.js"></script>

   2:  <script type="text/javascript">

   3:  /* STH: 2011-07-07 Make any stylesheets target for "print" media active on "all" media types (including screen)

   4:      Also disable any layouts for screen

   5:  */

   6:  jQuery(function() {

   7:    var bPrint = (window.location.toString().indexOf('#print')!=-1);  

   8:    if (bPrint) {

   9:      // The user wants to print this page

  10:      jQuery('link[media*="print"]').attr('media', 'all'); // Enable the print styling for all media types, including screen.

  11:      jQuery('link[media*="screen"]').remove(); // remove any styling related to screen

  12:    }

  13:  })

  14:  </script>

The fix above has a link to jQuery, you do not have to include it if you allready have jQuery on your webpage.

Code snippet for creating template for the #dynamicweb paragraph texteditor – mytemplates.xml http://goo.gl/DlUwG

Being logged in to the system as administrator you can get a SQL Query textarea like this one below. You can then enter:

SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_TYPE = 'BASE TABLE'
order by TABLE_NAME

Links

• sql list all tables at whirlpool

   1:    <script language="javascript" xmlns="urn:schemas-microsoft-com:xslt" implements-prefix="js">

   2:      <![CDATA[ 

   3:      // This will return a URI encoded string

   4:      function encodeURL(sUrl) {

   5:        sUrl.MoveNext();

   6:        sUrl = sUrl.Current.Value;

   7:        return encodeURI(sUrl);

   8:      }

   9:      ]]>

  10:    </script>

Find example XSLT here: http://dl.dropbox.com/u/3260327/xslt/js_encodeURL.xslt

Install plug-in on your wordpress blog

There are several plug-ins for wordpress which can use, I found SyntaxHighlighter Evolved interesting and installed it. Simply go in the control panel of your wordpress and click add new plug-in. Search for “SyntaxHighlighter Evolved” and you will find it. Click install and activate!

You may need to do a few setting up:

The Windows Live Writer plug-in

If you use Windows Live Write for direct publishing to a blog like I do you can get a plugin to make your code look nice. You can do so by downloading and installing the free “Code Snippet With Syntaxhighlighter Support for Windows Live Writer” from http://precode.codeplex.com/. Its free and easy to install!

Simply download the MSI file and install it! Next time you start up Windows Live Writer you will have a new option under the “Insert” menu item: “Precode snippet”. Now you simply type or paste your code into the window, change the settings you want. One is ofcause the language, as you can see below in the screenshoot – the red box and arrow.

The result – here on my blog..

Here is example of some code inserted using that module. This code is a Visual studio Snippet. Hope it looks okay

<?xml version="1.0" encoding="utf-8"?>
<CodeSnippet Format="1.0.0" xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
  <Header>
    <Title>DW_IfDefined</Title>
    <Author>Sten Hougaard, 2010 - http://www.netsi.dk/wordpress</Author>
    <Shortcut>dynamicwebIfDefined</Shortcut>
    <Description>Surrounds selected data in Dynamicweb If and If Not defined</Description>
    <SnippetTypes>
      <SnippetType>SurroundsWith</SnippetType>
      <SnippetType>Expansion</SnippetType>
    </SnippetTypes>
  </Header>
  <Snippet>
    <Declarations>
      <Literal>
        <ID>tagname</ID>
        <Default>paragraphImage</Default>
      </Literal>
    </Declarations>
    <Code Language="HTML">
      <![CDATA[<!--@If Defined($tagname$)]]><![CDATA[-]]><![CDATA[-]]><![CDATA[>]]>
      $selected$
      <![CDATA[<!--@EndIf($tagname$)]]><![CDATA[-]]><![CDATA[-]]><![CDATA[>]]>

      <![CDATA[<!--@If Not Defined($tagname$)]]><![CDATA[-]]><![CDATA[-]]><![CDATA[>]]>
      NOT defined
      <![CDATA[<!--@EndIf($tagname$)]]><![CDATA[-]]><![CDATA[-]]><![CDATA[>]]>
    </Code>
  </Snippet>
</CodeSnippet>

You do know getimage.aspx, right?

When you have a design to implement using Dynamicweb CMS and you have a list of items with images – say thumb images, Dynamicweb offers a nice utility which can ensure that the thumbs will have a given dimension. The images are cached on the server, so it is not using unnessesary resources of the server if you use the utility.

The utility can be found on any Dynamicweb soloution here:

http://[hostname]/Admin/Public/getImage.aspx

Enter the URL above and you will get a nice wizard which will dynamically produce what you need inside your templates. You can see the wizard above.

What makes things work for my needs!

To ensure that an image fits inside a container with known dimentions you need to:

• Enter the dimensions (width/height)
• Select the cropping offset: “Keep aspect ratio”

Try the utility by entering a path to an image – you have to start from “/files…”. When that is done, simply press OK and you will get a preview under the “Results” tab, as you can see below.

Using the Image URL in your templates

When you are happy with the results you should copy the “Image URL” path (highlighed with blue in the above image). The URL for my example is:

/admin/public/getimage.aspx?Image=/files/billeder/300×80.jpg&Format=jpg&Width=200&Height=100&Crop=5

If I were to use this path inside a template, I simply would replace the “/files/billeder/300×80.jpg” with a template tag like “<!--@Ecom:Product.ImageLarge.Clean—->”.

I hope this has helped you! I really find this improvement nice!

links

• Dynamicweb Templates
• Finally webdav access to dynamicweb websites
• (en-US) Release Notes, Dynamicweb 7.1.pdf

Min Toyota kontra Dynamicweb CMS

Jeg er den lykkelige ejer af en Toyota. Tidligere ejede jeg en Yaris og da den var ca. 2 år gammel modtog jeg et brev om at man havde konstateret at der kunne opstå et problem med bremserne under visse ekstreme omstændigheder. Jeg skulle bare køre ind til et selvvalgt Toyota værksted og de ville rette fejlen uden beregning. Hverken mig eller værkstedet ville blive lastet for noget i den forbindelse. Det er service!

Og nu til Dynamicweb CMS… Jeg oplever jævnligt at der opdages fejl som opstår på grund af fejl i Dynamicweb CMS. Jeg arbejder jo som sagt professionelt hos en Dynamicweb CMS Partner (Bleau A/S) og det er nok noget der i ovenstående situation med Toyota må være at betragte som at arbejde på et “autoriseret Dynamicweb værksted”. Selv om Dynamicweb CMS også selv finder fejl og retter dem uden beregning gennem hot-fixes, så er situationen fra før med fejlen på bilen i en Dynamicweb CMS verden normalt noget anderledes:

1. Brugeren (chaufføren) oplever at noget ikke fungerer i hans “bil” (hans hjemme side)
2. Han kontakter værkstedet
3. Værkstedet må bruge megen tid på at fejlfinde og bevise overfor Dynamicweb CMS support at fejlen er noget der ligger i selve Dynamicweb
4. Dynamicweb CMS anerkender måske at der er en fejl, men det medfører ikke at fejlen rettes. Fejl prioriteres naturligvis af Dynamicweb CMS.
5. Brugeren må så acceptere at der ikke kommer en løsning “sådan lige”

Som professionel konsulent er det svært

• At forklare overfor kunden at det er kundens problem.
• At kunden vil blive faktureret den tid som vi har brugt på at finde fejl i det system vi har anbefalet dem.
• At problemet ikke umiddelbart er blevet løst.
• At en løsning vil koste yderligere tid (=penge).
• At løsningen ikke nødvendigvis giver en forbedring.

Intet er fejlfrit! – men hvem skal nu betale?

Der er mange elementer i ovenstående sammenligning der kan anfægtes og en sammenligning mellem en bil og et CMS system er måske unfair. Det som jeg her forsøger at starte en diskussion om og brokker mig over er at det ikke er rimeligt at kunderne alene skal betale for noget som kan påvises er fejl i det produkt de har købt.

• Jeg ville personligt aldrig betale for reperationen hvis min fladskærm holdte op med at virke indenfor garentiperioden! Det måtte producenten betale for (gennem forhandleren).
• Jeg mener at det er i alles interesse at fejl rettes, så produktet bliver bedre.

Jeg har ikke en færdig model for hvordan man kunne løse problemet med at få dækket omkostninger ved fejl. Der er tre parter som burde dele omkostningen – brugerne, forhandlerne (partnerne) og Dynamicweb CMS. Idag er det kun de to første der betaler! Jeg tror på sigt at hverken brugere eller forhandlere kan leve med den model!

P.s: Ovenstående står for min egen personlige regning.