Phorum and CakePHP ?

Sure and still, time is limited and we need to get some food to live from.

---

Thomas Seifert

Are these "header redirects" limited to jumping off to admin pages?
In that case perhaps it's not an issue. Admin pages are hidden from the user anyway. Admin pages as separate pages are fine.

Or is each view a separate redirect? ....phorum list, message list, message view, etc?

Even then it wouldn't take much--by the enclosing CMS, to handle those redirects--iff they could be recognized as specific to Phorum, then a plugin wrapper could handle the display swaps????? If so the rest would be trivial editing to the template.

The problem with "just dropping it in a div" is that by the time you get to a div, you are in the body of the page (and you can't add things that belong in the page's head section). Phorum needs to add some things to the head section of a page (the redirects, css, scripts, rss feeds). Some CMS systems do allow you to add things to the head section of a page, but there really isn't a universal way of doing this and you might also need a way to access some phorum database values in the head sections (you might also be able to use output buffering if the CMS would support that).



Edited 1 time(s). Last edit at 07/15/2011 07:06PM by DavidVonB.

The only way that I see to make it work as a single drop-in div, is when the full interface is built as a javascript widget. From javascript, one can dynamically add stuff to the header and the interface could be driven dynamically inside a div.

There's also the issue that you have to take care of generating working URLs from Phorum. The default URLs would not work when Phorum is put in a CMS page. Work has to be done to make sure that Phorum generates URLs that are processed correctly by the CMS, while keeping the parameter transport working. Phorum can do this, but is definitely is not compatible with a div drop in widget.

Maybe one day, we'll have a fully widget-driven javascript based UI for Phorum (it's still one of the fun projects on my personal list), but I can assure you that this would be a big project on its own and not a tiny wrapper for Phorum.

---

Maurice Makaay
Phorum Development Team
my blog linkedin profile secret sauce

I'll have to dig into the code. I understand phorum was written in a way that makes use of important information at the head stage. Bear with me. I'm just trying to understand.

I can't for the life of me see why this would be required in the general case, not if you were redesigning from scratch. I'm not asking you to do that. I'm just curious. I wrote a forum from scratch myself and used it for five years or more before I wrote a convert-to-phorum.php script.

Everything I did then was GET or POST parameters, sent from standard URLs or (in a few cases) from Javascript. But my codes always figured out what to do before writing any head information. OK. I'm just ignorant. I will start diving into the low-level codes to see. There must be something basic going on here I don't know about yet.

I spent a year writing a complex GUI with Google's GWT libraries too at one point (Java that compiles into javascript). That was a highly complex front end to an XML database (Exist and/or SleepyCat) that did all sorts of interactive branching. And everything we did could have been stuffed into a div, rather than representing itself as a complete page.



Edited 2 time(s). Last edit at 07/23/2011 09:28AM by salmobytes.

I'll have to dig into the code. I understand phorum was written in a way that makes use of important information at the head stage. Bear with me. I'm just trying to understand.

I can't for the life of me see why this would be required in the general case, not if you were redesigning from scratch. I'm not asking you to do that. I'm just curious. I wrote a forum from scratch myself and used it for five years or more before I wrote a convert-to-phorum.php script.

Everything I did then was GET or POST parameters, sent from standard URLs or (in a few cases) from Javascript. But my codes always figured out what to do before writing any head information. OK. I'm just ignorant. I will start diving into the low-level codes to see. There must be something basic going on here I don't know about yet.

I spent a year writing a complex GUI with Google's GWT libraries too at one point. That was a highly complex front end to an XML database (Exist and/or SleepyCat) that did all sorts of interactive branching. And everything we did could have been stuffed into a div, rather than representing itself as a complete page.



Edited 1 time(s). Last edit at 07/23/2011 09:25AM by salmobytes.

When writing a fully javascripted GUI, it can most certainly be pushed in a <div>. Javascript GUI's modify the DOM tree continuously and the <div> is a container that can be used as the playground for it.

For the javascript code to work, you'd still have to load CSS and core JavaScript code (in your case, the GWT framework). This is part of bootstrapping your application. This bootstrapping takes place in the <head> section of the HTML output. JavaScript code could be read from somewhere inside the body, but CSS code must be added to the <head> section (although adding it to the body works for most browsers too, it is not according to standards and upsets our standards-aware users).

Loading stylesheets on the fly using javascript is possible too. They can be pushed in the <head> dynamically. When writing a javacript application, this is not a problem. The user needs to use a javascript browser to use the application at all. However, in the case of Phorum you are looking at a totally different kind of application. It generates HTML code that is pushed to the browser. No javascript required. The CSS code is put in the <head> by generating the required HTML code for that. JavaScript is only used for enhancing the interface and not as a core technology requirement.

Phorum also figures all of this out, before sending the head. What you describe for GET and POST calls, is exactly what Phorum does.

---

Maurice Makaay
Phorum Development Team
my blog linkedin profile secret sauce

Thank you. I will digest this for a while.

I looked at the "embed" module for the "Vanilla" forum. The Vanilla embed plugin exists as one line of javascript that dynamically inserts an iframe into the current page. I could do that with Phorum now. And I do prefer Phorum to Vanilla for a number of reasons.

I wanted to avoid iframes for SEO reasons. I might have to look at what Drupal does (their forum is a plugin...that I assume is not an iframe).
I need to shut up and think for a while. Thank you.



Edited 1 time(s). Last edit at 07/23/2011 12:26PM by salmobytes.

The main thing to do for you now, seems to get a grip on the various application architectures that are possible in the web environment. Each of them has different possibilities for integration.

Iframes is one of the worst "integration" options. Iframes have a fixed width + height, while most applications produce output pages of various sizes. When hosting the main site + inframe application on the same domain, there are hacky options to dynamically scale the iframe to match the size that the content needs. That is terribly hacky though and not an option when hosting on different domains.

---

Maurice Makaay
Phorum Development Team
my blog linkedin profile secret sauce