Why Fat Browser Clients are Evil

I spent nearly an hour trying to figure out what was wrong with the deployment package:

Start Import...
Start Import…
Import error message...
Import error message…

When I went to another tab in the browser, the answer became obvious:

What we have here is a failure to communicate!
What we have here is a failure to communicate!
© Scott S. Nelson

Inline Editing with WLP 10.3.2 Content Templates

Carrying on from WLP Content Presenter Portlet Simplified, the next goal is to get the in-line editing from the sample application running because most clients think that is a cool feature and don’t understand why it isn’t available by default. Right now I am almost done, and wanted to blog the progress to date, even if the most important part won’t be done until Monday…

There is a really (really, really) brief instruction in the official documentation to do this here.  I’m sure if you have been building content templates for years that document will be enough, just as I’m sure that if that were the case you won’t be reading this (unless to make tsk-tsk noises at my ignorance). The files to import can be taken straight from there, which is:

  1. Display Template (Outer Template) – <WLPORTAL_HOME>samplesapplicationsportalApp contentPresenterSampleWebsamplePresenterTemplates inlineEditExamplePresenterTemplate.jsp
  2. CM Display Template (Inner Template) That Displays the Content – <WLPORTAL_HOME>samplesapplicationsportalAppcontentPresenterSampleWebsampleCMTemplatesinlineEditExampleCMTemplate.jsp
  3. JSP File that Performs Other Work – <WLPORTAL_HOME>samplesapplicationsportalAppcontentPresenterSampleWebsampleCMTemplatessaveNode.jsp

Now, the first time I tried this, I wanted my own paths and renamed everything. It didn’t work. I’m sure I can rename them now, but at this stage the important thing is to get it working, with re-branding to the custom project being secondary.

The next step is to add these to the wlp-template-config.xml. Where the manual tells you to make your own, I find it much easier to simply go to the merged view and copy in the one from the shared install. While this may make a little more work for future WLP upgrading, it is worth it to me to save the time. With the file now in my project, I get the copy from the sample application and added the nodes to my own application that reference the files imported earlier. The relevant parts of the resulting file are…

Under <content-name-space><name>wlp-content-presenter-single</name>:

      <description>This is the detailed node view for simple HTML content in the Avitek Financial Intranet sample.</description>
      <description>This is the detailed node view with inline editing for simple HTML content in the Avitek Financial Intranet sample.</description>

Under <template-name-space><name>wlp-content-presenter-single</name>:

   <name>Sample Single Item View with Inline Edit</name>
   <description>This is the sample Content Presenter Display Template view for a single item that provides inline HTML editing.</description>

Now, for this to work, you have to create a content type of named “htmlContent”. I created this type with no parent and a primary property named “content” of data type binary.

I’m still testing to find out if the content needs to include “.html” as a suffix to the name.  And, yes, you can by-pass much of this “have to” stuff if you re-write everything, but the goal here is to get it deployed and have business users editing content today 🙂

I thought I had it with that, as I could then set the content in an instance of the Content Presenter portlet as a piece of content of the type htmlContent and see the Edit HTML button, but nothing happened on clicking it. Dang! Running it in FireFox (the project was targeted at IE, otherwise I would have started in FireFox), I found the disconcerting message “wlp dojo is not defined”.

Ok, I haven’t used the Dojo tookit yet. I have been building stuff by hand for so long, I just haven’t had the need to use a pre-built JS framework, even one that is as highly praised as Dojo. So I’m not sure if I went about it the best way to get this fixed, but it was the fastest. I searched through the sample directory until I found dojo.js (in Windows, it was located at [WEBLOGIC_HOME]wlportal_10.3samplesdomainsportalserversportalServertmp_WL_userportalApp4ycmg9beaextdojo-0.4.3-ajax ). I also found that in inlineEditExampleCMTemplate.jsp, the path it was looking for was ${pageContext.request.contextPath}/dojo-0.4.3-ajax/dojo.js. I tried importing it directly to my project from OPOE, but it must be compressed or the path is too long, so I did a copy/paste to a temp directory and imported it from there.

And, viola! It worked.

Now all that is left is to make the web project into a shared library so that I don’t have to turn off validation is my “real” project. If there is anything out of the ordinary with that process I will blog about it here.  Otherwise, go forth and edit.

© Scott S. Nelson