Check out this fabulous tip on Kyle's blog - provided by my old Stellent mentor and all-round nice guy Ed Bryant.
I'm gonna go replace my UCM search pages right now...
Ideas, tips, rants and other observations about web development & Oracle's WebCenter Content.
Labels
accessibility
(2)
ADF
(1)
archiver
(3)
cmu
(1)
contributor
(13)
cookie
(1)
DAM
(3)
date
(3)
download
(3)
dynamic list
(4)
ephox
(5)
fatwire
(1)
fck
(1)
filters
(1)
folders
(4)
headers
(2)
IBR
(3)
ImageAlchemy
(3)
java
(4)
javascript
(2)
layout/template
(4)
link
(6)
locale
(2)
multilingual
(1)
rendition
(3)
replicator
(4)
rules
(1)
schema
(1)
search
(11)
sites
(1)
sitestudio
(24)
ssp/sspu
(5)
SSUrlFieldName
(2)
stellent
(4)
timezone
(1)
urm
(1)
weblogic
(1)
workflow
(2)
Friday, 22 January 2010
Monday, 4 January 2010
Contribution Folders: Same Same But Different
There seems to be a lot of people who misunderstand the Contribution Folders feature of UCM. Crikey, half the features seem to be misunderstood. Things like UCM security Accounts being mistaken for Microsoft Active Directory accounts, or SiteStudio website Sections being confused with directories in a website. Like a popular t-shirt in Cambodia says, they are "Same Same But Different."
Contribution Folders may look like regular directories or folders on your desktop but they are definitely not the same thing and definitely should not be used the same way. So what is a Contribution Folder anyway? Glad you asked.
A Contribution Folder is a fancy name for a webDAV access point. It allows you to drag-n-drop files from your machine right into the Content Server. How cool is that? However, the Content Server is not a filesystem like your computer, it's a content management system organised by metadata. The Contribution Folders are just virtual folders - they don't physically exist; there are no corresponding directories in the filesystem. A Contribution Folder is just a metadata value attached to a content item.
Think of them more like the "labels" feature in Gmail. A bunch of emails with the same label can all be displayed together or modified together, regardless of where they are located in your mailbox. Contribution Folders work in a similar way. There is a slight difference though; you can't have more than one folder assigned to an item. This makes folders unsuitable for organising your content, so only use folders for the easy drag-n-drop experience.
Now here's the tricky part. Content management requires all content to have metadata assigned. So it's easy to drag-n-drop your files into the system, but what metadata will it get? What security group is applied? This is where the Contribution Folder takes over. The folder itself can be preset with metadata that gets automatically applied to all files dragged inside it. So if you drop 15 images into the folder, all 15 get the same security group applied. Pretty neat, eh? No more pesky checkin forms. But what happens when you need to apply a different security group? Well, just create a different folder and drag into it. But now things start to get tricky. Which folder do you drag into? What happens if you use the wrong one? How deep do your folders go? Who is assigning the correct metadata to the folders? How much does a Cambodian t-shirt cost anyway? Folder management is tricky for the sysadmin and easily abused by contributors, so keep their use to a minimum.
Here's a few pointers about using folders:
Contribution Folders may look like regular directories or folders on your desktop but they are definitely not the same thing and definitely should not be used the same way. So what is a Contribution Folder anyway? Glad you asked.
A Contribution Folder is a fancy name for a webDAV access point. It allows you to drag-n-drop files from your machine right into the Content Server. How cool is that? However, the Content Server is not a filesystem like your computer, it's a content management system organised by metadata. The Contribution Folders are just virtual folders - they don't physically exist; there are no corresponding directories in the filesystem. A Contribution Folder is just a metadata value attached to a content item.
Think of them more like the "labels" feature in Gmail. A bunch of emails with the same label can all be displayed together or modified together, regardless of where they are located in your mailbox. Contribution Folders work in a similar way. There is a slight difference though; you can't have more than one folder assigned to an item. This makes folders unsuitable for organising your content, so only use folders for the easy drag-n-drop experience.
Now here's the tricky part. Content management requires all content to have metadata assigned. So it's easy to drag-n-drop your files into the system, but what metadata will it get? What security group is applied? This is where the Contribution Folder takes over. The folder itself can be preset with metadata that gets automatically applied to all files dragged inside it. So if you drop 15 images into the folder, all 15 get the same security group applied. Pretty neat, eh? No more pesky checkin forms. But what happens when you need to apply a different security group? Well, just create a different folder and drag into it. But now things start to get tricky. Which folder do you drag into? What happens if you use the wrong one? How deep do your folders go? Who is assigning the correct metadata to the folders? How much does a Cambodian t-shirt cost anyway? Folder management is tricky for the sysadmin and easily abused by contributors, so keep their use to a minimum.
Here's a few pointers about using folders:
- Items inside a folder must have unique file names. If you try to drag into a folder a new file with the same filename as an existing item in that folder, it will become a new revision of the existing item.
- Items can be "deleted" from folders. This means they get moved to the "trash" folder. However those items still turn up in search results and appear in websites! You'll need to delete from the trash folder to destroy the item.
- Contribution Folders should only be present on your contribution instance. They should definitely not be used in consumption and there's little to no reason for using them on dev or testing environments.
- Should you require folders installed on two or more connected environments, keeping them in sync is problematic. There is no way to control the creation of folder IDs (it is sequential only) so you must use the replication procedure, which is a tricky thing to set up. Never create folders on the other environments or you'll break your replication.
- Each folder slows down your system. There is a default limit of 1000 folders. If you reach that limit... well, you're not using them properly. Read this post again!
Saturday, 21 November 2009
Cookie monster
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...
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...
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 ;)
Subscribe to:
Comments (Atom)