Hello world! This is my first post on my shiny new dev2dev blog and needless to say, I'm very pleased to be blogging here and to be given the opportunity to contribute to this prestigious and active community.
That being said, I hope you'll find my contributions worthwhile. I plan to address mostly technical topics pertaining to AquaLogic User Interaction or ALUI (pronounced ah-LOO-eee by those in the know) with the occasional foray into the business side of ALUI and portals in general. I've been working with the ALUI (formerly Plumtree) products now for almost 10 years, but I also know a bit about Weblogic and I want to learn more about the other products in the AquaLogic family. So watch this space for news about all your favorite BEA products!
Okay, on to the topic at hand -- navigation. Once upon a time (pre Plumtree 5.0), UI customization meant hacking through layers of ASP or JSP includes to find the right file and then changing this and that and trying not to break anything. And then when upgrade time came, you somehow had to merge all your changes out of the old UI code and into the new. It was a black art at best, a total goat rodeo at worst.
Enter Plumtree 5.0, which introduced the concept of header, footer and content canvas portlets along with "pluggable navigation." For the first time, you could code your navigation against a supported and documented API and bundle it into a separate DLL or JAR file. When upgrades came along, you simply installed the new code and everything in your old DLL or JAR just worked. The only problem was that writing a pluggable navigation was really hard.
So, in ALUI G6 (the current version), you can easily make a navigation using a remote portlet and few lines of HTML, CSS along with a few handy XML tags. However, the old pluggable navigation model is still in the product, which begs the question: how do I know what form of navigation to use (native or remote)?
A lot of times you'll hear me say, "it depends" i.e. it depends on your goals or it depends on your architecture. But, in this case, with 100% certainty, I can say that you want to go with remote navigation. Why? Because it's about 1000 times easier to code, maintain and deploy, you can change it on the fly and in a breeze, you can include Javascript and CSS just like you would in a normal web page, you don't have to work with confusing HTMLElement classes, you don't have to know Java or C# . . . need I say more?
If you're not sold yet on the concept of remote, XML tag based navigation over native pluggable navigation, consider the following example. Say I want to get all the mandatory with tab communities and display them in an unordered list.
Here's the native code for that:
CListURLMediator mediator = new CListURLMediator(m_asOwner,
m_model.GetCategoryLinks(NavCategoryType.MANDATORYTABS,
false));
HTMLList ul = new HTMLList(1);
while (mediator.Next()) {
HTMLListItem li = new HTMLListItem();
li.AddInnerHTMLElement((HTMLAnchor)mediator.GetEntry());
ul.AddInnerHTMLElement(li);
}
return ul;
And here's the remote code:
<ul xmlns:pt='http://www.plumtree.com/xmlschemas/ptui/'>
<pt:ptdata.mandtabcommsdata pt:id='mandtabcomms'/>
<pt:logic.foreach pt:data='mandtabcomms' pt:var='c'>
<li><pt:core.html pt:tag='a' href='$c.url'><pt:logic.value
pt:value='$c.title'/></pt:core.html></li>
</pt:logic.foreach>
</ul>
The code speaks for itself. (If you never have to learn what a CListURLMediator is, consider yourself lucky.) Not to mention that you have to worry about the NavType and deployment issues and that you have to restart the portal any time you make a change to your navigation code.
So, is remote, tag-based portlet navigation the solution to all your navigation needs? Not exactly. With pluggable navigation, you can control six navigation areas: the top bar, above the header, below the header, the left side, the right side and above the footer. It's easy enough to suppress the top bar and replace the first three areas with your header portlet. Same goes for the footer. But what about the left and right sides? You can't really replace those with portlets unless you use the two narrow columns, which leaves you with only a single portlet column for content.
So you're in a pickle -- you read this post and you're now the world's biggest remote navigation fan -- but you can't use them in left and right navigation. There is a solution. If you read this post in the newsgroups, you'll see that it's possible to write some code that will load a remote portlet into the left and/or right columns. (The only thing I would change about this code is make sure you put the portlet ID in a VarPack instead of hardcoding it.) Using this fairly simple approach, you can have your cake and eat it too.
Comments from BEA dev2dev are listed in date ascending order (oldest first)
thanks
steph
sviau@crea.ca
Posted by: sviau on July 9, 2006 at 7:04 AM
Fortunately, there's a easy way to prevent this from happening using community templates. There's a check box on the "Header and Footer" page of the community template that says "Force Community to use Header and Footer from Experience Definition." You'll want to check this box. Then, as the portal administrator, you can mandate which community templates your community managers can use. Set it up so that your community managers are forced to use the community template with this box checked and you should be good to go.
Posted by: bucchere on July 10, 2006 at 2:38 AM
Posted by: jayparker on January 2, 2007 at 12:28 PM
.platportletHeaderBg {
background-color: red;
}
Posted by: bucchere on January 10, 2007 at 7:13 PM
Posted by: geoffgarcia on October 2, 2007 at 11:26 AM