I spent today figuring out why our Excel to PDF conversion was rounding all numbers to two decimal places (it was StarOffice) and trying out some interesting components - PDF Watermark and ContentCategorizer.
PDF Watermark allows you to chuck a watermark on our PDFs either statically or dynamically. Static means that when a document gets checked in, the watermark is added to the PDF and the result is stored permanently as the web-viewable. Dynamic means that the web-viewable PDF is untouched, but whenever someone tries to see it the watermark is magically added. I found static worked great but the dynamic was a total hit-and-miss.
I was excited by ContentCategorizer and the prospect of tags, automatic metadata assignment and maybe even reading values out of the content itself, like recording the camera used to take a photo. Unfortunately I couldn't figure out how to get it to work. None of that stuff happens out-of-the-box anyway, you need to configure it all, and in true UCM style I mean it does nothing out-of-the-box. The manuals were no help either, this needs a consultant to demo.
Anyway, I was booked in for the "Advanced Site Studio" Oracle course next week but the instructor had his visa rejected. Bugger. I was going to get him/her to write me an "Insert Multimedia" widget for Ephox... now I have to do it myself. After all, the system supports inserting multimedia but, in true UCM style... yeah you know the rest.
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)
Tuesday, 9 December 2008
Latest Upgrades (the joy of)
I've been busy patching, testing and tweaking our UCM. We're finally on the latest, latest* release and I'm pretty happy about how it's performing.
Ephox got an upgrade too and by switching to the "sun" connection method it can actually display images now, yay. I still haven't figured out how to style the editor to look like each of our layouts (each layout has a fixed width) and darned if I know why our Intranet stylesheets aren't reaching Ephox. Wysiwyg editing? Not quite. And the LinkWizard is still as crappy as ever, total fail in Firefox3.
I also noticed that the size of our fonts are different now when launched from IE compared to FireFox. I'm not sure if it's Oracle UCM or Ephox doing it... looking at the Java Console Logs I can see the stylesheet information is loaded, parsed and rewritten according to rules my "launching browser" might understand. For example, here's what happens to my BODY style...
Actual stylesheet reference:
body { color:#000000; font-size: 70%; }
Launching the editor from Firefox:
body {ephox-visible: false;color: rgb(0, 0, 0); font-size: 70%;}
Launching the editor from IE:
BODY {ephox-visible: false;FONT-FAMILY: Verdana, Helvetica, Arial, sans-serif}
"I mean, I'm on a webpage, I'm editing a webpage, it's rendering a webpage - why force it through Java?" - and now it is trying to emulate the current browser? Wow. Is that ultra-smart or epic-dumb... I'm not sure! However if it's not Ephox doing the css emulation then I do apologise to the folks at Ephox. (I should point out that Ephox is a pretty decent editor with more features than others.)
* Update - I've been advised by metalink support that we're not on the latest release of DynamicConverter. There is a newer one not listed on metalink but available via eDelivery. How are we supposed to find this stuff out?
Ephox got an upgrade too and by switching to the "sun" connection method it can actually display images now, yay. I still haven't figured out how to style the editor to look like each of our layouts (each layout has a fixed width) and darned if I know why our Intranet stylesheets aren't reaching Ephox. Wysiwyg editing? Not quite. And the LinkWizard is still as crappy as ever, total fail in Firefox3.
I also noticed that the size of our fonts are different now when launched from IE compared to FireFox. I'm not sure if it's Oracle UCM or Ephox doing it... looking at the Java Console Logs I can see the stylesheet information is loaded, parsed and rewritten according to rules my "launching browser" might understand. For example, here's what happens to my BODY style...
Actual stylesheet reference:
body { color:#000000; font-size: 70%; }
Launching the editor from Firefox:
body {ephox-visible: false;color: rgb(0, 0, 0); font-size: 70%;}
Launching the editor from IE:
BODY {ephox-visible: false;FONT-FAMILY: Verdana, Helvetica, Arial, sans-serif}
"I mean, I'm on a webpage, I'm editing a webpage, it's rendering a webpage - why force it through Java?" - and now it is trying to emulate the current browser? Wow. Is that ultra-smart or epic-dumb... I'm not sure! However if it's not Ephox doing the css emulation then I do apologise to the folks at Ephox. (I should point out that Ephox is a pretty decent editor with more features than others.)
* Update - I've been advised by metalink support that we're not on the latest release of DynamicConverter. There is a newer one not listed on metalink but available via eDelivery. How are we supposed to find this stuff out?
Wednesday, 15 October 2008
correcting links with a validation script
Ok, my personal war on dodgy UCM links continues... had a win when our Oracle consultant visited last week (I know he's reading this :)) and showed me some new tricks with validation scripts.
A validation script is just a bit of JavaScript that can be executed when a contributor tries to save their changes. There is no documentation on validation scripts so I never tried to use them myself... but all they do is run a defined function and throw an alert if the function does not return true. Well our mate suggested we just implement a script that silently rewrites dodgy UCM links and return true.
It's so simple and yet so liberating! Thankyou James.
A validation script is just a bit of JavaScript that can be executed when a contributor tries to save their changes. There is no documentation on validation scripts so I never tried to use them myself... but all they do is run a defined function and throw an alert if the function does not return true. Well our mate suggested we just implement a script that silently rewrites dodgy UCM links and return true.
It's so simple and yet so liberating! Thankyou James.
Friday, 5 September 2008
Surprise! ssWeblayoutUrl
I put a bit of inline javascript in a content item to do an image rollover. After it published though the script was mangled - my mixed use of single and double quotes were all replaced with double quotes.
My code looked fine in Ephox. I tried a few edit+saves and realised my mixed use of quotes was sometimes failing. I complained to the Ephox folks who quickly checked & assured me it was not their product causing the issue. So I went to Content Server and viewed the content item's XML. Sure enough I found the problem - my image references were rewritten as a new Idoc URL format that inserts its own single quotes.
Observe my original code...
<img src="/serverroot/somepath/contentID1.gif" onmouseover="this.src='/serverroot/somepath/contentID2.gif';" onmouseout="this.src='/serverroot/somepath/contentID1.gif';" />
Now see what XML (unencoded) is stored in my content item...
<img src="[!--$ssWeblayoutUrl('somepath/contentID1.gif')--]" onmouseover="this.src='[!--$ssWeblayoutUrl('somepath/contentID2.gif')--]';" onmouseout="this.src='[!--$ssWeblayoutUrl('somepath/contentID1.gif')--]';" />
Hey wow! My URLs are magically replaced with some new Idoc link format... that screws up my quote groups! Gee, thanks guys.
Anyway I got around the problem by making my javascript first use an empty string and then appending the URL. Here's how it gets stored now..
<img src="[!--$ssWeblayoutUrl('somepath/contentID1.gif')--]" onmouseover="this.src=''+'/serverroot/somepath/contentID2.gif';" onmouseout="this.src=''+'/serverroot/somepath/contentID1.gif';" />
UPDATE:
I was fumbling around metalink when I discovered this gem: ssWeblayoutUrl can be configured to only use dDocName - no path required! Yay! Now we can fiddle with our image security without fear of broken links (except in javascript, of course :)) just put this in your config:
SSWeblayoutUrlUsesDocNames=true
Refer to metalink article 579457.1
UPDATE #2:
I'm playing with the new format, here are my findings...
* apparently it is only used on img tags - not links. Bummer...
* it will redirect to the latest available revision - contributor mode links to revisions in workflow, non-contributor mode gives you the latest released instead. Nice!
here's how it looks:
<img src="[!--$ssWeblayoutUrl('contentID')--]" />
UPDATE #3:
The bad news is that if the contentID is invalid or does not exist, it throws an error... more importantly, the editor will fail to load any content at all! Youch!
The good news is that the latest release of sitestudio(build298) is supposed to resolve the bug and also uses the new URL format on link tags.
UPDATE #4:
Finally got authority to upgrade and yes, ssWebLayoutUrl is a total kickarse auto-replacement for image src URLs but no, it doesn't seem to replace other weblayout links automatically. Maybe I should update my validation script to do it...
My code looked fine in Ephox. I tried a few edit+saves and realised my mixed use of quotes was sometimes failing. I complained to the Ephox folks who quickly checked & assured me it was not their product causing the issue. So I went to Content Server and viewed the content item's XML. Sure enough I found the problem - my image references were rewritten as a new Idoc URL format that inserts its own single quotes.
Observe my original code...
<img src="/serverroot/somepath/contentID1.gif" onmouseover="this.src='/serverroot/somepath/contentID2.gif';" onmouseout="this.src='/serverroot/somepath/contentID1.gif';" />
Now see what XML (unencoded) is stored in my content item...
<img src="[!--$ssWeblayoutUrl('somepath/contentID1.gif')--]" onmouseover="this.src='[!--$ssWeblayoutUrl('somepath/contentID2.gif')--]';" onmouseout="this.src='[!--$ssWeblayoutUrl('somepath/contentID1.gif')--]';" />
Hey wow! My URLs are magically replaced with some new Idoc link format... that screws up my quote groups! Gee, thanks guys.
Anyway I got around the problem by making my javascript first use an empty string and then appending the URL. Here's how it gets stored now..
<img src="[!--$ssWeblayoutUrl('somepath/contentID1.gif')--]" onmouseover="this.src=''+'/serverroot/somepath/contentID2.gif';" onmouseout="this.src=''+'/serverroot/somepath/contentID1.gif';" />
UPDATE:
I was fumbling around metalink when I discovered this gem: ssWeblayoutUrl can be configured to only use dDocName - no path required! Yay! Now we can fiddle with our image security without fear of broken links (except in javascript, of course :)) just put this in your config:
SSWeblayoutUrlUsesDocNames=true
Refer to metalink article 579457.1
UPDATE #2:
I'm playing with the new format, here are my findings...
* apparently it is only used on img tags - not links. Bummer...
* it will redirect to the latest available revision - contributor mode links to revisions in workflow, non-contributor mode gives you the latest released instead. Nice!
here's how it looks:
<img src="[!--$ssWeblayoutUrl('contentID')--]" />
UPDATE #3:
The bad news is that if the contentID is invalid or does not exist, it throws an error... more importantly, the editor will fail to load any content at all! Youch!
The good news is that the latest release of sitestudio(build298) is supposed to resolve the bug and also uses the new URL format on link tags.
UPDATE #4:
Finally got authority to upgrade and yes, ssWebLayoutUrl is a total kickarse auto-replacement for image src URLs but no, it doesn't seem to replace other weblayout links automatically. Maybe I should update my validation script to do it...
Wednesday, 30 July 2008
No new LinkWizard, just recommendations
Good new and bad news, folks.
The bad news is my employer refused to let me write a LinkWizard replacement. The good news is that I sent Oracle a reasonably comprehensive report about link management - what the problems are and what the solutions might be.
Naturally my first recommendation was to replace the LinkWizard. A new version should take any URL entered by the user and convert it into a SiteStudio link. This kind of pre-processing would eliminate common mistakes, like entering a SSPU-published URL. I even supplied a new interface that does away with the "wizard" style of annoying steps and offers an intuitive "properties" style interface. I also recommended they junk AJAX and just use a simple (fast) IDOC/JavaScript combination.
I then suggested that ssLINK tokens should be enhanced to include the file format of the target. This would allow a contributor to link to a content item and choose the web page version, PDF version or the native file version, without having to be trained in copying URLs from the Content Information page.
Next I proposed a "friendly" URL solution where horrible Content Server URLs like /content/groups/public/documents/doc/contentID.pdf could be replaced with intelligent URLs like /about/link-management.pdf. Wouldn't you love that!
I had a couple more suggestions including upgrades to the LinkManager component. I have no idea what will come of the report but here's hoping that they will do something about links.
The bad news is my employer refused to let me write a LinkWizard replacement. The good news is that I sent Oracle a reasonably comprehensive report about link management - what the problems are and what the solutions might be.
Naturally my first recommendation was to replace the LinkWizard. A new version should take any URL entered by the user and convert it into a SiteStudio link. This kind of pre-processing would eliminate common mistakes, like entering a SSPU-published URL. I even supplied a new interface that does away with the "wizard" style of annoying steps and offers an intuitive "properties" style interface. I also recommended they junk AJAX and just use a simple (fast) IDOC/JavaScript combination.
I then suggested that ssLINK tokens should be enhanced to include the file format of the target. This would allow a contributor to link to a content item and choose the web page version, PDF version or the native file version, without having to be trained in copying URLs from the Content Information page.
Next I proposed a "friendly" URL solution where horrible Content Server URLs like /content/groups/public/documents/doc/contentID.pdf could be replaced with intelligent URLs like /about/link-management.pdf. Wouldn't you love that!
I had a couple more suggestions including upgrades to the LinkManager component. I have no idea what will come of the report but here's hoping that they will do something about links.
Subscribe to:
Posts (Atom)