Not signed in (Sign In)

Categories

Vanilla 1.1.5 is a product of Lussumo. More Information: Documentation, Community Support.

Help keep Vanilla free:
Welcome Guest!
Want to take part in these discussions? If you have an account, sign in now.
If you don't have an account, apply for one now.

Add-ons: Extension creation guidelines

Bottom of Page

1 to 19 of 19

  1.  
    • CommentAuthortrabus
    • CommentTimeJul 29th 2005
     # 1
    So I'm going to try and build an extension myself (I'm making a simple calendar), and I'm curious to how we should go about creating a table (by creating an install file for the extension, or putting it in through a conditional directly in the extension that would be triggered if no table exists ), what the naming convention would be (I like VEX_ personally, as it immediately points out that it's an extension), whether the table should be completely self contained to keep things neat, or if it's kosher to add to existing tables (for instance if there were an extension that only had a boolean it needed to add a field to the LUM_User table).

    Also, should extensions be contained in only one file, as I've seen so far, or can the extension have it's own folder/library that is accessed by a file that is in the base extensions folder? I sorta looked at the settings.php code that grabs extensions, but I'm not quite experienced enough to follow the mechanism completely.
  2.  # 2
    I think LUX would be a better prefix - vex means an annoyance ;( - lux is more like..luxury!
    I dont think adding colums to the user table would be a problem - though again its probably best to prefix the column name to stop overlap.

    As for the rest...mark?
    •  
      CommentAuthorjsanders
    • CommentTimeJul 29th 2005
     # 3
    a simple calendar! that's a good one! har!

    i've been waiting for the documentation to help illuminate this and several other database-type questions. i agree there should be some kind of standard as far as these things go, so good extension can have something to adhere to
    •  
      CommentAuthorjsanders
    • CommentTimeJul 29th 2005
     # 4
    mini - in general, adding columns to existing tables seems like a bad idea, but maybe you're just better at it than i am.
    • CommentAuthortrabus
    • CommentTimeJul 29th 2005
     # 5
    oh, yes LUX is much better. :)

    the table creation and the library/folder/multiple files for one extension are my biggest concerns really.
    •  
      CommentAuthorMark
    • CommentTimeJul 29th 2005 edited
     # 6
    I'm open to suggestions from everyone on this, but these are my thoughts:

    Database Changes
    I think that you should probably have an install script come with the extension. I think that having it check for a table every time a page loads and creating it if it doesn't is extra load that the application just doesn't need.

    I think that the table prefix should actually be as unique as the author of the extension so that we never get any naming conflicts on new tables. Like, it should remain with an LUM_ prefix, but then go further with the author's initials or something, like LUM_MOS_TableName.

    As for adding to existing tables, I think it should be done sparingly. Obviously there will be times when you just need to do it, but if you can keep it outside, then do it.

    Everyone should note that if you are looking at creating an extension that turns on based on user preference, you should hold off on altering the database in any way. I'm going to be writing the documentation on user preferences and everyone is going to love what I've done (no database changes should be necessary for adding new user preferences).

    Multi-File Extensions
    I think it is fine to create an extension folder with the extension name as the folder name. I imagine you'd have your ExtensionName.php file that uses whatever you've got in your ExtensionName folder. I think that's a lot tidier than dumping it into the extensions directory root.
  7.  # 7
    well in my migration script i added a phpBBid column to the users table - i guess its slightly different cause that was before the forum was in use but it doesnt remove it (by default) afterwards and still works happily so i dont see it as an issue?

    There's almost certainly a good reason why not to though...i'm not very good at much so i imagine your reason is probably perfectly valid.
    • CommentAuthortrabus
    • CommentTimeJul 29th 2005 edited
     # 8
    jsanders, I also agree that adding to pre-existing core tables should be a no-no, as the whole point of an extension is to add without modifying the core.
    •  
      CommentAuthorjsanders
    • CommentTimeJul 29th 2005
     # 9
    i have an idea of how the user preferences in the databases works (i have been closely scrutinizing the built-in shortcut keys extension), and i have to say that it is a stroke of genius.
    •  
      CommentAuthorMark
    • CommentTimeJul 29th 2005
     # 10
    *tips hat*
    • CommentAuthortrabus
    • CommentTimeJul 29th 2005 edited
     # 11
    Wow, quick answer! That's exactly what I was wanting to know, thanks Mark.

    I think then if an extension requires a table to be created, it have an install file in that extension's library. Regarding the structure and naming, I think it should go like so:

    extension.php - core extension file
    /extension - library folder, should always have the same name as the extension
    /extension/extension_install.php - install file, always has the extension name followed by '_install', to prevent install filename conflicts. Always located inside the library folder for the extension
    •  
      CommentAuthorjsanders
    • CommentTimeJul 29th 2005
     # 12
    i think the install script should be included in the library folder that has the extension name. it's not something that should ever be needed more than once or twice.
    • CommentAuthortrabus
    • CommentTimeJul 29th 2005 edited
     # 13
    Anyone have any ideas on how to handle additional style definitions for page elements added through an extension? For instance, the extension I'm making will need to have some styles defined for the calendar it builds.
    I know there must be some way to link another stylesheet .
    •  
      CommentAuthorlech
    • CommentTimeJul 29th 2005 edited
     # 14
    trabus, look at the yellowfade extension, i believe it throws a js file into the header area like some other extensions, replacing the js with a custom style sheet shouldn't be a problem then.
    • CommentAuthortrabus
    • CommentTimeJul 29th 2005
     # 15
    well, after poking around a little, I found the AddStyleSheet function in the Common.Controls.php file, but I haven't found where its used to add a stylesheet yet.
    I'll check into the yellowfade extension though, thanks.
    •  
      CommentAuthorstuart
    • CommentTimeJul 29th 2005 edited
     # 16
    Heres the stuff form YellowFade:


    if(in_array($Context->SelfUrl, array("index.php", "categories.php", "comments.php", "search.php", "post.php", "account.php", "settings.php"))){
    $Head->AddScript("./js/yellowfade.js");
    }
    • CommentAuthortrabus
    • CommentTimeJul 29th 2005
     # 17
    nice! this works:

    $StyleSheetLocation="extensions/calendar/calendar.css";
    if(in_array($Context->SelfUrl, array("index.php", "categories.php", "comments.php", "search.php", "post.php", "account.php", "settings.php"))){
    $Head->AddStyleSheet($StyleSheetLocation);
    }
    •  
      CommentAuthorlech
    • CommentTimeJul 29th 2005
     # 18
    good, now all you need to do is have that style sheet appear everywhere your calendar is present. :D
    • CommentAuthortrabus
    • CommentTimeJul 29th 2005
     # 19
    yep. I'm actually placing the calendar on the page using brady's custom html messages in the panel extension, which has an include of the calendar building function, which it calls and then places the result in the panel. I then add the stylesheet to the page using the AddStyleSheet function on the very next line.

1 to 19 of 19

  1.  
Add your comments
    Username Password
  • Format comments as
 
Back to Discussions Top of Page