UBB.Developers Forums Announcements Announcements U-Zine Articles State of the Portal

State of the Portal
By: Dev Team





Editor's note: After a meteoric start and flameout, the ubb.portal is back on the front burner in ubb.classic development. This article will be a primer on where we are, where we're going, and what's in store.

History:

Requested often in some form or another, the ubb.portal took on a renewed interest in January 2002 with the asking of this question .
A great idea, it was taken up by the dev team and run with. As can happen on sites with volunteer work, people get busy, and the ball got dropped.
What did come out of the beginning stages was the process for design and development, with a lot of thought and work put into the design for a modularized system.
I present to you the process done and where we go from here.

Development Stages:
- v1
Version one is to be a alpha/beta proof of concept version. It will basically pull the currently available ubb modifications together that make up what most would consider a "portal system".
It would be easy to install and update, and for the most part, would remain as separate modifications so the individual pieces could continue to be developed/bug fixed.
A core dev module would be designed to make the pieces work together and allow easy updating/re-assimilation of the separate features.

-v2
Version II is where the portal system is actually headed. This is where the more advanced concepts and features would be added, building upon the trial and error period of version I.
The portal will move into an open-source development community with CVS access to ensure input from the widest possible audience of ubb developers and tighter quality control.

V2 Development:

- proposed features
Many features have been requested, some have been divided into "required"- if we don't do this, the product won't work and/or the users will kill us, "should do" - we should do this if possible, "could do" - we could do this, but we don't really have to, "can do, but won't" - we can do this, but we won't now, and "can't do, but wish we could" - nuff said
Most features that have fallen under "required" include:

• polls
• reviews
• styles integration
• ???

Features that are considered in the "should do" list include:

• who's online
• ???

Features that are considered in the "could do" list include:

• announcement posting icons
• image gallery
• ???

Of course, the feature list is liquid in design and implementation. Everyone has their own "must haves", ubb.portal will work towards serving the greatest number of sites in the best fashion
- module system
Serving the widest variety of sites would be accomplished using a modularized design. First, to ease installation and upgrading of both the portal and the forums as needed. Second, to allow individualized setups across different types of sites.
Charles Capps assists with a nice explanation of the modularization design:
Real applications have cleanly, clearly separated boundaries between data, logic, and presentation. It usually goes something like this.
Layer 0: DataThe data itself. This may be a flat file, a RDBMS, a remote source, whatever.
Layer 1: Data Handler
The routines that are responsible for reading and writing the raw data, i.e. DBI, something like ubb_lib_files/UBB::FileHandle/FileHandler.

Layer 2: Data <=> Logic
In the event that layers 0 and 1 can vary widely, this layer may exist in order to provide simplified methods to the above layers... i.e. UBB's &OpenTopic vs &OpenFileAsArray($topicpath);

Layer 3: Logic
Stuff gets done here. The real code. Data from the lower layers is munged into something useful. Useful != pretty...

Layer 4: Presentation
...which is where the presentation layer comes in. This is where the data gets turned into something pretty, i.e. HTML output.

In an ideal situation, Portal will be laid out cleanly and properly, doing as much as it can to stick to the Way Things Should Be Done.

In fact, doing so is critical to the plugin system working (which is why we aren't doing this with UBB).

Plugins may add *OR OVERRIDE* code on any layer. If someone wanted to replace, say, OpenFileAsArray with another implementation using a plugin, it could be done. This allows whole new systems to be devised using just the plugin modules.

That's all well and fine, but how does it WORK?

Let's take this from an admin's POV.

- $Admin uploads the plugin file to the proper directory on the server.
- $Admin enters the control panel's plugin section
- The plugin system scans the plugins directory. It notes that a new file has been added and catalogs it
- $Admin sees the plugin there and tells the plugin system to use it
- The plugin system loads the plugin's code, determines where it wants to hook into, and runs an optional initialization routine included with the plugin (i.e. initial setup)
- If there's a conflict, say, the new plugin wanting to be first in line to process data from a certain sub, and another plugin already has the first position, the admin is asked what to do.
- Once conflicts are resolved, the cache is cleared (Portal had better damn well cache - if it doesn't, I'm gonna MURDER someone...) and everyone goes on their merry way.
- If necessary, $Admin can then update the template system. (Small changes can be automated, of course.)

Okay, what about behind the scenes?

Each plugin is a real Perl module, say, in the UBB :: Portal :: Plugin namespace.

The modules do NOT have to be OO, they just must be real modules.

The module must have at least five subs (names, details TBD):
- information - provides a hashref with standardized data about the module, i.e. human readable data, versioning, copyright, authentication, whatever.
- initial init - called when the module is installed, does what is necessary to make sure the code will operate, and provides the main program with information on where this module wants to be put.
- instance init - called whenever the module is loaded. Exports vars, imports data, whatever
- un install - does whatever is necessary to remove the plugin from the system
- core routines - and, of course, all the subs that, oh, do WORK.

Let's say we're installing a polling plugin. It'll want to pre-process any data in news posts for polling information.

During initial init, the module would tell the system where it wants to be plugged. The list of filters to apply after the main processing (layer 3) and before display (layer 4) would be appended to include refs to the plugin subroutines.

Tada. That's it.

Whenever it comes time to do something that requires a filter, the subs are called And It Just Works™

I realize this is light on technical details and has no code... I have a few prototypes locally (see http://kurodot.org/ for my proof of concept site mockup)....

- thank you Charles, now my head hurts

- sourceforge site
A ubb.portal CVS site has been setup at sourceforge.net in prep for the coming work.

project - https://sourceforge.net/projects/ubbportal/
site - http://ubbportal.sourceforge.net/

Development for v2 will begin there as soon as the lead project admin is assigned.

Wrap-Up:

Where do we go from here? The good thing is, you as a community get to decide. Someone with the time and displayed maturity level to take on the project co-ordination must step forward in order for the project to get off the ground.
Some knowledge of coding is desired, but organizational skills and a "take-charge" attitude are more in need. Beyond that, forward-thinking individuals with skill sets that can assist with html/templates, graphics, back end coding in perl, and front end coding in php and javascript are needed.
You may contact me if you have the desire to be a part of something big.