This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes JForum and the fly likes Proposal for future extension Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Products » JForum
Bookmark "Proposal for future extension" Watch "Proposal for future extension" New topic

Proposal for future extension

Migrated From
Ranch Hand

Joined: Apr 22, 2012
Posts: 17424
I aggree with the cons and pros. Another major problem of site_key is that, if the data for all boards are in the same database, query's performance will be gradually slower over the time, since you'll be sharing the same table with n other systems.

I'm currently refactoring JForum in many parts in order to get maintance and extensibility easier, and one of the things I have to do is to merge the changes from Jahia guys. However, I don't know exactly when I will get it done.

Anyway, the developement HEAD version as initial support for SSO. The doc is here: . Any thoughts?

[originally posted on by Rafael Steil]
Migrated From
Ranch Hand

Joined: Apr 22, 2012
Posts: 17424
Hi JForum team

We are currently using JForum in our application. In fact we use the portlet that has been adapted by the Jahia guys.
One feature we - and also the guys from Jahia - would like, is to make JFotum something like we call "site aware".

I.e. on our platform, which runs on Jahia, we want that on each site an administrator can instantiate and configure a forum for it's own. E.g. If company A on site A instantiates a forum it should not see or disturb forum content of company B on site B, and vice versa.

For this reason I have thought about of adding a site_key field to each relevant JFORUM TABLE, and passing somehow the current site_key to the JForum DAO's, so that it can be considered within the queries. This solution has drawbacks, because I have to change the DB-schema and make also many changes in the JForum Source Code. Another problem are the caches, that JForum uses, I think in a "site-aware" solution I have to disable them, which surely will decrease perormance .....
Doing all this it will make it also very difficult to switch to a newer version of JForum, which we surely don't want to miss because we think JForum is really cool

kind regards
Wilhelm Berger

[originally posted on by Anonymous]
Migrated From
Ranch Hand

Joined: Apr 22, 2012
Posts: 17424
Hi Raphael!
I agree with your concerns about performance when putting n sites into one table, but currently I do not see any other choice because my managers want this feature, and I am already used to JForum, and also I think there is no other Forum Solution available which addresses "site awareness" But I think if Jahia wants to use JForum Portlet within its platform structure which relies on the site concept, it would be an important issue for them.
Maybe some special DB VIEWS, or something like that might help. we are using Oracle (BTW implementing Oracle DAOs was quite straight forward, because JForum is niecly designed

About your link concerning SSO:
currently Jahia uses the second aproach, and it works quite well. In fact I had to change in some minor points according to our needs (not so important and difficult)
But I think also the first approach has some benefits:
- because you could integrate JForum users table with the platforms user table, because crurrently ther are some redundant duplicate entries. Maybe also an integration of JForum Groups with portal groups would be nice...

kind regards

[originally posted on by Anonymous]
I agree. Here's the link:
subject: Proposal for future extension
Similar Threads
Users in Groups or memberships
Integrating Jforum with other application but within a single ear
About Jakob Vad Nielsen
JForums as a JSR-168 Portlet Application
JavaRanch goes mobile