Does v3.0 use " JavaScript Object Notation "?

  *zigzag said:

*

+ Vodka *

/me steals *zigzig's popcorn

Since matt mentioned factories and singletons i went and read up about 30 articles on it, its a very interesting design pattern but till i actually code something i won't be able to comment on how well it works.

My main aim (along with Brandon and Josh's who have been very much involved with the concept of the 'IPS Core' in IPB 3.0.0) was to break up a 'catch all' class ($ipsclass) and replace it with a more logical solution.

At the moment, these are basic static classes masquerading as singletons. They are very basic classes whose methods are very simple and straight forward.

These are in 'staticclasses/core.php'

IPSLib
IPSDebug
IPSCache
IPSCookie
IPSData
IPSText

These are largely built from functions found in "sources/ipsclass.php". IPSLib is a bit of a dumping ground currently for things that don't fit in elsewhere. A lot of stuff (Error, boink_it, etc) has been moved to the output class. Other methods have been moved into the ACP functions class.

Still in "core.php" are two more static classes masquerading as mini-factories.

IPSClasses
IPSDB

IPSClasses is a little class to handle maintaining state of loaded classes. Certain classes like class_display, class_session, class_forums, etc share data across files and it would be annoying to either pass their handle around or initiate them in every script. IPSClasses takes advantage of using PHP 5's "thru" class handling.

* Usage:
* IPSClasses::set('className', './className.php' );
* IPSClasses::get('className')->classNameMethod( $foo, $bar );

IPSClasses::get('className') is now available everywhere.

IPSDB is a little factory for the DB drivers which are going to be rewritten at some point. Its usage is similar to IPSClasses.

IPSDB::set( 'mysql' );
IPSDB::get()->build_query( ... );

You can pass an optional key, like so:

IPSDB::set( 'mysql' );
IPSDB::set( 'mysql', 'connectionNew' );
IPSDB::get()->build_query();
IPSDB::get('connectionNew')->build_query();

This allows for more than one connection to be maintained in a single invocation.

'staticclasses/member.php' holds two static classes.

IPSMember is a general class for member functions (get_avatar, load, save, etc)
IPSActiveMember is 'you'; the active member browsing the boards. Attached to this class are methods to deal with loading you, saving you and building your permissions as well as checking your permissions. Also attached are variables to hold your session state and environmentals, such as IP Address, user-agent, etc.

I think that is much better than throwing everything at $ipsclass.

One also has to keep in mind that we're not coding for the class room here. We're trying to advance a 4 year old project with minimum fuss. IP.Board 3.0.0 is a new framework using refactored code. We don't have 18 months to start from the ground up.

  Jaggi said:

/me steals *zigzig's popcorn

It's okay I have a large supply, I have a feeling this could get interesting :P

I don't understand a word of it though :P I went looking up PHP and then closed the page down :(

Thanks Matt... Looks like IPB 3 is goona look good. :)

  Matt said:

My main aim (along with Brandon and Josh's who have been very much involved with the concept of the 'IPS Core' in IPB 3.0.0) was to break up a 'catch all' class ($ipsclass) and replace it with a more logical solution.

At the moment, these are basic static classes masquerading as singletons. They are very basic classes whose methods are very simple and straight forward.

These are in 'staticclasses/core.php'

IPSLib

IPSDebug

IPSCache

IPSCookie

IPSData

IPSText

These are largely built from functions found in "sources/ipsclass.php". IPSLib is a bit of a dumping ground currently for things that don't fit in elsewhere. A lot of stuff (Error, boink_it, etc) has been moved to the output class. Other methods have been moved into the ACP functions class.

Still in "core.php" are two more static classes masquerading as mini-factories.

IPSClasses

IPSDB

IPSClasses is a little class to handle maintaining state of loaded classes. Certain classes like class_display, class_session, class_forums, etc share data across files and it would be annoying to either pass their handle around or initiate them in every script. IPSClasses takes advantage of using PHP 5's "thru" class handling.

* Usage:

* IPSClasses::set('className', './className.php' );

* IPSClasses::get('className')->classNameMethod( $foo, $bar );

IPSClasses::get('className') is now available everywhere.

IPSDB is a little factory for the DB drivers which are going to be rewritten at some point. Its usage is similar to IPSClasses.

IPSDB::set( 'mysql' );

IPSDB::get()->build_query( ... );

You can pass an optional key, like so:

IPSDB::set( 'mysql' );

IPSDB::set( 'mysql', 'connectionNew' );

IPSDB::get()->build_query();

IPSDB::get('connectionNew')->build_query();

This allows for more than one connection to be maintained in a single invocation.

'staticclasses/member.php' holds two static classes.

IPSMember is a general class for member functions (get_avatar, load, save, etc)

IPSActiveMember is 'you'; the active member browsing the boards. Attached to this class are methods to deal with loading you, saving you and building your permissions as well as checking your permissions. Also attached are variables to hold your session state and environmentals, such as IP Address, user-agent, etc.

I think that is much better than throwing everything at $ipsclass.

One also has to keep in mind that we're not coding for the class room here. We're trying to advance a 4 year old project with minimum fuss. IP.Board 3.0.0 is a new framework using refactored code. We don't have 18 months to start from the ground up.

Thank you. I am looking forward to the new version :)

I would personally just change $object->ipsclass=$ipsclass to new object($ipsclass).
And won't singletons implemented as fully static classes require quite some work if you for some reason need more than one instance of the singleton?
For example uhm, hold on, I am sure I can invent a need to unsingleton something... Oh, yeah. Some migrating tool for changing the database server used, meaning that there is suddenly a need for multiple db connections.

  henke37 said:

I would personally just change $object->ipsclass=$ipsclass to new object($ipsclass).

And won't singletons implemented as fully static classes require quite some work if you for some reason need more than one instance of the singleton?

For example uhm, hold on, I am sure I can invent a need to unsingleton something... Oh, yeah. Some migrating tool for changing the database server used, meaning that there is suddenly a need for multiple db connections.

The database object(s) is/are not implemented using a singleton design pattern...


Oh and ipsclass was never really a true object, so new object($ipsclass) is not necessary. It was more of a HUGE php4 static class.

  Quote

What has that got to do with anything? Why are you doing that? How can you correct my code without even seeing it?

In your code you've shown a lot more to me than you obviously believe. I can see from your structuring and execution that you've shown thus far you are exactly where I was in design last year, which is why I'm commenting. I've been there, saw how bad it works, and moved further. As for "why I'm doing that", I guess you didn't even read the example below it to see exactly why I did that. Further, it creates a common interface throughout your code which is good at upper "application" levels.

  Quote

Also, why are calling "init()" who says there's an init in my code? Why are you assigning a static class to a variable? And then use that variable as an OOP handle? That makes literally no sense to me.

Wow... and you are questioning me? I'm not assigning a "static class" to a variable. I'm assigning an instance of a singleton class to a variable in the only way you can. Sure "init()" doesn't need to be called init. But the Singleton must be initiated through a public method that IS NOT the constructor.

  Quote

And here's some code from 'boards.php'

Note: no set up has been done, no variables passed around. All static classes are available *everywhere* instantly, like magic.

And you can't tell me that's not going to work, because it is!

Firstly, the parent class is NOT STATIC. You initiated it. Static classes are those that need no initiation. A Static Class is not the same as an instance. and a static class should not be called and used as a static class simply because you've stored a copy of the instance within the class. That's bad OOP.

Second, I never said it wasn't going to work. I said that you will see large problems when you want to expand later due to the lack of common interfaces. In my example, all classes are initiated by common method, all TRUELY static classes can be called at any time (by magic as you put it), and no variable passing happens. And because common interfaces exist, expandability will never be a problem.

  Quote

No, those were factories. They are a static interface to a dynamic protocol. Mainly so you don't have to pass object handles around for classes which you want available everywhere (session, display, etc)

