|
It seems that the load by content_id is redundant since it would have been loaded by liberty if it matches but there may be some case where the liberty load fails but it works in this file though the author (Nick Palmer) has a hard time seeing how this could be the case. At worst it is never called and it is only a couple of lines of code so it is still there.
|
|
-! sample/templates/sample_display.tpl
|
-
|
+!! sample/templates/sample_display.tpl |
This template renders an instance of the content stored in $gContent.
|
|
The first line in the file includes any templates that are registered with Liberty as navigational services. Likewise the last line includes templates for any services which are registered as view related services.
|
|
The middle portion of the file simply displays the content including edit and remove icons and information on the modifier of the content. It should be pretty self explanatory but does demonstrate the use of permissions, icons and various bits of information stored in $gContent->mInfo.
|
|
-! sample/bit_setup_inc.php
|
-
|
+!! sample/bit_setup_inc.php |
This is the file included by bitweaver to load the package and hook it into the system. The first part of the file registers the package with bitweaver providing only the bare minimum of information about the package, i.e. it's name and the directory for the package.
|
|
The file next checks if this package has been activiated and if it is registers the application menu for inclusion. Note that this call specifies the template to be used for the menu.
|
|
-! sample/templates/menu_sample.tpl
|
-
|
+!! sample/templates/menu_sample.tpl |
This is the template which is used to display the menu. It is pretty straight forward.
|
|
-! sample/BitSample.php
|
-
|
+!! sample/BitSample.php |
This is the class which represents an instance of the data type. It extends LibertyAttachable in order to allow it to be integrated into the Liberty system properly. The constructor thus calls the LibertyAttachable constructor and then sets it's internal id fields and ensures that the data type has been registered with Liberty properly.
|
|
-The load() method is responsible for loading the actual data from the database. It starts by trying to verify that the id's in the object set in the constructor are valid. If they are it begins setting up the bindVars array to have the sql required to join properly to get the instance.
|
-
|
+The __load()__ method is responsible for loading the actual data from the database. It starts by trying to verify that the id's in the object set in the constructor are valid. If they are it begins setting up the bindVars array to have the sql required to join properly to get the instance. |
It uses the LibertyAttachable provided getServicesSQL to load some of the variables and does some Joins to be able to pull out creator and modifier information in a single query. It then uses the results of this query to set various fields in the mInfo hash for the object.
|
|
-The store() method is responsible for storing an instance of the object to the database. It uses a call to associateInsert to update the database making calls to StartTrans() and CompleteTrans() to make sure the update is done atomicly making sure the data is verified first using the verify() method.
|
+The __store()__ method is responsible for storing an instance of the object to the database. It uses a call to associateInsert to update the database making calls to StartTrans() and CompleteTrans() to make sure the update is done atomicly making sure the data is verified first using the verify() method. |
|
-The verify() method verifies the data in the request meets the requirements for the class and stores values to be stored away in the content_store hash in order to make it so Liberty can store the class properly.
|
+The __verify()__ method verifies the data in the request meets the requirements for the class and stores values to be stored away in the content_store hash in order to make it so Liberty can store the class properly. |
|
-The expunge() method removes an instance of the object again using transactions to ensure that everything is done properly.
|
+The __expunge()__ method removes an instance of the object again using transactions to ensure that everything is done properly. |
|
-The isValid() method checks that the sample_id in the object is valid.
|
+The __isValid()__ method checks that the sample_id in the object is valid. |
|
-The getList() method returns an array of structures suitable for a list.
|
+The __getList()__ method returns an array of structures suitable for a list. |
|
-The getDisplayURL() method gives a url suitable for linking to the object. There currently doesn't seem to be support here for pretty URLs through the usage of mod_rewrite but there probably should be.
|
-
|
-! sample/list_samples.php
|
+The __getDisplayURL()__ method gives a url suitable for linking to the object. There currently doesn't seem to be support here for pretty URLs through the usage of mod_rewrite but there probably should be. |
|
+!! sample/list_samples.php |
This file presents a list of all of the content of the sample type. The top of the file includes the usual magic to include all the bitweaver code and the data type. It then does the package and permission verification steps taken in index.php described above.
|
|
The list page includes the ability to delete a large number of samples. So the next bit of this file is designed to handle that for of "edit". It does a confirmation first to make sure the user isn't making a mistake and then calls expunge for each of the items in order to delete them.
|
|
The next bit of code simply uses the BitSample class to load all of the samples from the database and places them in the context and then calls the display function on the list_samples.tpl template.
|
|
-! sample/list_samples.tpl
|
-
|
-This template simply renders the samples from the context providing a form to do the mass delete described above if that is active. It is pretty simple over all.
|
-
|
-! sample/edit.php
|
+!! sample/list_samples.tpl |
+This template simply renders the samples from the context providing a form to do the mass delete described above if that is active. It is pretty simple over all but contains some functionality easily overlooked. |
+E.g. sorting the result set is accomplished using ((function_smartlink)) in the table header. |
|
+!! sample/edit.php |
This is the file responsible for displaying an edit page for editing a sample. It first looks up a sample if there is one, fills out various parts of the mInfo structure of this object based on variables in the request and then saves out the object if requested to do so. If the save works it redirects to the display of this new entry.
|
|
The one unusual area in this file is the inclusion of the quicktags include file to load up the quicktags stuff and the setting of the textarea_id in the context. This variable is used by the WYSWIG and QuickTags stuff to know what text area to target when they are doing their thing.
|
|
Finally it displays the templte edit_sample.tpl to render the page.
|
|
-! sample/templates/edit_sample.tpl
|
-
|
+!! sample/templates/edit_sample.tpl |
This is the template which renders the edit page for a sample. The interesting bits of this file are the inclusion of the liberty templates as well as the smileys and quicktags templates. The inclusion of the liberty edit templates provides hooks for any liberty edit oriented services and the quicktags and smileys provide the ability to have those functions hooked to the text area through the name of the text area.
|
|
-! sample/remove_sample.php
|
-
|
+!! sample/remove_sample.php |
This file is responsible for handling the removal of a single sample as might be done from the edit page. There isn't really a lot in here that shouldn't make sense by this point from the understanding of all the other files. The one interesting bit is the use of the confirmDialog to show a handy confirmation dialog with a form on it for continuing. Doesn't bitweaver rock for making such things easy?
|
|
-! sample/mkpackage.sh
|
-
|
+!! sample/mkpackage.sh |
This script can be used to rename the sample package in order to make it easier to use it as a base for new packages. See ((SamplePackage)) for more information on using this to repackage the sample package as your own.
|
|
+! Other optional files |
+!! Package specific Styles and Javascript |
+If you need some CSS to make your package 'work', you can put these into your own css in your own package. You can put this anywhere you like, such as {code}sample/styles/sample.css{/code} and then call that file from your __sample/bit_setup_inc.php__ file using: {code}$gBitThemes->loadCss( SAMPLE_PKG_PATH.'styles/sample.css' );{/code} |
+The same applies to javascript files you wish to add that are not present in util/javascript/ {code title="Example bit_setup_inc.php file with additional CSS and Javascript loading"}<?php |
+global $gBitSystem; |
+ |
+$registerHash = array( |
+ 'package_name' => 'sample', |
+ 'package_path' => dirname( __FILE__ ).'/', |
+ 'homeable' => TRUE, |
+); |
+$gBitSystem->registerPackage( $registerHash ); |
+ |
+if( $gBitSystem->isPackageActive( 'sample' ) ) { |
+ $menuHash = array( |
+ 'package_name' => SAMPLE_PKG_NAME, |
+ 'index_url' => SAMPLE_PKG_URL.'index.php', |
+ 'menu_template' => 'bitpackage:sample/menu_sample.tpl', |
+ ); |
+ $gBitSystem->registerAppMenu( $menuHash ); |
+ |
+ // Load CSS file |
+ $gBitThemes->loadCss( SAMPLE_PKG_PATH.'styles/sample.css' ); |
+ // Load Javascript file |
+ $gBitThemes->loadJavascript( SAMPLE_PKG_PATH.'scripts/sample.js' ); |
+} |
+?>{/code} |
+ |
+Using this method is the least invasive and the most flexible since it allows other developers to {code}$gBitThemes->unloadCss( SAMPLE_PKG_PATH.'styles/sample.css' );{/code} if they do not want to load the CSS file. |
+ |
+!! Header and Footer templates |
+bitweaver allows you to insert code into the ~np~<head>~/np~ section without touching any files in the core. You can achieve this by adding a file called: {code}sample/templates/header_inc.tpl{/code} This file will be picked up and inserted automagically. You can test this with a simple script: {code title="Example header_inc.tpl"}{if $gBitSystem->isPackageActive( 'sample' )} |
+ <script type="text/javascript">/* <![CDATA[ */ |
+ alert( "It's a small world, but I wouldn't want to have to paint it." ); |
+ /* ]]> */</script> |
+{/if}{/code} |
|
+The same is true for {code}sample/templates/footer_inc.tpl{/code} |