able

Thanks for the links, but it wasn't what I wanted. I don't want to build ontop of phpbb3 - merely be able to create/update/ban users remotely. I've now got that working, for anyone else looking to do this, the stuff in phpbb3 about the random seed hashes - is security through obscurity, it does nothing. The seed hashes can be completely left out and it doesn't alter anything.

Yeah thats what I'm doing at the moment, I was hoping someone had already setup a list of steps or knew about a secret api :-)

Has anyone had to do an integration with phpBB3 yet? I need to synch the main user database with the phpbb3 when people register/change pass/etc - has anyone done this already and have some advice?

set the html element name to ids[] set the value for each box to the id You'll then get an array $_POST['ids'] that contains the id's of all checked which you can use.

Loading only parts of the user seems fine to me, you have 3 main approaches for doing so: 1) Lazy loading, put a proxy in fields/relations you don't always need and reload if requested (not a fan of this in php) 2) Specify which fields you want at the query stage 3) Create additional classes e.g. User extends UserBasicInfo With option 2, you can get round the problem of overwriting the empty data, by tracking dirty fields. Each set, marks a field as dirty, the update statment is then built only using dirty fields i.e. if a field value hasnt changed, it isnt updated. Getting round the problem of the last 10 orders and the users, I've given up trying to make the OO nice, and basically followed the DB structure on the idea that I'd rather have efficient queries than the cleanest OO. What I currently do, is build the query and in this case, the user id would be in the order, so I tell it to grab the 10 most recent queries, and that that the user id is a foreign key, so it should do a join and the itterator will return an array of objects (order, user) reducing it to 1 query, which is generated on the fly - but loosing the ability to say: $order->getUser() For me, I can live with the lack of oo purity. I know some can't.

Why can't your url_helper or other class/method/function simply take an object, plus the name of the field of the object which is a url and use it to create your link?

By default sessions are stored as text files on the server.

Just speak to your host about enabling SSL - you can buy certificates pretty cheaply now.

Try an address book application. 1 person can have multiple sets of contact details.

It does speed up comunications, but it's nothing to do with the number of sockets. Sending multiple echo's without output buffering does not use multiple sockets.

Output buffering is perfectly valid, for the purpose of buffering output :-) Output buffering allocates a larger memory size than a php string, so sending large output to it instead of a variable is more efficient due to less resizing behind the scenes. Sending all output at one time, without delay allows for less packets to be sent which aids communications. As stated, turning on gzip handler for your output buffering will also reduce the amount of data sent. Don't let anyone in 2008 tell you output buffering is evil :-)

Nobody is doing that. Just calling a render process, the output of which is passed to the view as a variable for display.

I disagree entirely with the notion that having php output html breaks mvc/model2. It is simply that some of the php is in the view layer (seperate form model from form renderer). As to having the designer add additional form fields... I get to skip this, where is the data from the field kept? With my work 9/10 its in the db, so the extra field has to be added to the db, the business object and controller is regened to add the new field - and a few lines to the form abstraction is added, rather than then having to wait for the designer to edit the form.

This is the flow of a typical edit scenario: function executeMain() { $user = $this->dao->load($_SESSION['user_id']); $user->sendToPostArray (); $form = $this->makeForm (); echo $form->render ( false,URL_ROOT . 'EditAccountDetails/submit/' ); }

You are trying to do too much I think. What you have is some form html and some database access. It seems like a step backwards, but seperating the two makes life a lot easier. I have the form as you saw, once validated the post array is passed to object(s) which populate themself. Those objects are then created or updated with a single method call, the sql is generated based on the objects and relevant tables. I've included a typical form submit flow below: function executeAddSubmit() { $form = $this->makeListForm (); if (! $form->validate ( $_POST )) { echo $form->render ( false, URL_ROOT . 'Lists/AddSubmit/' ); return; } $list = new FlList ( ); $list->populateFromArray ( $_POST ); $list->setUserId ( $_SESSION ['user_id'] ); $created = $this->dao->create ( $list ); if ($created) { header ( "Location: " . URL_ROOT . "Lists/Main/" ); } else { echo 'Sorry, there was a problem adding your new list'; } }