I've been speaking with the vwar developers, at www.vwar.de (vWar is an excellent standalone clan management system, and efforts are being made to port it to PHP Nuke)
the developers support vwar being ported to different Content Management Systems, since many of their users have a CMS-based site, and would like vwar integrated to use their regular user database, etc
what the vwar developers would like to know is, are there any suggestions about how they can make vwar a more CMS-friendly system?
i imagine they will always have a standalone version, but they would like to make it easier for those of us that are trying to turn vwar into a module
the developers have already acknowledged my request that they change the default sql call ($db) to another variable (they will be changing it to $vwardb in the next release), to help prevent sql errors between systems
they have a fairly advanced system, though. there is support for admin-added fields, as well as completely restructuring the template-appearance/structure/color of vwar (templates are maintained in the database, with an easy-to-edit admin interface). they have member profiles (with the ability for the member to upload an image), a calendar system, a funds tracking system (add/remove funds), etc etc
all *helpful* suggestions are appreciated, and anyone who is a user of vwar, and would like to start a vwar-port team, please contact the vwar developers so that it can be an organized effort (there is already a fella named 'ecosys' who has been working on a PHPNuke port, and he's making some good headway, but i'm sure more help wouldn't be turned down)
_________________ Is it paranoia if they are really out to get you?
-------------------------------------------------------
sting usually hangs out at nukehaven.net
wapu Nuke Cadet
Joined: Aug 16, 2003
Posts: 9
Posted:
Tue Aug 26, 2003 10:09 pm
I spend too much time wandering around the internet aimlessly! I keep missing this stuff.
The number one suggestion I have, and this comes from my clan, is having just one Log in. Log into nuke and you are logged into vWAR. Admin in Nuke is an Admin in vWAR.
The Second thing we would like to see is vWAR using the nuke_users table for Contact info and personal stuff. Such as MSNM or YM. Keeping it in 2 places makes it tough.
Anything else with vWAR is managable.
Thanks for your work on this!
intel352 Lieutenant
Joined: Mar 11, 2003
Posts: 180
Posted:
Tue Aug 26, 2003 10:49 pm
heh, i guess i phrased my questions wrong
they want to know how to make vwar more CMS friendly... in *general* (not a specific instance... specific ports will be handled by different volunteers, but the vwar devs want to give a hand by trying to cut out some of the redundancy, or whatever)
Have any documentation as to how it's currently designed .. ?? Any ERD's, DFD's, UML diagrams? It's kind of hard to make suggestions, when you don't know how it's currently designed :p
I'm not familiar with the vwar, is it just PHP based, made to run on Windows, Linux & Mac (shudders), etc etc.
I've got some great ideas on how to develop a CMS, especially when it comes to database abstraction (however this does not apply directly to PHP Nuke, and might not be relevant depending on your goals).
~Steve
intel352 Lieutenant
Joined: Mar 11, 2003
Posts: 180
Posted:
Wed Aug 27, 2003 6:56 am
anything that doesn't apply *directly to nuke* is exactly what they need to know
they want info that would help integration into *any* CMS much easier
it's fully php/mysql, and as for documentation on it, i dunno, but i'll see if i can get one of the developers to post here w/ more info
and, go ahead and divulge your ideas, i'm sure they'd be appreciated
okay then.
intel asked me to write some information about VWar that could be useful.
First of all: Sorry for my bad english, it is only learned in school
The basic structure of VWar is the following:
There are two files (_header.php and _footer.php) to include the own header and footer information. This two files are always integrated in each page.
The basic code of VWar is based on two classes: the database-class (only for MySQL by now) and the template-class. We renamed database-class to 'vwardb', before that, it was 'db' and this off course meant trouble (why didn't nuke changed their class-name?!? ).
I know, this information isn't that helpful, but if you want to know one thing, just ask, i'll be around for some time.
The problem of a lot of Nuke-VWar-Users is, that they can't VWar as a module of Nuke. I never worked with Nuke (okay, i have it installed on my localhost, but i don't like it ), so i don't know, what something needs, that it can be added as a module. Any basic information would be helpful!
@Steve: Sorry, but what do you mean with ERD's, DFD's and UML diagrams?
As a quick answer (I'm at work, I will post more a little later).
DFD = Data Flow Diagram
ERD = Entity / Relationship Diagram
UML = Universal Modelling Language (ie: class design, attributes, data types, relationships, etc).
Basically anything that would describe what it is, you are trying to achieve.
To integrate the vwar system with PHP Nuke, your biggest hurdle will be to use the abstraction layer that Nuke has created.
Instead of doing mysql_query, you would do something of the following:
Code:
function foo()
{
global $dbi; // constant for database instance
global $prefix; // constant for table prefix, ie: nuke_table
$sql = "select * from ".$prefix."_sometable";
sql_fetch_row, sql_query, sql_num_rows all come from the sql_layer abstraction of PHP Nuke. Depending on the value of the $db_type of the config.php in Nuke (either MySQL, MsSQl, oracle, etc etc), it will try to make the appropriate calls to the database you have set. This is one of the great features of Nuke, when used right. By "right" I mean sticking to the SQL92a compliant commands.
Try to adhere to database standards in your code. ... avoid proprietary things like select * from table limit 3,4 which is ONLY available in MySQL.
For templating, perhaps use smarty.php.net another standard that is widely known by the PHP community. Considering using http://pear.php.net for code-reuse (why re-invent the wheel?)
Mannny things to consider
rooobin Nuke Cadet
Joined: Aug 27, 2003
Posts: 4
Posted:
Thu Aug 28, 2003 9:31 am
hmm, i think, vwar will remain an only MySQL-Script. This could be a feature in a future version, but this not really our most important ToDo. So, VWar will be only available for Nuke-Users with MySQL-Database in the next time...
And: Sorry, i still can't really understand those diagrams could you post an example of them, maybe i could do it for vwar, too then.
I think it's a proven fact that most programmers don't comment & diagram
I'll post some when I get a chance ... I just ended up making a glorious journey (moving).
Cheers,
~Steve
MikeMiles Lieutenant
Joined: May 29, 2003
Posts: 231
Posted:
Mon Sep 01, 2003 11:18 am
Quote:
I think it's a proven fact that most programmers don't comment & diagram
That may be true for open source hobby type projects but not for those creating/maintaining major systems. It use to be the same way with them too. Managers found out the hard way when the primary programmers left, it was extremely hard to get someone else to figure out what the code was doing to maintain it. Since at least the mid-80's, I would say all major systems started requiring commenting and adequate documentation.
In the os community, some projects' code is commented quite well while others are not. I haven't seen any use of diagrams and most lack good technical documentation. I think that's a result of many not being professional programmers. Then again, many programmers hate doing external documentation but are trainable to doing internal.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum