Main Stories
Slash Boxes

Slash Open Source Project

Slashcode Log In

Log In

[ Create a new account ]

slashstyle

posted by pudge on 09:16 AM March 31st, 2001   Printer-friendly   Email story
We've written a document called "slashstyle" which is now in effect as the primary coding guideline for Slash. It is on CVS (in fry, /docs/), and it is on http://slashcode.com/docs/ and the Slash FAQ, along with the boilerplates.

All new code going into Slash sould follow it. If you have any problems, please let us know. The core team may make changes to the document at any time (and especially the boilerplates), and we will note significant changes when they are made.

This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login
Loading... please wait.
  • That document is a great start, but I'd like to see some documentation on the database functions.

    Like, if I wanted to write a plugin, how do access non-bender/slash tables? I don't really see any generic SQLSelect statements or anything.

    Maybe some pointers on important Slash functions, like getting table data, saving table data, and displaying stuff would great in addition to the slashstyle document.

    --

    --
    It's either on the beat or off the beat, it's that easy.
  • Like, if I wanted to write a plugin, how do access non-bender/slash tables?

    In Slash 2.0, you handle it yourself, in your own plugin. You could copy some of the code from Slash::DB and inherit sqlConnect (and other methods) from Slash::DB::Utility, if you like. You could use DBIx::Password or DBI directly.

    In Slash 2.2, you will be able to use a function called getObject() which will handle much of this for you.

    Anyway, I suppose what you're talking about is an API / programmer's guide, which could be a part of slashstyle, but we weren't really considering it at the time. It's something to consider for the future, but we don't really have the time to do it right now. If someone else wanted to put togther an API FAQ, that would be great.