About two weeks back I posted an article on LinkedIn under the same title. It generated a bit off buzz based on feedback I received. The use-cases one could imagine having this feature are endless, if you ask me. If you haven’t seen it yet, check the Youtube footage.
The original idea was drafted by Warren Mull, and I took the raw demo solution to the next step. Why? Because as said, there are endless use-cases and a feature alike has been requested for as long as I have been working with Siebel.
Traditional solution would be to allow multiple Siebel sessions to be opened by end-users, which really, is one of the worst approaches possible for many reasons. The beauty of the Pinnable Views is the fact, that there is no Siebel session tied to it. It acts as a ‘static’ copy or clone if you wish of the original Siebel view. That does mean, the Pinnable View does not allow any further user-interaction (no drill-downs, no navigation, no scrolling). But for the majority of the use-cases, that is no limitation if at all.
So, this post is all about the implementation. Which really, is quite straight-forward. Conceptually it consists of just a few steps:
- A postloader injects the necessary code to display the ‘pin’ and ‘unpin’ buttons;
- When the ‘pin’ button is clicked, it will traverse the DOM’s <head> to identify all the embedded CSS stylesheets. That would allow, to reference these same stylesheets in the ‘cloned’ page;
![headcss]()
- Retrieving the view’s current title (from the <head> section);
- Create a boiler plate HTML document, referencing the previously collected style sheets and page title;
- Generate a new window, which would display as a tab in the browser;
- Cloning the existing view’s ‘_swecontent’ into the new window’s document;
- Push the new windows handle to an array, within the scope of the Siebel application.
No more, no less.
And sure, a bit of additional styling is requires to visualize the ‘siebel-pin’ and ‘siebel-unpin’ glyphs nicely. And about these glyphs: I desired to have a decent ‘unpin’ glyph. But that is non-existent in the fonts delivered with the application. So I choose to create a separate ‘siebelpins’ font-family for that purpose. In a previous article I explained how to go about, creating a new font-family using icomoon.
But this time, I just wanted to create a custom glyph. Not from scratch, but based on the existing ‘pin’ available in the ‘oracle’ font-family, delivered with the Siebel application. So how to go about?
First, you need to get a decent ‘path’ or ‘polygon’ svg. That is easily done with the Icomoon app. Simply import the ‘oracle.svg’ into Icomoon, select the ‘pin’ glyph and have Icomoon generate your font.
It will something be alike shown below. But do not worry, you don’t need to understand what SVG is all about😉
Next I turned to Glyphrstudio, which is a really neat tool to create either from scratch or modify any existing font. As long as you have a path or polygon SVG string available, you’re fine. Simply copy/paste your SVG string and voilá – there you go.
Glyphrstudio provides a neat editor, so just drawing a diagonal line through the ‘pin’ glyph takes little time.
The next step would be exporting your new SVG font. Because we would like to have .svg, .woff, .ttf and .eot representations of the the new font, it’s back to Icomoon again. Import the SVG generated by Glyphrstudio, and save it again. Icomoon will generate a .zip archive with all the goodies inside.
The resulting files .svg, .ttf, .woff and .eot files you can copy to your Siebel’s /public/<lang>/fonts/custom folder.
Alright, so what would need to do code-wise? Let’s walk you through.
It generates a ‘windowsPopups’ array, which will hold any handle to Pinnable Views windows. Why? Well, because otherwise we cannot close them.
Next the buttons get appended to the application menu (if you happen to use the Synergy theme, sure you need to visualize the application menu, or append the buttons to another element).
Forcing to re-paint is required, otherwise the buttons will on initial display be ‘wrapped’ and not shown as a single block.
Next, we define the ‘onclick’ event. The first reference we add is the ‘faviconpin.ico’ which I created. Next it traverses the style sheets, and appends these. Finally the <heads> title is retrieved. The boiler plate HTML is created, the new window is generated and the boiler plate gets written to it. The ‘_swecontent’ portion of the view is cloned, and finally we push the handle to the earlier mentioned array.
To make things a bit more appealing, adding hover functionality. Implementing the ‘unpin’ is as simple as closing all of the windows while looping through the array.
To suppress any non-sense elements on the pinned view, I added a bit of styling to the pinnable view. Remember, that in the first stage I embedded a popup.css?
And this is the tiny bit of content.
Lastly, the needed additions to your theme override. First define the new font-famile ‘siebelpins’ (usually on top of your CSS). Beware that the paths are considered relative from where the override CSS is located. That should be in /files/custom – but if you decided otherwise beware of that.
That it. And of course, you can grab it all here:
- Pinnable views postloader code
- Pinnable views Favicon
- Pinnable views button CSS
- Pinnable views popup CSS
- Pinnable views fonts archive
Enjoy!
– Jeroen
