Something I've never bothered to do until recently was make cookies. I prefer eating them! But it came up the other day at work when the website needed to read and write some cookies.
UCM provides simple idoc functions to read and write cookies, using getCookie(name) and setCookie(name,value,expires.) The problem we had was that the setCookie command would only create a simple, non-secure cookie that was tied to the current sub-domain. We needed more flavour in our cookies!
So, instead of using setCookie I sent my own HTTP headers to do the job with more precision with setHttpHeaders(type,details.) Using this little baby meant I could include whatever cookie ingredients we needed. Here's an example:
<$setHttpHeader("Set-Cookie","myCookieName=myValue; path=/myPath/here/; domain=.topLevelDomain.com; secure=true; httponly=true; expires=0")$>
The cookie can be read back in as normal using the getCookie command... provided the cookie is available, of course. I may have eaten it already. Mmmmmm cookies...
Saturday 21 November 2009
Thursday 25 June 2009
How to get Digital Asset Management to report image details
The Digital Asset Management (DAM) capabilities of UCM are powerful and kick-arse, but often misunderstood. Unfortunately it has a non-Oracle dependency that limits its effectiveness and could cause your management to shy away from implementing it. DAM is supposedly able to plug into any image conversion software but it turns out that it has a dependency on the ImageAlchemy converter. After converting an image, it asks ImageAlchemy to do a report on each image rendition - the size, filetype, dimensions etc - that cannot be reconfigured. Without ImageAlchemy that useful information is lost.
ImageAlchemy is not free - it costs thousands of dollars to purchase. If, like me, you are unable to convince the boss to purchase this non-Oracle add-on you'll find yourself relying on alternative software for conversions. Anything should work just fine - but you have no image information.
ImageAlchemy does offer a free demo version but it is crippled to only convert small images so it cannot be used. It turns out that although the ImageAlchemy demo won't convert images, it can still perform the reports; it just appends a "buy now" disclaimer to the output. If you try to use the demo with UCM, just for reporting, it works fine - except the extra disclaimer message at the end causes UCM to fail the conversion.
The solution is quite simple. Configure DAM to use whatever conversion software to generate images, but set the <$ImageAlchemy$> variable to point at a shell script. Tell the script to accept two parameters - the image filename and a report flag. The script should accept the parameters and execute the ImageAlchemy demo, but instead of just printing the output to the console, pipe the output to a file. Then get the script to output the file to the console but stop at the disclaimer. Eureka! The reporting is complete and the conversion is successful. There is one little hiccup - ImageAlchemy can't read filenames over 80 chars, so make sure your script changes the image path.
ImageAlchemy is not free - it costs thousands of dollars to purchase. If, like me, you are unable to convince the boss to purchase this non-Oracle add-on you'll find yourself relying on alternative software for conversions. Anything should work just fine - but you have no image information.
ImageAlchemy does offer a free demo version but it is crippled to only convert small images so it cannot be used. It turns out that although the ImageAlchemy demo won't convert images, it can still perform the reports; it just appends a "buy now" disclaimer to the output. If you try to use the demo with UCM, just for reporting, it works fine - except the extra disclaimer message at the end causes UCM to fail the conversion.
The solution is quite simple. Configure DAM to use whatever conversion software to generate images, but set the <$ImageAlchemy$> variable to point at a shell script. Tell the script to accept two parameters - the image filename and a report flag. The script should accept the parameters and execute the ImageAlchemy demo, but instead of just printing the output to the console, pipe the output to a file. Then get the script to output the file to the console but stop at the disclaimer. Eureka! The reporting is complete and the conversion is successful. There is one little hiccup - ImageAlchemy can't read filenames over 80 chars, so make sure your script changes the image path.
Tuesday 21 April 2009
Friendly file names component
I was poking around the interwebs when I noticed a useful update over on David Roe's ContentOnContentManagement blog. I mentioned previously in my blog that SiteStudio was capable of friendly filenames and offered a few config tweaks to auto-generate them. Well, David went one better an wrote a component that does all the work. Grab yourself a copy.
http://contentoncontentmanagement.com/2009/03/02/auto-fill-that-friendly-name/
Note that you still need to configure your server for friendly file names. The component has an advantage in that it can detect previously used filenames and increment the name with a number if necessary (1,2,3), whereas my method always appended the contentID (we can't execute any search services). His component doesn't use hyphens to produce SEO friendly filenames though... but if he reads this he'll probably update it to do so ;)
http://contentoncontentmanagement.com/2009/03/02/auto-fill-that-friendly-name/
Note that you still need to configure your server for friendly file names. The component has an advantage in that it can detect previously used filenames and increment the name with a number if necessary (1,2,3), whereas my method always appended the contentID (we can't execute any search services). His component doesn't use hyphens to produce SEO friendly filenames though... but if he reads this he'll probably update it to do so ;)
Friday 30 January 2009
Better SiteStudio "Best Practices" - Generating Navigation
Continuing my theme of scalable best-practice for SiteStudio, it's time to turn our attention to the elephant in the room - generating navigation. SiteStudio comes with dozens of "navigation" fragments that harness the power of dynamically assembling navigation from the site sections. There's plenty of fragments to choose from, they do nifty stuff... but the question nobody seems to ask is "why the hell would you build navigation out of your site sections?"
Building site navigation from site sections might make sense to a content-management developer or even a clueless contributor, but as a web developer it smacks me as fair dinkum madness. Nesting sections (directories) just for a drop-down nav? Thinks of all the redundant jumbled-up URLs, yuck. If you wanna change your nav, you gotta move around site sections, mucking up external links to your site... I could go on, but you know the issues, right?
But you were thinking "dynamically assemble nav, that sounds hi-tech and easier to manager, right?" Wrong. To add a link to your navigation, you need to create a new section with a URL, assign a layout, assign content to the regions, set the section as "include in navigation" plus any other custom section properties. Phew... not so dynamic now, eh? The dynamic bit is the fact that every time someone visits the page it needs to recalculate and reassemble the navigation based on the site hierarchy. Strewth. The nav probably changes once a blue moon yet you're wasting valuable processing power regenerating it on every single page visit. On a site with thousands of sections that's gonna be a significant slowdown! The Oracle dudes will tell you to cache it but that means whenever you do change your nav you won't see nuthin' until the cache expires. Site hierarchy as navigation is horribly impractical.
1. Generate navigation from a content item, not from site sections.
Why bother "generating" navigation when we can just use a content item? It's a CMS, remember! Create a region in your layout for navigation content. The contributor simply edits the assigned content and adds a list of links, links to whatever content or sections or URLs they feel like. Easy! Use a staticlist fragment to offer tighter control over the items, the new 10gR4 SiteStudio uses region templates to finitely control the appearance further. Standard workflow & security can be used to control the nav, it's fast and reusable, and it doesn't expose the project file (site structure) to non-designers.
2. Auto-reuse your navigation content across multiple sections.
Worried about the arduous task of assigning the nav content item to each section's layout? Simply hard-code into your layout that the nav region uses a specific content item. Better still, use a Custom Section Property (CSP) to define a starting section. Then code the layout so that all child sections use the same nav content item as the CSP parent. A site footer is also an ideal use for this approach.
Building site navigation from site sections might make sense to a content-management developer or even a clueless contributor, but as a web developer it smacks me as fair dinkum madness. Nesting sections (directories) just for a drop-down nav? Thinks of all the redundant jumbled-up URLs, yuck. If you wanna change your nav, you gotta move around site sections, mucking up external links to your site... I could go on, but you know the issues, right?
But you were thinking "dynamically assemble nav, that sounds hi-tech and easier to manager, right?" Wrong. To add a link to your navigation, you need to create a new section with a URL, assign a layout, assign content to the regions, set the section as "include in navigation" plus any other custom section properties. Phew... not so dynamic now, eh? The dynamic bit is the fact that every time someone visits the page it needs to recalculate and reassemble the navigation based on the site hierarchy. Strewth. The nav probably changes once a blue moon yet you're wasting valuable processing power regenerating it on every single page visit. On a site with thousands of sections that's gonna be a significant slowdown! The Oracle dudes will tell you to cache it but that means whenever you do change your nav you won't see nuthin' until the cache expires. Site hierarchy as navigation is horribly impractical.
1. Generate navigation from a content item, not from site sections.
Why bother "generating" navigation when we can just use a content item? It's a CMS, remember! Create a region in your layout for navigation content. The contributor simply edits the assigned content and adds a list of links, links to whatever content or sections or URLs they feel like. Easy! Use a staticlist fragment to offer tighter control over the items, the new 10gR4 SiteStudio uses region templates to finitely control the appearance further. Standard workflow & security can be used to control the nav, it's fast and reusable, and it doesn't expose the project file (site structure) to non-designers.
2. Auto-reuse your navigation content across multiple sections.
Worried about the arduous task of assigning the nav content item to each section's layout? Simply hard-code into your layout that the nav region uses a specific content item. Better still, use a Custom Section Property (CSP) to define a starting section. Then code the layout so that all child sections use the same nav content item as the CSP parent. A site footer is also an ideal use for this approach.
Friday 2 January 2009
Better SiteStudio "Best Practices" - Secondary Pages
I've read a few blogs, webcasts and discussions about "best practice" for SiteStudio. They all seem to talk about the same obvious ideas. What I've been thinking about are some real-world issues and solutions, especially for scalability. Here's two I'm playing with now regarding secondary pages.
1. Use Primary Pages sparingly - rely on Secondary Pages
Forgive me for starting with a simple one... but I'm seeing websites where every page is generated from a primary layout. Yuck. This means every new page will need a new section. Every section in the entire site is stored in a single project file which quickly becomes stupidly massive. Only designers can edit sections. Sections need all sorts of settings done right or your site could become corrupted, even vanish. The content workflow processes are useless because sections can't be workflowed, you'll get a site full of sections with blank pages. Avoid this mess by using secondary pages.
What's the difference between primary and secondary? Well, let's start by understanding website sections. A section is the equivalent of a directory on a filesystem. The section however is a "virtual" directory - it's not a physical directory on any filesystem, it doesn't actually exist anywhere, the section is "generated" on demand. Anyway, if I go to a real directory in a normal website, I'll see a directory listing. Actually most websites are set up so that instead of seeing the listing, I'll see a default page, usually called index.htm - sounds familiar? In UCM terms this "default" page is your primary page, assembled using your primary layout. (Example: http://www.mydomian.com/mysite/mysection/index.htm)
But just as a directory can contain any number of files, a section can display any number of web pages. The primary layout can only display the one assigned content item as index.htm - so the secondary layout is used to display any other content item requested as a web page. The region in the secondary layout is not assigned to a particular content item, it is assigned as "replaceable." To see any content item in this section, simply append the ContentID to the section's URL and presto! there it is. Any item whatsoever can appear as a web page in this section (depending on security, conversion settings and so on) so you'll never need to modify any sections ever again! Woohoo! (Example: http://www.mydomian.com/mysite/mysection/ID000001) One final tip on this issue - you can (and usually should) use the same layout as the primary and the secondary, no probs.
2. Generate SEO-friendly filenames using SSUrlFieldName
The problem with secondary layouts is that the filename is just the ContentID, typically just a number with no file extension. Yuck! That's going to ruin your Google ranking and cause all sorts of confusement. (Example: http://www.mydomian.com/mysite/mysection/ID000001)
Give yourself real file names with the config value SSUrlFieldName. Create a metadata field (let's call it Bob) and then append your config.cfg file with SSUrlFieldName=Bob and presto! your web pages now use whatever filename Bob says. There is a catch - old mate Bob must know a unique filename for every content item, regardless of where it gets used. Bob can't talk about two items called about.htm (he gets confused) and expecting your contributors to give Bob the unique filename is delusional. The solution is to auto-generate it using the ContentTitle, the ContentID and a file extension. Replace spaces with dashes, truncate and then remove the leading zeros. (Example: http://www.mydomian.com/mysite/mysection/about-1.htm) Set this up as a global rule (newcheckin onsubmit) on your contribution instance - or as a archiver import rule on your consumption instance.
*****
I'll write a few more of these...
1. Use Primary Pages sparingly - rely on Secondary Pages
Forgive me for starting with a simple one... but I'm seeing websites where every page is generated from a primary layout. Yuck. This means every new page will need a new section. Every section in the entire site is stored in a single project file which quickly becomes stupidly massive. Only designers can edit sections. Sections need all sorts of settings done right or your site could become corrupted, even vanish. The content workflow processes are useless because sections can't be workflowed, you'll get a site full of sections with blank pages. Avoid this mess by using secondary pages.
What's the difference between primary and secondary? Well, let's start by understanding website sections. A section is the equivalent of a directory on a filesystem. The section however is a "virtual" directory - it's not a physical directory on any filesystem, it doesn't actually exist anywhere, the section is "generated" on demand. Anyway, if I go to a real directory in a normal website, I'll see a directory listing. Actually most websites are set up so that instead of seeing the listing, I'll see a default page, usually called index.htm - sounds familiar? In UCM terms this "default" page is your primary page, assembled using your primary layout. (Example: http://www.mydomian.com/mysite/mysection/index.htm)
But just as a directory can contain any number of files, a section can display any number of web pages. The primary layout can only display the one assigned content item as index.htm - so the secondary layout is used to display any other content item requested as a web page. The region in the secondary layout is not assigned to a particular content item, it is assigned as "replaceable." To see any content item in this section, simply append the ContentID to the section's URL and presto! there it is. Any item whatsoever can appear as a web page in this section (depending on security, conversion settings and so on) so you'll never need to modify any sections ever again! Woohoo! (Example: http://www.mydomian.com/mysite/mysection/ID000001) One final tip on this issue - you can (and usually should) use the same layout as the primary and the secondary, no probs.
2. Generate SEO-friendly filenames using SSUrlFieldName
The problem with secondary layouts is that the filename is just the ContentID, typically just a number with no file extension. Yuck! That's going to ruin your Google ranking and cause all sorts of confusement. (Example: http://www.mydomian.com/mysite/mysection/ID000001)
Give yourself real file names with the config value SSUrlFieldName. Create a metadata field (let's call it Bob) and then append your config.cfg file with SSUrlFieldName=Bob and presto! your web pages now use whatever filename Bob says. There is a catch - old mate Bob must know a unique filename for every content item, regardless of where it gets used. Bob can't talk about two items called about.htm (he gets confused) and expecting your contributors to give Bob the unique filename is delusional. The solution is to auto-generate it using the ContentTitle, the ContentID and a file extension. Replace spaces with dashes, truncate and then remove the leading zeros. (Example: http://www.mydomian.com/mysite/mysection/about-1.htm) Set this up as a global rule (newcheckin onsubmit) on your contribution instance - or as a archiver import rule on your consumption instance.
*****
I'll write a few more of these...
Subscribe to:
Posts (Atom)