Using factory methods like that is silly and uglifies code. I'd like to see an example of any program that actually does this too. I'm pretty sure that using the return as you are is also bad OO practice (for many of the reasons I've mentioned).

  Matt said:

I think you need to read up on static classes in PHP 5.

I'm quite fine thank you. I'm either not explaing myself properly or you're missing my points.

  Quote

You may have done in PHP 4, but not in PHP 5.

Been working with PHP5 alone for 3 years now as a primary development platform, reading on OOP for longer, and developing my own framework. Either way, I'm not even talking PHP5 here, so it doesn't matter. I'm speaking about organization and expandability from an OO standpoint within your project.

  Quote

Don't have time to ground up

Paraphrased

There are a lot of easy things that could be done to set the ground work for IPB and PHP5 under the current structure and still meet your deadline. After the groundwork is laid a rewrite could become a lot easier. You can say you aren't rewriting now, but in fact you are to a large extent.

  Quote

Not much that you posted makes any sense at all.

I can see that you are taking my post as an attack, not as necessary constructive criticism. From your first few replies to me all I see are pointless jabs to supposely question my knowledge of the situation. I'll just move on and let you do whatever. If you actually want to have a development discussion without resorting to insults, feel free to contact me.

  henke37 said:

I would personally just change $object->ipsclass=$ipsclass to new object($ipsclass).

Using my examples above they wouldn't even have to do that.

  JasonIPS said:

Oh and ipsclass was never really a true object, so new object($ipsclass) is not necessary. It was more of a HUGE php4 static class.

ipsclass is NOT a static class, never was, nor could be associated with!!! It was an unnecessary object for a lot of things but, never once did you use it statically (nor could you) because you always had to initiate it.

  Digi said:

ipsclass is NOT a static class and never was!!! It was an object. Never once did you use it statically [b]because you always had to initiate it.[/b]

Okay, you are over analyzing. I was basically saying that it was a dumping pool for functions that needed to be used through IPB. I was talking more abstractly and not literally...

I'm not sure how the actual term "static class" could be used abstractly. However, sorry for over analyzing. ;)

Popcorn anyone :P

*grabs popcorn from zigzag ;)

I think you're getting obsessed with terminology. If, by definition a singleton needs to be initiated by some form of constructor, then I shall stop calling them singletons in front of you. Rather static classes, then if that pleases. My 'singletons' or, 'static classes' do not require any constructor or construct method. They are imported into PHP by require and thus begin their existence without any coding intervention.

I'm going to refrain from posting a lengthy response to your posts and wait until you have all the code in front of you.

You have to keep in mind that what is good in the class room isn't always good in the real world. I'm aware of what constitutes good OOP design and what does not. I am making choices based on several factors that include, but are not limited to:

Great ;) A whole new structure to learn, more fun for me :D

I would like to congratulate Matt and the team on moving to PHP5 support only.

PHP 5.0.0 was released in July 2004, and being a host myself, I can not think of a single business case why a host would support only PHP4 still. (Note: I'm not saying PHP5+PHP4 support is bad, just only PHP4 support)

I've started making some changes to the core framework to make it more flexible. This discussion has been useful as it's made me question my code and reasons for using it.

I have just finished a rough version of the new framework which is basically:

ipsRegistry
ipsController
ipsCommand
ipsView

The registry is a singleton (yes, a proper one!) that sets up and holds settings, input, member, DB handle, etc.
The controller takes basic input (_GET _POST) initiates the registry and passes it onto the command class which figures out which command file to run (boards, usercp, forums, etc) and then executes it.

'index.php' is essentially:

require_once( IPS_ROOT_PATH . 'sources/base/ipsRegistry.php' );
require_once( IPS_ROOT_PATH . 'sources/base/ipsController.php' );
ipsController::run();

*insert giant clapping smiley here*

I'm glad that I was able to help you improve the overall design, even by limited proxy, through my replies. What you have just posted is EXACTLY the kind of design methodology that I was trying to get across, and I'm sure that you will be more than pleased with the end result! I can't wait to see the finished product! :D

  Lindsey_ said:

*grabs popcorn from zigzag ;)

glads thats sorted, we were running out of popcorn :P.

Will look forward to updates on how its going though matt...er i mean shouldn't you be working on nexus!! :ph34r:

With this new design model, are you going to implement some kind of system-wide hooks functionality? T'would be nice to remove the some of the need to modify code all over the place. :)

they did already say that ipb 3.0 would have a hooks system. How it'll work remains to been seen yet. I assume it'll be similar if not the same to the nexus hooks system. Although i don't know how that works... YET

We haven't fleshed out the details of IPB itself yet, so we haven't been able to fully flesh out the hooks yet. Nevertheless, there will be a lot better integration and hooking functionality in IPB 3.0, however we implement it.

And there will be uniform functions for the most common database tasks, right? Like adding a reply to a post and so on.

Ideally, yes. Something like $post->addPost( $post_details_array );

We have something like this already under sources/api/ but I'd like it abstracted better - I hate having to maintain similar, but different, code in multiple places.