You knew this was coming, you could have spend the winter learning. :D

i have a question, if you code a hack using OOP, or OOPing the code however the correct reference goes, will it only work with 3.5 or could it be developed on 3.0.7?

Im currently developing RPG v4 in OOP, but (obviously) for .0.7
The difference is that while my $RPG class won't have to change (much), all the $vboptions's etc needs to be changed.

lol, poor admin :D

The instructions for installing the typical hack will no longer include steps like:

"Open showthread.php and look for:

<<CHUNK OF CODE>>

and replace it with

<<CHUNK OF CODE>>"

and init.php, search.php, etc. ad nauseum.

Instead you will upload a bunch of PHP files which vBulletin talks to in a documented way.

Aslong as the class-name and variable given to call the class is 'unique' then no collision will occur.

I am glad to hear about OOP, it was something i always liked about IPB (back when i used it), some may see it as a pain, but from a different perspective it can really neaten codes up, optomize them, and make nice lil library files =)

I'll be looking out for the beta, so i can be prepared what to expect for the Plugins system, i'm also very interested and planning on intergating every single line of the AJAX engine, i have great plans for it.

- Zero Tolerance

Without seeing the code, one can only speculate on how it will actually work. It was said that "hooks" are used throughout the program now which likely means it will consult a list of installed modifications, see which ones are registered with that hook, and execute code appropriately. Where there's no hook, you won't likely be able to affect the normal code flow, just like now. However, the way they described it, it sounds like they can easily add hooks later.

I would be worried about a hook in a loop. An irresponsible modification author may add a query to their code that registers with that hook and therefore queries in a loop.

Hack authors won't need to write queries very often because of the Data Manager and OOP.

Most queries that people add to their hacks search on the post table or add an index or table to supplement users, posts, threads, etc. With vB3.5, all of that should be done with Data Manager and Classes.

well i didnt think it would be so soon and i was busy actually coding the sections of my site. OOP= da evil!!! why cant i just code!!1

It's going to be great learning to code 3.5.0 in my opinion, now I have a reason to learn OOP annnd now I have things to do over the summer ^_^

Does this also mean you can install more hacks at the same time without having conflicts?

Some hacks want you to edit things en other hacks want you to edit the same.. And then it's up to you what to edit.

unfortunately there still may be conflicts, some plugin code may interfere with others plug-in code.

The idea is that hacks don't need to make file edits anymore, or less.

Time will tell if we can really make it work like that.

I guess programmers can insert their own hooks, but that´s just a guess...

There will always be the need to modify an existing section of vBulletin code, but this as I understand it will reduce that from almost every hack to only a handful:)

Satan

Some hacks can be done that way now without modifying the files. I was able to rewrite the template compressor and microstatus hack to work from the templates preventing me from having to rehack my board when I upgrade it.

I haven't been in the community that long, so I'm curious about how long a beta period normally is?

I'm trying to decide whether it's worth hacking my board now, with the 3.0.7 hacks, then rehacking it with the 3.5 stuff, or if I should just wait. I can wait like a month, but I think I'll hack it if I have to wait for 3 months.

What's the normal beta period + major hack release cycle?

It usually varies on the time of the Jelsoft Development team... They stated that if all goes accordingly, a public beta in early June. The beta may last anywhere from a week, or a couple, to a couple of months. My advice to you is if you're just going to install a few easy modifications, then theres reason not to; but keep in mind with this new system that it'll be a few months (maybe longer) after this new system comes out for modifications to be ported to work with this new version...

If you don't need modifications for - I'd say a good couple of months, then don't bother, but if you can't wait that long then go ahead and get modifying and don't upgrade until all the modifications you need are ported to the new version.

Only time will tell.

My board is still running on 3.0.3 and 3.0.4 (2 boards).. Do I first have to upgrade tot 3.0.7 or can I make direct the upgrade tot 3.5 when it's getting relleased?

Teck's microstats? and you never released it :(

you can go directly from any 3.0.x to 3.5.x

personally i'd ay hack away, Jelsoft are no long reknownd for meeting their own deadlines.

besides if you're like me and have LOADS of hacks installed it will be a long wait till they're all converted to 3.5-ness.

It was my version of Erwin's microstats. I never released it because it was based it on his code.

Taking into account the slow speed of loading of vb3 pages, I can expect this to worsen in 3.5... But yeah, seeing the AJAX technology, I was like "woah! wtf is that?".. lol.

vB3's pages don't load slowly for me - Its about as fast as vB2 ever was :ermm:

Satan

vB3 was faster for me, less nested tables, less overall code in the page, external css file support. 10x faster, rendering times should be down as well

Well on the concept of OOP you would think that it would be faster. Also with the ability to reload content without refreshing is going to be or at least appear faster to the end user.

"less" code in the page doesn't mean anything.. they're just stored eleswhere for retrival...

vb3 is slower than vb2 in terms of page rendering.. there is hardly any JS code in vb2 whereas vb3 is bloated with JS which tend to lag browsers and cause delays. the PHP code might be more "optimized" in vb3, but it doesn't mean its any faster than vb2 when it comes to page rendering.

i dont think i have plans on upgrading to vb3.5. just thinking about all the bloated "AJAX" JS code it will have makes me look the other way. I took vb3 and basically rewrote and eliminated almost all the excessive JS code.

You know there is a switch, that when you flip, it turns off the js ;)

Actually, vB3 overall, bboth on php render time and browser render time, the stock skin is faster. (assuming optmial conditionals for connections etc)

I'd love to see these benchmarks, as I don't believe it for a second ;)

you mean theirs actual stats, groovy

[high]* sabret00the eagerly awaits.[/high]

Also with vb 3 theres more conflicts with otehr browsers .... Maybe could be cleared up with 3.5.

Where can I see them?

No I'm asking to see the benchmarks too!

If the developers were to eliminate their usage of tables for design, vBulletin would get a speed increase from:

1. Less Bloat
2. More Efficently Rendered Code
3. Lower Server Loads as a result of faster page transfers (and therefore shorter connection times)

vBulletin 3.0.x did reduce the amount of bloat (and therefore made pages transfer faster and be efficently rendered while reducing server loads as a consequence of the connections closing faster) but not to the extent as it would have if it had a tableless design (all presentation done by the CSS). Other forum software has done this:

http://forums.punbb.org/

Tableless designs are not all they are cracked up to be, I would be supprised if any vB style is tableless untill 2010

This is a personal opinion and not related to any thing but my own views and feelings.

Then again, that punBB default skin is the ugliest skin I have ever seen in my entire life. It is dull. Heck, it's even worse than the wBB default skin.

Besides, Im sure there's SOME coding that just can't be done without tables - I know that I like working with tables better than divs.