Re: PEAR Forum

[change reply-to to pear-dev so it get's sent right the first time!!!!!!] I'm for 1 too, PEAR Forum sounds nice i think. :) Also my forum is split up into several parts, as listed below. -Frontend The files in the root directory -Backend/lib Everything in the lib directory -Database abstraction

    Everything in lib/classes/db

-Skins

    This is actually related to the frontend, but it's also related to
    the library as it is the library that uses the skins.

-Plugins

    Everything in lib/plugins
    Can be used to:
     *add additional headers to messages for example ICQ#, links to
      attachments etc.
     *perform actions when a new message has been posted,
      such as sending it out to a mailinglist.
     *manipulate bodies of posts to make URL's clickable, or make
      syntax highlighting of code, for example if someone types some code
      surrounded by <?PHP ?> all code inside can be syntax highlighted
     *and lots of more problably...

I think the backend fits best as a PEAR/Forum, with a set of global plugins and skins. Support for adding additional plugins and skins in the root/frontend directory can be added pretty easy by first looking in <root>/skins for skins, if it doesnt exist there look in <lib>/skins and the same for plugins and maybe database abstraction. I'm not entirely sure how PEAR packages work though, maybe it's easier to have a local and more up to date installation of PEAR Forum. Stig Sæther Bakken wrote:

PEAR has room for larger packages like Phorum (the "A" in PEAR is for "Application" after all), but we haven't quite figured out a way to integrate them yet. We need to figure out how to fit applications into the package namespace. I guess it cooks down to picking one of these two options: 1. Each application gets its own top-level package name. Pros: simple. Cons: may clash with topics we may want to add later. If application packages have fairly unique names it shouldn't matter. 2. Each application prepends something to its package name, for example "App_". Pros: won't clash with topics. Cons: it just looks silly. I'm in favor of (1). - Stig [Morgan Christiansson <sft3905@post.netlink.se>]

Hello, i'm wondering what you think of having larger things like forums in PEAR, or perhaps optionally downloadable, which might be better, since there is no good way of keeping the automatically installed repository updated. I'm thinking of naming it PEAR Forum, if you don't approve you don't have to worry. Anyway, i've written a forum that is designed as a library, so to display a page you do something like this: <?PHP $list = new pear_forum_list(); $list->forum_id = $HTTP_GET_VARS["forum_id"]; $list->offset = $HTTP_GET_VARS["offset"]; $list->display(); ?> It's written with the PEAR codeing standards, with the exception of functions which currently has the first brace at the same line as the function declaration. It has PHPDoc generated documentation, a plugin and template system, abstracted DB, has a system to easily cache pages (just catch $list->display() in the output buffer) and/or you can add a little code to cache SQL queries. Well that's most of the features, PEAR stands for PHP Extension and Application Repository so why shouldn't it include apps? I think PEAR Forum fullfill the purpose of PEAR: - to provide a consistent means for library code authors to share their code with other developers. It is class based easily embedded in other apps and has a plugin system to extend the base functionality and uses PHP as a template parser to give highly flexible templates. /Morgan Christiansson -- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, e-mail: pear-dev-unsubscribe@lists.php.net For additional commands, e-mail: pear-dev-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.net