PluginList format control block
The FORMAT control block is used to create individually formatted objects that can then be used in any of the individual OUTPUT methods.
- Available filters
- Basic example
- Examples of the use of the FORMAT control block (format and default value)
- Example with comments
- Using Font Awesome icons instead of content depending on the value of the field content
- Editable inline sample using the table template
- Editable inline sample in a smarty (or wiki) template
- Using Font Awesome icons instead of content depending on the value of the field content
- Display an Item Link (tracker item) linked to another item within a template page
Available filters
Name | Description | Boolean | Sample | Tiki Version |
---|---|---|---|---|
default | Display a default value or a default file when no value is available | no | "empty", "1140" (fileId) | - |
format | format the displayed value to something different that the db value (human readable) | no | "trackerrender", "date", "objectlink", etc. (see format parameters here) | - |
editable | Make the field editable so the value can be changed from the results display. Inline editing (found in admin control panels => trackers) must be enable. Must be used in conjunction with the trackerrender format (see above) and may require mode="raw" when using it with the table output template} | editable="inline" | - |
Note that in some cases the field that will be displayed has its own behavior and it can clash with the format you selected.
IE: A tracker field that is a "title" is pre-formatted as a link. If you set the format as "objectlink" (or you set the display inside a link) the display will end broken as Tiki will try to display a link inside a link.
For the default parameter, it's important to remember that the tracker field "Files" works a bit differently than the others with this parameter. The tracker field Files expect an Id from the File Gallery. When most of the other fields type will display the text of the default parameters the default for "Files" must be an existing file in a gallery. The file can be an "anonymous" portrait file or a plain white image or an image with only the text "Not Available", etc. Whatever you feel right for your usage.
Basic example
In most of the examples shown in PluginList output control block and PluginList advanced output control block you will see a FORMAT control block have been used. E.g. in the example shown for Table output as below, two FORMAT control blocks are used:
{LIST()} {filter type="trackeritem"} {filter content="water"} {OUTPUT(template="table")} {column field="title_link" sort="title" label="Title" mode="raw"} {column field="description" label="Description"} {column field="event_date" sort="tracker_field_18" label="Event Date"} {OUTPUT} {FORMAT(name="title_link")}{display name="title" format="objectlink"}{FORMAT} {FORMAT(name="event_date")}{display name="tracker_field_18" format="date"}{FORMAT} {LIST}
The first FORMAT control block defines an object with the name title_link
that is displayed in a specific way - this object reference is then used in the column control block in the body of the table OUTPUT. Similarly the second FORMAT control block defines the event_date
object which is also used in a column control block.
A similar use of the FORMAT control block allows the normal set of Smarty variables, eg {user}
etc, to be made available in Smarty templates - for example:
{FORMAT(name="theuser")} { {user} } {FORMAT}
{{}}
) around user
should have no spaces between them. Spaces are used here only to keep the user variable from being interpreted. This creates a reference object theuser
with the userId of the current user which can then be invoked in a server stored smarty template using the variable {$row.theuser}
.
Examples of the use of the FORMAT control block (format and default value)
{LIST()} {filter field="tracker_id" content="1"} {filter field="tracker_status" content="o"} {OUTPUT()} {DIV(class="h3")}{display name="name"}{DIV} {display name="photo"}%%% {display name="email"} {OUTPUT} {FORMAT(name="name")}{display name="tracker_field_userName"}{FORMAT} {FORMAT(name="photo")}{display name="tracker_field_userPhoto" format="trackerrender" default="1140"}{FORMAT} {FORMAT(name="location")}{display name="tracker_field_userLocation" format="trackerrender" default="Unknown"}{FORMAT} {LIST}
Default parameter applied on the "photo" field will display a default generic image if not file found.
Default parameter applied on the "location" field will display the text "Unknown" if the field is empty.
Example with comments
You might want to display all comments, and this script will retrieve them:
{LIST(cache="n")} {filter type="comment"} {pagination max="10"} {OUTPUT( template="table")} {column field="title"} {column field="comment_content"} {column field="object_link" mode="raw"} {column field="date"} {OUTPUT} {FORMAT( name="object_link")} {display name="object_id" format="objectlink"} {FORMAT} {sort mode="date_desc"} {LIST}
The FORMAT control block defines an object with the name object_link which is displayed in such a way that it is object_id which is displayed and formatted as objectlink; which makes the id clickable. This object reference is then used in the column control block in the body of the OUTPUT table.
This gives us the following result:
Title | Comment | Thread Id | Date |
---|---|---|---|
nocache=1 | I removed from wiki help because similar information is offered by plugin help for img plugin. I am not sure if this cache thing actually works. If it does, there perhaps is a feature check that should be added. Non cacheable images {img src=http://example.com/foo.jpg?nocache=1 width=200 height=100 align=center link=http://www.yahoo.com desc=foo}" displays an image height width desc link and align are optional | 810 | 2009-05-13 21:01:01 |
This was once in the code and may contain relevant info | I removed from wiki help because similar information is offered by plugin help. {file name=file.ext desc="description text" page="wiki page name" showdesc=1} Creates a link to the named file. If page is not given, the file must be attached to the current page. If desc is not given, the file name is used for the link text, unless showdesc is used, which makes the file description be used for the link text. If image=1 is given, the attachment is treated as an image and is displayed directly on the page; no link is generated. | 809 | 2009-05-13 20:47:40 |
Re: iframes on rewrite rules | > xavi - the iframes aren't working for me (IE7). Just big blank spaces. Not sure what the problem is. > > lindon I confirm bug on IE7 | 808 | 2009-05-10 05:12:52 |
iframes on rewrite rules | xavi - the iframes aren't working for me (IE7). Just big blank spaces. Not sure what the problem is. lindon | 807 | 2009-05-07 16:26:58 |
thank you! | I'm glad you like it - with 200 plugin and module pages I desperately needed something. Might could have used dynamic content, but I don't think that's available to registered users here so I wanted something everyone who had normal edit rights could edit. | 806 | 2009-05-04 16:53:10 |
brilliant idea, lindon! :-) | I was kind-of-reluctant to do that just for myself long ago, but nowadays, I see the benefits of doing that (after the many tenths of pages where I manually added those links). | 805 | 2009-05-04 06:21:28 |
allow_url_include = On | For an unknown reason - this should not be necessary- on some system - you need in /etc/php.ini allow_url_include = On to have the php function file_get_contents() working | 804 | 2009-02-20 21:45:55 |
All I can say is... | WOW! | 803 | 2009-02-12 23:12:17 |
Suggest redesign of doc.tw.o page | For the first time in a while I scrolled down and saw some article headings for the Editorial Board. I think a lot of folks don't pay attention to it because "out of sight, out of mind". I think there's a LOT of information overload on this site/page. Maybe get rid of the What's New box, get rid of the Keywords box (should be able to do a search on those), and maybe instead add a box to the left (or right) for the Editorial Board topics under the search box? Just some thoughts. I think some important stuff is getting overlooked because it's getting lost in the page, or so far down that people don't think it's relevant. | 802 | 2008-11-22 00:07:21 |
Perms example | Imagine a site where * Anonymous see nothing * Registereds see the approved pages and not the stagging pages * Authors see the staging+approved pages. They can edit staging pages. They see all the pages: They can categorized with other categories the pages. * Approvers see the staging+approved pages. They can approve pages. The groups are included in each other Anonymous < Registered < Authors < Approvers Group perms * Registered ** tiki_p_view * Authors ** tiki_p_edit ** tiki_p_wiki_view_history * Approvers ** tiki_p_remove ** tiki_p_rename ** tiki_p_rollback If you have other categories, you can add tiki_p_view_categories... as global permissions to Registered 2 categories * Staging * Approved Categories perms * Staging ** Authors: tiki_p_view_categorized ** Authors: tiki_p_edit_categorized * Approved ** Registered: tiki_p_view_categorized ** Approvers : tiki_p_edit_categorized Wiki staging setting: * If not in the group, edit is always redirected to the staging page edit: Approvers * Delete staging pages at approval: yes * Categorize approved pages with categories of staging copy on approval: yes * Force bounce of editing of approved pages to staging: yes * Category for staging pages: Staging * Category for approved pages: Approved * Category for pages out of sync: none * Unique page name prefix to indicate staging copy: * What happens during the staging process with this configuration? * For example a page named mypage. During the staging, 2 pages will be able to coexist, mypage = approved version, *mypage = stagging version * An author clicks edit on mypage, the edit page pannel opens the stagging page *mypage. When he saves *mypage, tikiwiki assigns *mypage to the stagging category. If an author clicks edit on *mypage, the edit page opens on *mypage * An approver approves *mypage. tikiwiki copies all the history of *mypage changes on top of mypage history and assigns the category approved to mypage. tikiwiki deletes *mypage | 800 | 2008-07-23 12:18:45 |
We see that this only gives us the information about the object (the comment in this case), but what if I want to have more information before visiting the comment?
One way to do this is to add a column which indicates the item being commented on. It is typically a wiki page or tracker item which is clickable and takes me there.
So let's make some changes and see what we have:
{LIST(cache="n")} {filter type="comment"} {pagination max="10"} {OUTPUT( template="table")} {column field="contributors"} {column field="title"} {column field="comment_content"} {column field="parent_object_title" mode="raw"} {column field="object_link" mode="raw"} {column field="date"} {OUTPUT} {FORMAT( name="object_link")} {display name="object_id" format="objectlink"} {FORMAT} {FORMAT( name="parent_object_title")} {display name="parent_object_type"}: {display name="wikiplugin_objectlink" format="wikiplugin" type="parent_object_type" id="parent_object_id"} {FORMAT} {sort mode="date_desc"} {LIST}
Here we have just added a new column whose label is "Parent Object".
The new FORMAT control block formats the parent_object_title field, which is the title of the comment's parent object, then with {display} tag we first display the name of the parent object, which is stored in the parent_object_type field. For example, if the parent object is a trackeritem, it will display "trackeritem:", and finally we display the link to the parent object, using the wikiplugin_objectlink plugin. This plugin allows you to create a link to a Tiki object according to its type and its identifier. Here you specify the link format as "wikiplugin", the object type as parent_object_type, and the object id as parent_object_id. For example, if the parent object is a trackeritem with id 1, this will generate a link to "tiki-view_tracker_item.php?itemId=1".
So you get a field that displays the name and link of the comment's parent object. For example, if the comment is linked to an item called "This is my first item", you display "trackeritem: This is my first item".
This gives us the following result:
Title | Comment | Parent Object | Thread Id | Date |
---|---|---|---|---|
nocache=1 | I removed from wiki help because similar information is offered by plugin help for img plugin. I am not sure if this cache thing actually works. If it does, there perhaps is a feature check that should be added. Non cacheable images {img src=http://example.com/foo.jpg?nocache=1 width=200 height=100 align=center link=http://www.yahoo.com desc=foo}" displays an image height width desc link and align are optional | wiki page: Wiki-Syntax Images | 810 | 2009-05-13 21:01:01 |
This was once in the code and may contain relevant info | I removed from wiki help because similar information is offered by plugin help. {file name=file.ext desc="description text" page="wiki page name" showdesc=1} Creates a link to the named file. If page is not given, the file must be attached to the current page. If desc is not given, the file name is used for the link text, unless showdesc is used, which makes the file description be used for the link text. If image=1 is given, the attachment is treated as an image and is displayed directly on the page; no link is generated. | wiki page: PluginFile | 809 | 2009-05-13 20:47:40 |
Re: iframes on rewrite rules | > xavi - the iframes aren't working for me (IE7). Just big blank spaces. Not sure what the problem is. > > lindon I confirm bug on IE7 | wiki page: Apache Clean URLs | 808 | 2009-05-10 05:12:52 |
iframes on rewrite rules | xavi - the iframes aren't working for me (IE7). Just big blank spaces. Not sure what the problem is. lindon | wiki page: Apache Clean URLs | 807 | 2009-05-07 16:26:58 |
thank you! | I'm glad you like it - with 200 plugin and module pages I desperately needed something. Might could have used dynamic content, but I don't think that's available to registered users here so I wanted something everyone who had normal edit rights could edit. | wiki page: Module and Plugin Includes | 806 | 2009-05-04 16:53:10 |
brilliant idea, lindon! :-) | I was kind-of-reluctant to do that just for myself long ago, but nowadays, I see the benefits of doing that (after the many tenths of pages where I manually added those links). | wiki page: Module and Plugin Includes | 805 | 2009-05-04 06:21:28 |
allow_url_include = On | For an unknown reason - this should not be necessary- on some system - you need in /etc/php.ini allow_url_include = On to have the php function file_get_contents() working | wiki page: Profiles | 804 | 2009-02-20 21:45:55 |
All I can say is... | WOW! | wiki page: PluginDBReport | 803 | 2009-02-12 23:12:17 |
Suggest redesign of doc.tw.o page | For the first time in a while I scrolled down and saw some article headings for the Editorial Board. I think a lot of folks don't pay attention to it because "out of sight, out of mind". I think there's a LOT of information overload on this site/page. Maybe get rid of the What's New box, get rid of the Keywords box (should be able to do a search on those), and maybe instead add a box to the left (or right) for the Editorial Board topics under the search box? Just some thoughts. I think some important stuff is getting overlooked because it's getting lost in the page, or so far down that people don't think it's relevant. | wiki page: Documentation | 802 | 2008-11-22 00:07:21 |
Perms example | Imagine a site where * Anonymous see nothing * Registereds see the approved pages and not the stagging pages * Authors see the staging+approved pages. They can edit staging pages. They see all the pages: They can categorized with other categories the pages. * Approvers see the staging+approved pages. They can approve pages. The groups are included in each other Anonymous < Registered < Authors < Approvers Group perms * Registered ** tiki_p_view * Authors ** tiki_p_edit ** tiki_p_wiki_view_history * Approvers ** tiki_p_remove ** tiki_p_rename ** tiki_p_rollback If you have other categories, you can add tiki_p_view_categories... as global permissions to Registered 2 categories * Staging * Approved Categories perms * Staging ** Authors: tiki_p_view_categorized ** Authors: tiki_p_edit_categorized * Approved ** Registered: tiki_p_view_categorized ** Approvers : tiki_p_edit_categorized Wiki staging setting: * If not in the group, edit is always redirected to the staging page edit: Approvers * Delete staging pages at approval: yes * Categorize approved pages with categories of staging copy on approval: yes * Force bounce of editing of approved pages to staging: yes * Category for staging pages: Staging * Category for approved pages: Approved * Category for pages out of sync: none * Unique page name prefix to indicate staging copy: * What happens during the staging process with this configuration? * For example a page named mypage. During the staging, 2 pages will be able to coexist, mypage = approved version, *mypage = stagging version * An author clicks edit on mypage, the edit page pannel opens the stagging page *mypage. When he saves *mypage, tikiwiki assigns *mypage to the stagging category. If an author clicks edit on *mypage, the edit page opens on *mypage * An approver approves *mypage. tikiwiki copies all the history of *mypage changes on top of mypage history and assigns the category approved to mypage. tikiwiki deletes *mypage | wiki page: Flagged revisions tab | 800 | 2008-07-23 12:18:45 |
Using Font Awesome icons instead of content depending on the value of the field content
Tweaking the sample above and using font awesome (integrated in Tiki) you can display corresponding icons for a content.
In this demo case we have a tracker with a "gender" field that hold 2 values, "male" or "female". There is a "male" and a "female" icon in Font Awesome and as both use the same term we can assign it to a div type icon and class.
{LIST()} {filter field="tracker_id" content="42"} {OUTPUT(template="table")} {column label="Title" field="title" sort="title"} {column label="Gender" field="gender"} {OUTPUT} {FORMAT(name="gender")}{DIV(type=i class=fa fa-{display name="tracker_field_gender"})}{DIV}{FORMAT} {LIST}
Editable inline sample using the table template
{column label="First Name" field="firstName" mode=raw} ... {FORMAT(name="firstName")}{display name="tracker_field_firstName" format=trackerrender editable=inline}{FORMAT}
Editable inline sample in a smarty (or wiki) template
In this wikiplugin embedded in a smarty (or wiki) template the field is set to be editable inline (note: format="trackerrender" is required ad well as the Inline editing (found in admin control panels=>trackers)
{wikiplugin _name=list} {literal} {filter content="2" field="tracker_id"} {output(template="mytemplate.tpl")} {ALTERNATE()} empty {ALTERNATE} {FORMAT(name="name")}{display name="tracker_field_name" editable="inline" format="trackerrender" default=""}{FORMAT} {/literal} {/wikiplugin}
So the 2nd column uses a FORMAT plugin where the contents of the field in question, tracker_field_data, is used as the class for a div but the default (used if the data field is empty) is set to be the bootstrap class "hidden" so the contents, the check mark, only appears if there is some data.
Obviously if the data is the name of some other class weird stuff might happen, but for most usual cases, it works as expected and saves having to make a new smarty template just for this simple list.
(Tip and example taken from a message from JonnyB in the developers list - thanks!)
Using Font Awesome icons instead of content depending on the value of the field content
Tweaking the sample above and using font awesome (integrated in Tiki) you can display corresponding icons for a content.
In this demo case we have a tracker with a "gender" field that hold 2 values, "male" or "female". There is a "male" and a "female" icon in Font Awesome and as both use the same term we can assign it to a div type icon and class.
{LIST()} {filter field="tracker_id" content="42"} {OUTPUT(template="table")} {column label="Title" field="title" sort="title"} {column label="Gender" field="gender"} {OUTPUT} {FORMAT(name="gender")}{DIV(type=i class=fa fa-{display name="tracker_field_gender"})}{DIV}{FORMAT} {LIST}
It will display a if the content of the field = male and a if the content of the field = female.
Display an Item Link (tracker item) linked to another item within a template page
When you use a template to display your plugin list you want other item related or linked to the item to open using the same template (or another it doesn't matter) but not to open the trackers built-in system. For this you need to enable the Alias feature and set it to use the template to display the tracker item, "record-" for this sample.
When you use an item link to link an item to other item (related, friend of, etc.) this is a kind of a problem.
Item link has 2 option to display and item link. Value and Link.
Value display the id of the content (ie: 6).
Link display the value of the content linked to the tracker item (ie: Bernard).
Your link should be like:
[record-6|Bernard]
So it open the item "Id6" in the "record-" template showing the value "Bernard" for the link.
To achieve this you need to create and use 2 row.
{FORMAT(name="name")}{display name="tracker_field_contact" format=trackerrender}{FORMAT} {FORMAT(name="id")}{display name="tracker_field_contact"}{FORMAT}
The first one with format=trackerrender will display the content of the tracker Item Link field as it is shown in the tracker (Bernard).
The second one without the format=trackerrender will show the real value for this field (6).
The assemble your link as follow:
[record-{display name="id"}|{display name="name"}]
It will complete the trick and open the item 6 using the record- template while the link displayed will show the right value, Bernard.