Advertisement
If you have a new account but are having problems posting or verifying your account, please email us on hello@boards.ie for help. Thanks :)
Hello all! Please ensure that you are posting a new thread or question in the appropriate forum. The Feedback forum is overwhelmed with questions that are having to be moved elsewhere. If you need help to verify your account contact hello@boards.ie
Avantgo and Boards
-
05-11-2001 6:43pm#1
Comments
-
The layout of Boards.ie would have to be amended for the channel as it's very table dependant and last time I created an AvantGo channel [1], it didn't support tables.
Also, for replies, forms would have to be handled somewhat differently as AvantGo will only submit them upon upon a sync.
Finally, how many boards would you want to sync? I could see it bloat my AvantGo PDB before long...
[1] Plug: ****.net
0 -
-
-
-
-
Advertisement
-
-
-
-
-
I was thinking that tackling boards by allowing members to view their subscribed threads, forums and PM's from their Control Panel would be the way to go, alright.
Given this, subscribed forums would bloat most PDA's, while PM's raise the unnerving issue of security (a username/password would in effect have to pass via the AvantGo proxy as clear-text). So, in the sake of simplicity, I'd suggest tackling subscribed threads first.
Application would probably have to be split into three parts:- A link in a users control panel, allowing them to subscribe, generating the necessary AvantGo URL,
- Scripts to read the preferences (either from the DB directly of encoded in the Avantgo URL) and format the threads for AvantGo (data coming directly from the DB), and
- A post/reply script, which would also have to bypass the 'constructing a new page' page
The first is easy once an architecture is decided. Database schemas, with some sample data (for example; we don't know if the vB code is stored in the database and formatted on the fly or formatted upon INSERT), would be needed for both the User prefs and tread content side of things.
Unfortunately, I'm also pretty busy at present and while I'm more than happy to sacrifice a day on a weekend, I've no intention of doing the whole thing alone (community spirit does not pay for my vices ). As Verb is the only other volunteer for coding and DeVore has offered to do some implementation (deployment?), I don’t think there’s enough here to make it fly, at least for me. Another two would probably do it, as long as the workload was spread out. 0 -
Advertisement
-
-
-
If we can get the subscribed threads using only the user ID, then I can quickly write you the necessary code.Originally posted by DeVore
What isnt there is the extraction script and formatting for the Avantgo bot.
Am I right in thinking that it’s all stored in MySQL? If so the SQL will be part of the PHP script (no stored procedures). However, I’d suggest, if you want to tackle the SQL, to do so as a series of functions in an SSI that can be drawn upon by myself and Verb (assuming he’s still on for it). You won’t need much PHP for that – also means that I won’t have to worry about your DB schema.This is why I presumed we'd be writing SQL at some stage and I'm happy to do that...
[/B]
If we’re dropping posting for the time being, then I’d agree.I dont think it will take more then the three of us to do it to be honest, the DB structure is already there.
[/B]
LOL. I was wondering how long it would take for that to be raisedI'll be up front about this: Even though I know both of you guys whatever code is written would have to be signed over to Boards Ltd. I dont want any clever clogs infecting us with a open-source style license (or worse) later down the line. Sorry to be paranoid but better that then in court![/B]
Seriously though - no problem. You won’t be getting any of my existing IP in this and maintenance ain’t my problem.
I’ll just take payment by way of credit for work done and a few beers :rolleyes:0 -
-
-
-
-
Originally posted by DeVore
What you do with this now, I dunno. Thats getting into the realm of how PHP handles recordsets. I like the idea of creating a number of include files that I can work on that perform functions for you... very kinda com-objecty...
You would want to put it in a function something like this:
[PHP]
function getSubForums($id) {
$SQL = "SELECT user.username, subscribeforum.";
$SQL .= "forumid , forum.title FROM [subscribeforum]";
$SQL .= ", [user], [forum] WHERE subscribeforum";
$SQL .= ".userid = ".$id." and user.userid = ".$id;
$SQL .= " and subscribeforum.forumid = ";
$SQL .= "forum.forumid";
$i = 0;
$rs= mysql_query ($SQL);
while($row = mysql_fetch_array($rs)) {
$TempArray[$i] = array (
"username" => $row["username"],
"subscribeforum" => $row["subscribeforum"],
"title " => $row["title"]);
$i++;
}
mysql_close();
return $TempArray;
}
[/PHP]
Easy
That way we can seperate the database logic from the display logic and you could put all the necessary SQL functions into an SSI for me (or anyone else) to draw upon and not worry about the database at all (splitting up the work); just the key values of the array being returned and the args needed in the first place.
You could probably cut and paste that code (warning: I just knocked it up - it's not even slightly tested) for any query. Other SQL operations (such as INSERTS, etc) would be much the same, but only returning a boolean (actually, in this cut down version we wont need any of those).
Edited 'cos I aready saw a silly mistake in above code0 -
-
-
Advertisement
-
-
-
-
Advertisement