vbExtension utilities or class (Poll)

[CarCdr]

Something that has been on my mind for some time is the notion of a community-supported set of utilities for writing vBulletin extensions/hacks. vBulletin itself is not designed with extensibility in mind.

The two most compelling reasons for such a set of utilities would be:
To protect extensions from changes in vBulletin. If it were community supported, changes in vBulletin could be integrated in the utilities so that hacks using the utilities would be somewhat protected from incompatible changes in vBulletin code.

To provide common interfaces for the most common vBulletin idioms, such as generating a list of accessible forums. Why repeat this code in every hack?
I have put some of the ideas for interface ideas in the poll. Others?

[nexialys]

take a close look at the /includes/ directory, and you will have everything you need to suite your needs. all these files are like the default API classes for your needs. each file have the specific functions to answer specific needs in code integration.

no need of more extensions...

2¢CA == 1¢US... but btw, it's a cent

EDIT... btw, discussing the code structure of vB would have more values on vBulletin.com than here... we already code new things because we need more features, having them implemented in vB means you discuss with the coders of it, at vBulletin.com !

[CarCdr]

take a close look at the /includes/ directory, and you will have everything you need to suite your needs. all these files are like the default API classes for your needs. each file have the specific functions to answer specific needs in code integration.

no need of more extensions...

2?CA == 1?US... but btw, it's a cent

EDIT... btw, discussing the code structure of vB would have more values on vBulletin.com than here... we already code new things because we need more features, having them implemented in vB means you discuss with the coders of it, at vBulletin.com !
I am not suggesting it be coded *in* vBulletin. It would be supported here, for the purpose of making extensions easier to write, more standardized, and to some extent, to help prevent incompatible changes in vB ripple through all of the extensions in the world (e.g., change in a functions parameters).

I have perused most of the code in include files, and have used a good deal of the common routines. While they offer decent functionality, they clearly do not provide many of the common requirements of writing an extension. If they did, we would not have to post lines of code everytime someone asks "How to I get a proper navbar?" or "How to I generate a list of forums that are accessible?", etc.

Cheers

[nexialys]

sure, but i was talking about integrating to vB... if you want to develop a setup class, no problem, i will be one of the first to try it... i'm doing so myself, as i'm developping external tools and each time, i build the complete list of functions to be independant from vB, so i don't have to upgrade each time vB upgrade..

[Andreas]

> "How to I get a proper navbar?"
$navbits = array('put smth. useful here');
$navbits = construct_navbits($navbits);
eval('$navbar = "' . fetch_template('navbar') . '";');

I don't think this could be done much easier ... ?

[CarCdr]

sure, but i was talking about integrating to vB...
And I was not... :)

It is difficult for me to understand why folks would want to hand-code something like permission checking or the pagenav stuff. In the end, all it does is lead to extensions being posted without the proper functionality.

The sorts of calls one would make might look like this:
/* Set page title, script-related var's, and var's according to option string. */
$vbext = &New vbExtension($TITLE, $URL, 'navbar, forum_jump);
...

/* Generate list of forums with these permissions (or can_moderate). */
$forumids = $vbext->get_accessible_forumids('canview, canviewothers');

[CarCdr]

> "How to I get a proper navbar?"
$navbits = array('put smth. useful here');
$navbits = construct_navbits($navbits);
eval('$navbar = "' . fetch_template('navbar') . '";');

I don't think this could be done much easier ... ?
I understand where you are coming from, but again, it codes in a dependency on vBulletin and, it clearly more difficult than:
/* Default navbar based on initial call to vbExtension. */
$navbar = $vbext->get_navbar();In fact, that call would be unecessary if 'navbar' were specified in the class-creation call.

Or to generate a navbar two-levels deep:
$navbar = $vbext->get_navbar('Sub-page name');
Both calls work because the title and URL info are available from when the class is created.

[nexialys]

hum.. looks like i see where is your point... you would like to have parts of vB to become OOP... i don't think it's planned... OOP is not even recognised at php.net, even in PHP5...

your leveled navbar example is not concise...:
$navbits = construct_navbits(array(
'element_url.html' => 'element_name',
'' => 'last_element_name_without_link'
) );

is it so complicated to build ?!... you tell in your explanation that our actual structure is hard to understand... i think that OOP is complicated, not pure php...

[CarCdr]

hum.. looks like i see where is your point... you would like to have parts of vB to become OOP... i don't think it's planned... OOP is not even recognised at php.net, even in PHP5...

your leveled navbar example is not concise...:
$navbits = construct_navbits(array(
'element_url.html' => 'element_name',
'' => 'last_element_name_without_link'
) );

is it so complicated to build ?!... you tell in your explanation that our actual structure is hard to understand... i think that OOP is complicated, not pure php...

It could just as easily be straight functions. using a class is a simple means of keeping information without using global variables. (Classes does require PHP 4. Creating a class does not require that vB be OOP. It's just standard PHP.)

As for my navbar call, it would work fine. In the initial call we were supplied the page title and the page URL. We save three pieces of information in globals:

1) The file name, saved in say $EXT_filename. E.g., foo.php
2) The URL, in say $EXT_url. E.g., ./foo.php
3) The page title, in say $pagetitle.

A call to generate a two-level navbar then only requires the page title of the sub-page. Hence, the call:
$navbar = get_navbar('Sub-page name');
would contain code along these lines:
construct_navbits(array($EXT_url => $pagetitle,
'' => 'Sub-page name'
));
It is the most common sort of design consideration to hide the structure of data where feasible. We now have the details of building a navbar in exactly one place, called by extensions.

[nexialys]

any way to create such function would mean to create documentation for each function anyway... so why not simply build documentation on what already exists on vB?!...

[CarCdr]

any way to create such function would mean to create documentation for each function anyway... so why not simply build documentation on what already exists on vB?!...

Yes, documentation would be required, but it would be straightforward, since the entire idea is that the interfaces would be very straightforward.

Maintaining a handful of pages for documentation is likely outweighed by the benefits of a standard hacking toolkit:

1) Easier to implement common hack features.
2) Isolate hacks, to some extent, from changes in vB releases. All one needs to do is upload new vbExtension.php if incompatible changes are introduced.
3) Less bugs since everyone is not coding common tasks by hand.

Cheers