embedded page customization

[Migrated From Jforum.net]

I have a commercial Confluence license, but I want to serve parts of the Wiki to the public, allowing registered users to comment and discuss. I don't have the $8K to upgrade Confluence to handle this. Jforum can definitely handle this commenting aspect, but I need some way to integrate the two. Could somebody knowledgeable about Jforum customization opine about the practicality of the following approaches?

Have jForum at the top level and work as usual, but have the root post of the topics consist of the content of the target Confluence wiki page. Add a new Jforum (square-bracket) markup tag so that authorized users can inline the content of the target Confluence Wiki page being served by my Confluence server, similar to JSP-including.

Similar to previous item, but instead of having the Jforum instance perform the fetch, just write an inline HTML frame and let the browser do the including. I'd think this would be simpler to implement and manage, and more efficient, but I'd have more work dealing with browser compatibility issues around inline frames.

Conversely, leave jForum in its off-the-shelf state ,and display the entire jForum pages inside another page. The content of the jForum topic's root post would just say something like "The document above". Either make a wrapper page that will include or inline-frame the two related Confluence + jForum pages; or modify Confluence to include or inline-frame the entire jForum page after the main Wiki page content.


[originally posted on jforum.net by blaine]

[Migrated From Jforum.net]

There are a couple of ways to do this.

You could create a striped down version of the templates to display just a topic and replies with a minimum of the overall forum navigation needed. Then put this in an iFrame at the end of the wiki page so people can comment.

It should be possible to use Javascript in the jForum new post screen to figure out the parent frame's URL (the wiki page). This could be used to have a "Reference this page" button in the edit menu if you want.

An alternative route might be to look at writing your own code to get information from the jforum DB tables about topics and postings. Then just have a list of the subjects of the replies at the bottom with links that take you to the native jforum interface. Thats where uses read the full comments and reply. I've some some stuff like this with some custom tags (sorry work related and I can't share.. but it's not that hard..). The advantage here is that there is less template mods and it's easier to upgrade over time.

The hard part here would be to link the topic to the page. You might be able to pass this info to the templates via a request parameter or some other mechanism.

Hmm, I wonder if a "hybrid" solution might not be nice. E.g., have a list of recent replies subjects at the bottom of a "normal" page. Then when people click to read or add comments, go to a frame page (I know..yuck..) with the wiki page in a scrollable section at the top and a semi normal jforum session in the bottom. Then you could just javascript to find the top frame's URL info for the "reference this page".

One danger here is if people navigate the top or bottom frames away from the related page/thread. Some Javascript event magic might help with that. E.g. if the top frame changes pages, the jforum frame either goes to the related topic or closes.
[originally posted on jforum.net by monroe]

[Migrated From Jforum.net]

Thanks Monroe. Great insights.

I've made much progress already. Since the jForum interface is so economical, by using conservative permissions, the jForum header is so small and useful that I have no desire to improve it by dynamically generating my own forum header.

'm working on all of the navigation and sizing/scrolling issues, most of which you have anticipated. Fortunately I've done a lot of work with traditional and inline frames before. (Took a massive amount of time to figure out all the tricks the first time). Using the right target settings for BASE and LINK tags, and individual links, results in the right behavior without Javascript for most cases (wrt which frames change).

The only limitation that I knew going in, but which is distasteful to me nonetheless, is the inability to dynamically size the iframe vertically without internal scroll bar. I just put a bunch of white space at the bottom. In the case of a really long forum page, the user will get an internal scrolll bar and can also use my custom button to eliminate the Wiki part and just go to the normal page. I wish vertical sizing/scrolling of iframes worked the same as horizontal (which works fine once you know the quirks of how % works).

I'm not concerned about auto-generating forum Topics or auto-generating links back to the Wiki. When my team wants public access to a Wiki page, they'll create the Wiki topic for it, and the external URL to bring up the "dual page" (regardless of whether the URL is used in a forum entry) is just a simple URL. I've implemented the Spring MVC infrastructure so that this all works right.
[originally posted on jforum.net by blaine]

[Migrated From Jforum.net]

Here's some JavaScript code that (mostly) can resize an i-frame to match the content...

<script language="JavaScript">
<!--
function calcHeight()
{
  //find the height of the internal page
  var the_height=
    document.getElementById('the_iframe').contentWindow.
      document.body.scrollHeight;

  //change the height of the iframe
  document.getElementById('the_iframe').height=
      the_height;
}
//-->
</script>
<iframe id="the_iframe" name="the_iframe" onLoad="calcHeight();" src="/${forumURL}" width="100%" frameborder="0" height="3000">
Sorry, your browser doesn't support IFRAMES!  Try a different browser.</iframe>

[originally posted on jforum.net by monroe]

[Migrated From Jforum.net]

Excellent. I'll give that a try. I had tried the same approach in the past, but the tactics I used to get the sizes either calculated too early or too late (wrt HTML assembly) with the result that the resultant size was not the size that I needed to resize to). If you know this works, then I must not have known about the scrollHeight method.
[originally posted on jforum.net by blaine]

[Migrated From Jforum.net]

The JavaScript's not working for either Firefox or IE. Permission denied on Window.document.

If I inline it and eliminate the object lookup, I get permission failure on the "contentWindow".

I do have a working method (in production for about a year now) that resizes, but it avoids the permission and hierarchy problems by resizing in the content HTML of the child page. I don't want to do that with this project because I don't think the benefit would be worth the extra maintenance work of customizing jForum content. If I could just redeploy the jForum webapp that would be one thing, but since jForum mixes data with the webapp itself, it makes redeployment much riskier and entails much more down time.

I'm starting to believe my previous conclusion that the desired size can't be obtained and then set, excep from the page inside the embedded frame.
[originally posted on jforum.net by blaine]

[Migrated From Jforum.net]

For anybody who's curious, here's my first production iteration:

http://admc.com/confluence/display/tech/Shell+Scripts?forum=13

The URL is just the exact Confluence URL + ?forum=X where X is the corresponding JForum list page number. Not much to see in the forum at the time I'm writing this, since nobody's left any replies yet. I'm only allowing registered users to leave comments.
[originally posted on jforum.net by blaine]