When you installed the extension you probably not have already created an folder for Categories and Properties. If this is the case do so now and go back to the Extension Manager and enter the UID of the created page(s) into the “Category Folders” and “Property Folders” fields.
It is completely legal to have categories and properties in two different folders altough this wasn't tested heavily and it is more safe to put categories and properties into the same folder.
When you have set up the extension fully go to the “Table Configuration Sysfolder” (called TCSF from now on) and create a new record of the type: “Product category”:
You will then see the record editing screen of the newly created category.
IMPORTANT: When you create the categories you can create a tree-structure of categories. The “lowest level” of those categories will get created as separate tables. So when you created 3 base categories and in each of them 2 sub-categories you will finally have 3 tables more in your database. The 6 sub-categories will not get created as tables but all of the fields assigned to them will be available in their parent table. But only those fields selected for a category (or inherited from parent categories) will be visible when editing a record assigned to this category. This is achieved via the “types” field of TCA.
When you create a category-record on the category-root-level you MUST fill in the fields Title and Alias. Title will be the name of the the table (it is a table because it's a root category) or the Category (or both) and Alias is just required for tables/categories on the root level. The alias will become the name of the table in the database. If you leave away the alias the table will get the uid of the category record as table-name (of course prefixed with some string).
A short listing of what the different fields of a category are for:
Field Name | Type | Description |
|---|---|---|
Title | string | The title of the table and/or category created. |
Alias | string | The name of the table in the databse. It will get prefixed with a shop specific prefix but you should define a suitable name for this table here. Only required when you create a root-category==table, for sub-categories it will not be required. |
Virtual | PALLETE FIELD select | This allows you to create “virtual” tables which just exist in the session variable of the clients browser. This is useful for the FE to create ordering forms. (See section: Ordering). You can either choose that a table shall be connected to the browser-session or the logged in FE-User. |
Allow Table on Pages | PALLETE FIELD boolean | When this checkbox is set record for this table/root-category can get created on normal pages and not only in sys-folders |
Label property | PALLETE FIELD database relation to shop properties | Here you can select a property which shall get used as label for the records of this table. Sadly currenlty all properties get shown and not only those which are already selected to be part of the table. This can be very annoying as you can select a field to be the label which is not contained in the table. This cannot be fixed due to a bug in TYPO3's ###REC_FIELD_fielname### TCA construct. |
Sorting property | PALLETE FIELD database relation to shop properties | This property allows you to select by which field the tables is ordered in the BE by default. The same problem as with the above label field occurs here (all properteis shown not only in “Properties” selected ones) |
Sorting direction | PALLETE FIELD select box | Allows you to select in which order the sorting get's performed. |
Language | database relation to sys_languages | Shows the language of the current category record. Use the “translate” select-box at the top of the editing screen for translating a category/table. When a root-category/table is translated you will also be able to create translations for the records in the associated table. |
Parent category | database relatation to shop categories | Here you can select the parent category for the actual category. If you select a category the current category will become the child of the selected category and will inherit all it's properties. Sub-categories will be made available in the category selector of each created “product”-record. |
Image | image field | Here you can upload an image to each table/category which can get used in different places. |
Icon | image field | Here you can upload an icon (preferrably 18x16 px) which get's used as icon for the table. This is only visible when you didn't select a parent category – so the actual category is a root-category/table. |
Description | RTE field | Here you can write a description for each table/category which can get used in different places. |
Properties | database relation to shop properties | Here you assign which properties each table should have. You can also assign properties to sub-categories then the table will also contain those fields but they will only get shown in the BE when a “product” record has this category set. |
Now you can start to create your first properties.
Go to the page you configured as “Base Page” for the properties (can be the same page where the categories are located) and create a record of type “Shop Property”.
You get a form with some fields of which the Top two (Title, Alias) are mandatory (REQUIRED). Altough alias is no real requirement it should always get filled. The same as with root-categories/tables the alias will become the fieldname of the fields/properties in the database. The fieldname will be prefixed with the prefix you defined in the Extension Manager Installation Configuration of the extension.
Now a short list of what the different fields are for:
Field Name | Type | Description |
|---|---|---|
Title | string | The title of the field/property. It will get used in the BE as label for the field. When you translate the property record this will be the only available field – letting you define the translated label for BE Users with the language translated to. |
Alias | string | The alias of the field property will get used in conjunction with the field prefix you configured in the Extension Manager Configuration as the fieldname in the database. If you do not insert a value here the UID of the the property record will get used as field name which results in quite unreadable tables – which is also not nice for export. |
Language | database relation to sys_languages | Shows the langauge of the current property. Use the “translator” select box at the top to translate the actual property. The page on which the properties reside must be translated for the “translator” box to be visible. |
Parent property | database relation to shop properties | Some types of properties allow to have child-properties. If you have already created such properties (like select boxes or containers) you can select that the current property shall be a child of the selected property. (See explanation of special container types below) |
Parent property value | select box | When you have selected that the current property shall be a child of a select-box property you can select which value the parent-property shall have so the current property is visible. (See explanation of special container types below) |
Language mode | select box | Selects how this field/property behaves when the record it is assigned to get's translated. The options are quite self explanatory. But here a short description: Copy value: The value from the default langauge get's copied over to the translated record. Don't translate: The field is not shown in the translated record. Inherit if blank: Nothing get's copied and when the field is empty in the translated record the value from the original record get's used. Don't copy original contents: The values from the language original are just not copied. Prefix with Language Title: The values from the language original are copied and prefixed with a “[Translate to .....]:” prefix. |
A fully configured RTE field/property looks for example like:
You can play around a little bit with the different kind of properties but you will soon start to ask yourself what the special property “Container” is and why you can select a parent property.
If you want to have a quick start and not get confused at the beginning skip the follwing the follwing two sections.
A container is something you probably already know from TemplaVoila FlexForms or from the extension kb_tca_section. A section is an area in the record editing screen which can hold an arbitrary amount of “subsets” which each has fields again.
A picture is more than thousand words so here is a picture of a section/container field as it get's rendered in the BE:
You possibly know that you can add additonal “Zuordnung Segment” entries with the selectbox at the top. Each of those section-elements is again a table in the database which has the shown fields and a relation back to the record they are contained in.
So if you want to create such a section in one your tables/root-categories then just create a “Container” property and then assign this Container property as Parent property to all properties which shall be contained in the section.
UPDATE: Since T3 4.1 supports “Inline relational record editing” (IRRE) - which is exactly the same as containers/sections the extension has been updated to generate IRRE-fields instead of old fashioned containers like in the picture above. So the above screenshot is outdated.
When you click on relLang you have in your Select boxes only one Lang not all.
When you create a select-box it also counts as property which can get selected as “Parent property”. As soon as you select a Select-Box in the Parent-property field you will get an additonal field called “Parent property value” in the record editin screen of the property.
The current property will now only get shown in the BE when you have set the select-box you assigned as parent to the value selected in the “Parent property value” field. This may be a bit of confusing at the beginning but I will shed some light on it.
It behaves similar like the “type” field of tt_content. Depending on which type of content element you have selected when editing a content element you have different fields available. Now when you have created such a parent/child structre with select boxes for one shop-table then the child-fields will only be visilble when the parent (the select box) got set to a specific value.
This enables you to create very complex BE forms. For example if you have a book shop and you made a select box which allows you to choose what kind of “book” you have (i.e. “Magazine, Technical reference, Child book”) then the input field “Release cycle” wil only get shown when you selected “Magazine” in the select box (as technical references and children books do not have a release cycle – magazines do).
When you have succesfully created a root-category and some properties the only thing left to do is to go to the category record again and select all properties this table/root-category should have in the “Properties” select box at the bottom and to select the Sortin and Label property.
When you have done this delete the Shop-Cache using the Tools>Shop module. Select “Cache” in the select box on the top right and press the button “Clear cache” once.
When you now visit a page in the List module and choose to create a record you should see your newly created table available. If this is not the case you most probably didn't check the “Allow Table on Pages” checkbox in the category record and tried to create the record on a different page than a sys-folder.
When you have created your first record you may suddenly be disappointed because your fields do not show up but only the category selector. This is currently normal. Even if you do only have one category you still have to select it explicitly. You can enable that a specific category shall be set as default by setting the User TSConfig option:
TCAdefaults.tx_kbshop_tbl_yournamehere {category = 3
}
Of course replace “yourtablename” with the alias you gave the table and “3” with the uid of the category which you would like to select as default.
You will soon notice that the properties you create are in a Tab (similar like the Tabs from Flexforms) called "Basic" and may ask yourself how you can create additonal Tabs. This is easy: Just create a subpage in the page where your properties are located (only one level deep allowed) and give the page a title which shall be shown as Tab-Title.
You have to enter this page into the “propertyFolder” Installation Configuration which you set when installing the extension. You have to add it to the end of list cause at the top always the main property folder has to get listed.
Now just move over some properties to the new page and hit the clear-shop-cache button in the KB-Shop BE module.
After those steps the properties move should show up in a new Tab. When you are using section/container fields the section will show up in the Tab where the container property is located even if the sub-properties of the container are located on a different page.
Now you can start to insert some testing records on a page and you will surely soon want to see some output in the FE. To begin this just go to the page where you want to show a listing of those records and create a content element of type “Plugin: Shop (cached)” there.
When you created the FE plugin the first step you should take is to choose the table you want to display from the field “Displayed Table” after chaning it the forms updates itself.
You can then go through all the available options and set it to your needs. Below is a short table of what each field is for.
Field name | Type | Description |
|---|---|---|
Product Folders | database relation to pages | Here you select all pages from which you want to show records of the selected table. |
Product Folders recursive | select box | Here you can choose if you wish to collect also the records on the subpages of the page specified in “Product Folders” |
Template File | string | Here you can give the path to a template file to use. |
Displayed Table | database relation to (root-) categories | Here you have the choice to select from all created tables the one which you want to display using this plugin. |
Disable single-view | checkbox | When checked the singleView link doesn't get generated when in listView |
Disable list-view | checkbox | When checked the listView link doesn't get generated when in singleView |
Items per page | integer | Defines how many items get listed per page |
Show page browser | boolen | When checked and there are more items for the current query than elements per page a pagebrowser gets shown |
Pages in browser | integer | Define how many pages get shown in the pagebrowser |
Show first and last link | boolean | When set a link to the first and last page get generated in the pagebrowser. |
Show previous and next link | boolean | When set a link to the previous and next page get generated in the pagebrowser |
Show criteria selector | boolean | When set and user-definable criterias are also set a criteria selector gets shown in the FE which a visitor can use to define criterias after which he wants to filter the displayed records |
Criterias | SECTION | See following table “Criterias” |
Submit Target OK | database relation to pages | Here you can select a page to which the user shall get redirected when all fields of the current forms have been filled properly. This is used for Ordering forms. |
Form table | SECTION | See the following table “Form tables” |
Search page | databse relation to pages | Here you can set a page to which full-text search request get posted. Different to the criterias full-text searches (searches after a specific word) can not get cached. For this reason you have to direct serach-request to a special page where an uncached version of the plugin is inserted. NOT IMPLEMENTED CURRENTLY |
You can easily define which records shall get shown by defining criterias in the listing plugin. More or less you build up the WHERE part of the query which selects the records from the databse.
To define criterias you should already have used Flexform Sections once else it will be a little bit confusing for you I guess. To create a criteria go to the “Criteria” tab in the FE plugin and choose “NEW Criteria Item” from the select-box. When you selected it at the first moment nothing will happen – you have to save the record first using the normal “Save” button at the top and end of the record editing scren.
After saving the “NEW Criteria Item” selection a new criteria item will show up in the form. Such an item looks mostly like in the follwing picture:
The topmost field in the criteria item is named “Field”. Here you can select which field of the table shall get compared to another value. All other options are explained in the table below:
Field name | Type | Description |
|---|---|---|
Field | select box | Here you can select from all fields the current table has. The selected field will get compared in the WHERE query which selects the items to display in the FE |
User selectable | checkbox | If you check this option all other options will disappear and the visitor of the website can choose which value the field selected in “Field” shall have. (See: Criteria selector) |
Compare string/integer/etc. | different | Using the “Compare” field you can select “how” the value of the field is compared to the specified value. |
Value | different | Here you can either input (if you mad a Text/Integer criteria) or select (if you made a db-relation criteria) the value to which to compare against. |
Negate compare results | boolean | When set the result of the comparison will get negated – this is especially useful for database relation fields to select that specific values should not occur. |
The KB-Shop extension also supports Ordering Forms for letting website visitors order your products. Currently no billing mechanism is implemented for letting the visitors directly pay in your online-shop but only mails can get sent and orders can (must?) get stored in the database. This requires additonal work from you for each order – to process it manually.
The concept of KB-Shop Ordering Forms is genius if you think some time about it:
In TYPO3 there already exists a “huge” and very powerful forms library for generating fields out of database descriptions (TCA arrays): t3lib_tceforms. This library is normally used for rendering the record-editing screens in the BE for all different kinds records (records of all tables).
Now kb-shop simply utliilzes those form rendering libraries but instead of storing each record in the database it first is simply stored in the user-session of the clients browser which most shopping-cart systems do. This concept is called "virtual" tables.
When a user has finished his ordering process this “virtual” record gets transferred to a real database table and via additonal hooks also mails can get sent to specific addresses (where people process the order then).
The sending of mails and all extra data handling of orders (except storing them in the database) is not part of KB-Shop but will get implemented by add-on extensions which hook into KB-Shop.
You have to create an ordering form table which contains fields like firstname,lastname,address,zip,city for letting the user input his delivery and contact data and in this root-category/table you should have a section where each element contains at least one field: "ordered product" and most probably a second field "ordering amount" which specified how many items of a product have been ordered. This way (the ordered items themselves are section elements) you get a nice display for orders in the backend.
Here a listing of all fields available for a “Form table” section element:
Field name | Type | Description |
|---|---|---|
Form name | string | The name of this form. (Not used currently?) |
Form table | database relation to “virtual” root-categories | Here you can select the “virtual” table which gets used to store the data in the user session. This table defines which fields are available in the ordering process (Firstnam, Lastname, etc.) |
Save table | database relation to “non-virtual” root-categories | Using this field you define to which table the virtual table shall get saved when finishing the order process. |
Transfer TS | text | Here you can define TypoScript which “translates” the virtual-table values to values acceptable for the real tables. The syntax is explained in the section “Ordering system” |
See section “Ordering system” for more details on ordering.
Of course for the first test we must not miss an working HTML template. As all fields of kb_shop tables are completely dynmically defined you can hardly give an “default” template. So in the res/ folder of the extensions directory only a template is included which shows some basic things you can do within the HTML template.
First of all there are 2 main parts in a template:
<!-- ###TMPL_listView### begin -->
and
<!-- ###TMPL_singleView### begin -->
You can easily create custom views by defining a template key in your TS-Setup. Then the main part will be called:
<!-- ###TMPL_listView_YOURKEY### begin -->
or TMPL_singleView_YOURKEY respectively (see TS option: plugin.tx_kbshop_pi1.subpart.listView / singleView)
In such a “main part” there are five different possible kind of subparts:
<!-- ###PART_criteriaSelector### begin -->
<!-- ###PART_criteriaSelectorEmpty### begin -->
<!-- ###PART_pageBrowser### begin -->
<!-- ###PART_pageBrowserEmpty### begin -->
<!-- ###PART_listing### begin -->
<!-- ###PART_listingEmpty### begin -->
PART_criteriaSelector contains the criteria selector. PART_listign contains the actual listing of records, PART_pageBrowser the pagebrowser and PART_listingEmpty gets shown instead of PART_listing when no elements are found for the currently defined criteria.
Following is a short reference for all markers allowed in the template. SingleView is completely similar to listView except that only one item is rendered. Whenever a token like “++fieldname++” or “++cobjname++” occurs you have to replace this token by a valid fieldname not including the prefix set in the install tool (so just the alias or UID of the property). In case of a cObject ++cobjname++ has to get replaced with the TS key of the cObject. So if you define for example
graphicalTitle = IMAGE
then the marker would be “###COBJ_ITEM_graphicalTitle###.
Name (without ###) | Type | Valid in (Level) (without ###) | Description |
Template file top level (0) | |||
TMPL_listView | main-subpart | file top level (1) | When you show a listing of records the listView main-subpart of the template file will get used. |
TMPL_singleView | main-subpart | file top level (1) | When you show a single record the singleView main-subpart of the template file will get used. |
TMPL_listView_++customkey++ | main-subpart | file top level (1) | When you show a listing of records and you have defined that a special main-subpart shoould get used using the subpart.listView TS configuration variable then this main-subpart of the template file will get used. |
TMPL_singleView_++customkey++ | main-subpart | file top level (1) | When you show a single record and you have defined that a special main-subpart shoould get used using the subpart.singleView TS configuration variable then this main-subpart of the template file will get used. |
Global markers | |||
ITEMS_found | marker | Anywhere | The number of found items. |
ITEMS_index_begin | marker | Anywhere | The index of the first element shown on the current page (changes when browsing through the pages using the page browser) |
ITEMS_index_end | marker | Anywhere | The index of the last element shown on the current page (changes when browsing through the pages using the page browser) |
COBJ_LISTING_++cobjname++ | marker | Anywhere | This marker gets replaced by cObject specified by ++cobjname++. You have to set the TS objects in your TS setup like: plugin.tx_kbshop_pi1.listView.cObjects.myCObject = TEXT you must of course replace listView by singleView when you are inserting the cObject in the singleView. ++cobjname++ would be myCObject in this case. |
LINK_listView_HREF_++linknum++ | marker | Anywhere | This marker contains a link to the listView which can be configured via TS. The special about this link markers is that while they get generated by the ->typoLink method the values: linkViewUid - item to show linkPageNumber - page to show are available in the registers of TSFE. which means you can access those values using a .data = register:linkPageNumber construct.. ++linknum++ is the number you used in the TS setup to define the link. |
LINK_singleView_HREF_++linknum++ | marker | Anywhere | The same as for the above listView link except that this link links to a detail view (specified by the value in the register linkViewUid) |
Main-subpart top level (1) + Global markers | |||
PART_criteriaSelector | subpart | TMPL_* (2) | This subpart contains the criteria selector which allows a website visitor to select criterias for filtering the listing on his own. Normalls this selectors get rendered as checkboxes but you can easily render them as text links or in other forms. |
PART_criteriaSelectorEmpty | subpart | TMPL_* (2) | When no criteria selector shall get shown then the contents of this subpart get shown instead. This subpart allows no other subparts or markers inside. |
PART_pageBrowser | subpart | TMPL_* (2) | This subpart contains a page browser which allows to browse between different pages of the listing when the current number of records (depending on the set criterias) don't fit onto one page (set in the FE-Plugin using: Items per page) |
PART_pageBrowserEmpty | subpart | TMPL_* (2) | When no page browser has to get rendered (because it is deactivated in the FE plugin or there are less records than shall get shown on a page) this subpart will get rendered instead of PART_pageBrowser. This subpart allows no other subparts or markers inside. |
PART_listing | subpart | TMPL_* (2) | This subpart contains the list of records. Even in single view the single record is contained in this subpart. |
PART_listingEmpty | subpart | TMPL_* (2) | When no records are available for the currently selected criterias (or there are none at all) then this subpart will get shown. This subpart allows no other subparts or markers inside. |
Subparts of ###PART_criteriaSelector### (2) | |||
CriteriaItem | subpart | PART_criteriaSelector (3) | This subpart contains a single criteria selector item. Currently there are two options to render a criteria item. As a select box or text links (using this subpart) or as a checkbox (for 0/1 properties). Also lists of checkboxes (up to 10) are possible. This subpart will get repeated and concatenated for each criteria item a user can select from. Meaning for each select-box. |
CriteriaItemCheckbox | subpart | PART_criteriaSelector (3) | This subpart contains the code for a checkbox criteria selector item. |
Subparts of ###CriteriaItem(Checkbox)### (3) | |||
TITLE | marker | CriteriaItem CriteriaItemCheckbox (4) | The title for the current select-box or checkbox. |
ELEMENT_NAME | marker | CriteriaItem (4) | This marker contains the <select> tag name attribute value which has to get used for the tag. It is commonly not used when the criteria selectors get rendered as text links. |
CriteriaSelectorCheckbox | subpart | CriteriaItem Checkbox (4) | This subpart contains the single checkboxes in case of multiple checkboxes (or just one entry in case of a single checkbox) |
CriteriaSelectorOption | subpart | CriteriaItem (4) | This subpart contains a single selector option or Text-Link for normal criteria items (not checkboxes) |
Subparts of ###CriteriaSelctorCheckbox# and ###CriteriaSelectorOption### (4) | |||
LABEL | marker | CriteriaSelectorCheckbox CriteriaSelectorOption (5) | This marker contains each label/title for the single values of the criteria item select-boxes (or link lists). It will contain the label for the different checkboxes in the case of multiple checkboxes. |
LINK_HREF | marker | CriteriaSelectorCheckbox CriteriaSelectorOption (5) | This marker will contain links to the current page but with GET parameters set so the listing is filtered to show only records where the current criteria equals the value of the current option. The links have a cHash parameter and the resulting pages will be fully cached. |
VALUE | marker | CriteriaSelectorOption (5) | The value of the current select-box option (or text-link) is contained in this marker. In the case of text-links it is mostly not required cause you should better use the above LINK_HREF marker. |
SELECTED | marker | CriteriaSelectorOption (5) | This marker contains normally nothing but when the current value/option/link is selected for filtering it will by default contain the string: selected=”selected” But you can change what the content should be using the TS option: plugin.tx_kbshop_pi1.listView.criteriaSelector.selectedValue |
ELEMENT_NAME | marker | CriteriaSelectorCheckbox (5) | This marker will contain the <input> tag name attribute value for the single checkboxes. Also in the case of just a single selectbox the name will be on this level. The same logic as with listView/singleView is used. A single checkbox is just a list of checkboxes with just one entry :) |
CHECKED | marker | CriteriaSelectorCheckbox (5) | This marker contains normally nothing but when the current checkbox is selected for filtering it will by default contain the string: checked=”checked” But you can change what the content should be using the TS option: plugin.tx_kbshop_pi1.listView.criteriaSelector.checkedValue |
Subparts of ###PART_pageBrowser### (2) | |||
ITEM_count | marker | PART_pageBrowser (3) | Contains the number of records for the currently selected criterias (or for all available records if no criterias are set) |
ITEM_equalWidth | marker | PART_pageBrowser (3) | Contains 100 divided by the above value. It can get used to divide the pageBrowser into html elements of equals width depending on the number of currently shown records. |
BROWSE_itemFirst | subpart | PART_pageBrowser (3) | This subpart contains markers for the “First page” link in the page browser. |
BROWSE_itemFirstEmpty | subpart | PART_pageBrowser (3) | The contents of this subpart will get shown when the respective subpart (name without Empty) shall not get shown or is not available (i.e. first link will not be available when you are on the first page). This subpart does not contain any further subparts or markers. |
BROWSE_itemPrevious | subpart | PART_pageBrowser (3) | This subpart contains markers for the “Previous page” link in the page browser. |
BROWSE_itemPreviousEmpty | subpart | PART_pageBrowser (3) | The contents of this subpart will get shown when the respective subpart (name without Empty) shall not get shown or is not available (i.e. first link will not be available when you are on the first page). This subpart does not contain any further subparts or markers. |
BROWSE_itemList | subpart | PART_pageBrowser (3) | This subpart contains another subpart which forms the list of pages in the page browser. This subpart gets repeated and concatenated for each single page. |
BROWSE_itemListEmpty | subpart | PART_pageBrowser (3) | The contents of this subpart will get shown when the respective subpart (name without Empty) shall not get shown or is not available (i.e. first link will not be available when you are on the first page). This subpart does not contain any further subparts or markers. |
BROWSE_itemNext | subpart | PART_pageBrowser (3) | This subpart contains markers for the “Next page” lllink in the page browser. |
BROWSE_itemNextEmpty | subpart | PART_pageBrowser (3) | The contents of this subpart will get shown when the respective subpart (name without Empty) shall not get shown or is not available (i.e. first link will not be available when you are on the first page). This subpart does not contain any further subparts or markers. |
BROWSE_itemLast | subpart | PART_pageBrowser (3) | This subpart contains markers for the “Last page” link in the page browser. |
BROWSE_itemLastEmpty | subpart | PART_pageBrowser (3) | The contents of this subpart will get shown when the respective subpart (name without Empty) shall not get shown or is not available (i.e. first link will not be available when you are on the first page). This subpart does not contain any further subparts or markers. |
Subparts of ###BROWSE_*### (3) | |||
LINK_HREF | marker | BROWSE_* (4) | This marker contains a link (only the href attribute) to the respective page (depending on the subpart the marker is found in). |
LINK_SELECTED | marker | BROWSE_* (4) | This marker containts the contents of the LL label text_browser_selected when the currently rendered page is the active/selected/displayed one (makes only sense inside BROWSE_itemList) |
LABEL_first | marker | BROWSE_* (4) | Contains the LL label label_browser_first |
LABEL_previous | marker | BROWSE_* (4) | Contains the LL label label_browser_previous |
LABEL_next | marker | BROWSE_* (4) | Contains the LL label label_browser_next |
LABEL_last | marker | BROWSE_* (4) | Contains the LL label label_browser_last |
LABEL_item | marker | BROWSE_* (4) | This marker contains the label for the currently rendered page. It will contain the contents of the LL label label_browser_page in which the marker ###PAGE### is substituted with the number of the current page. If the page is the current page also the marker ###MARKER_BEGIN### and ###MARKER_END### are substituted with a <span> tag (on pages other than the current those markers are substituted with an empty string) |
Subparts of ###PART_listing### or ##PART_++sectionnanme++### (2,4,6,8, ...) | |||
LIST_item | subpart | PART_listing (3) | This subpart gets repeated for each record found for the currently setted criterias. In the case of singleView it will get repeated only once. |
LIST_++sectionname++ | subpart | PART_++sectionname++ (5, 6, 8, 10, ...) | This subpart gets repeated for each section record found for the currently rendered record (or secton record in case of recursion). Multiple LIST_++sectionname++ subparts also get's created when you define an overlay. |
Subparts of ###LIST_item### (3) | |||
FIELD_SUBPART_++fieldname++ | subpart | LIST_item LIST_++sectionname++ (4, 6, 8, 10, ...) | The contents of this marker will get kept if the field which is specified in the subpart does contain a value which evaluates to true. When the current field contains a value which evaluates to false thie contents of this subpart get removed. The markers in this section (on level 4) also can get used in this subpart so they would be on level 5 in fact. This also applies to the below subpart. |
FIELD_SUBPART_++fieldname++Empty | subpart | LIST_item LIST_++sectionname++ (4, 6, 8, 10, ....) | The opposite of the above subpart. |
FIELD_RAWVALUE_++fieldname++ | marker | LIST_item LIST_++sectionname++ (4, 6, 8, 10, ...) | This marker contains the raw database value of the specified field. |
FIELD_VALUE_++fieldname++ FIELD_VALUE_++sectionname++_++fieldname++ | marker | LIST_item LIST_++sectionname++ (4, 6, 8, 10, ...) | This marker contains the value of the specified field after some basic processing (RTE fields are passed through lib.parseFunc_RTE and database relations are resolved to the titles of the records they point to.) The value of this field can also get set using stdWrap using a TS like the below. The ->data array of the cObj which is rendering the stdWrap is filled with the values for the current row. Meaning you can access them via .field = fieldname (where fieldname is an alias you set for a property). plugin.tx_kbshop_pi1.listView.itemList.fields.myFieldName.stripHtml = 1 of course you have to replace listView with singleView if you want to stdWrap the field in singleView. myFieldName has to get replaced with the value you also use for ++fieldname++ (the alias of the property/field). stripHtml is just an example for some stdWrap property. The fields of a container record get automatically filled into the marker with the ++sectionname++ included. This helps to distingush between fields of the main-table and containers (or overlayed tables) |
PART_++sectionname++ | subpart | LIST_item LIST_++sectionname++ (4, 6, 8, 10) | This subpart will contain the elements for a section/container field in a record. The contents of this subpart can be the same as those of a PART_listing subpart except that they render a section-element. As they are themselves contained in PART_listing (exactly in the LIST_item element of a PART_listing subpart) this nesting is recursive. Except that not a LIST_item subpar is repeated inside this element but rather a LIST_++sectionname++ subpart. A PART_++sectionname++ subpart also get's created when you define an overlay. |
PART_++sectionname++Empty | subpart | LIST_item LIST_++sectionname++ (4, 6, 8, 10, ...) | When a section field is empty (i.e: has no section elements) this subpart will get rendered instead and the above will get removed |
COBJ_ITEM_++cobjname++ | marker | LIST_item (4) | This marker will get replaced with a cObject which get's rendered individually for reach record displayed. Thus it is possible to do a lot of nice things with values like generate GIFBUILDER images out of uploaded files (i.e: watermarks). You have to set the cObjects for the item like in the following TS: plugin.tx_kbshop_pi1.listView.itemList.cObjects.myCObjName = IMAGE Again you have to replace listView with singleView when you want to have the cObject available in the TMPL_singleView main template. myCObjName has to get replaced with the same value you used for ++cobjname++. |
COBJ_++SECTIONNAME++_++cobjname++ | marker | LIST_++sectionname++ (6, 8, 10, ....) | This marker will get replaced with a cObject generated for each record of a section field individually. This means you can create cObjects dependend on the values of a section-element. You set a TS object like in the following TS: plugin.tx_kbshop_pi1.listView.itemList.++sectionname++.cObjects.myCObjName = RECORDS Again you will have to replace listView with singleView when you want to render the cObject for singleView. ++sectionname++ has to get replaced with the name of the section (the alias of the container field). myCObjName should be the same label which you used for ++cobjname++. Note that in the marker the sectionname must be uppercase. |
ITEM_even ++SECTIONNAME++_even | marker | LIST_item LIST_++sectionname++ (4, 6, 8, 10, ...) | Contains 1 when the current item is an even one. Contains 0 it it is uneven. When used for a section (wheter the section element is an even or uneven one) then the section name must be written in uppercase. |
ITEM_uneven ++SECTIONNAME++_uneven | marker | LIST_item LIST_++sectionname++ (4, 6, 8, 10, ...) | Contains 1 when the current item is an uneven one. Contains 0 it it is even. When used for a section (wheter the section element is an even or uneven one) then the section name must be written in uppercase. |
ITEM_index0 ##SECTIONNAME++_index0 | marker | LIST_item LIST_++sectionname++ (4, 6, 8, 10, ...) | Will contain the index of the element actually rendered counted starting from 0 for the first element. |
ITEM_index1 ##SECTIONNAME++_index1 | marker | LIST_item LIST_++sectionname++ (4, 6, 8, 10, ...) | Will contain the index of the element actually rendered counted starting from 1 for the first element. |
When you have configured some fields in the “Criteria” Tab of the FE plugin as “User selectable” then there will be a criteria selector available. The criteria selector subpart will not get replaced by an empty string then.
The PART_criteriaSelector main subpart has to contain one subpart “<!-- ###CriteriaItem### -->” which will get repeated multiple times – once for each criteria item created in the FE plugin and set to “User selectable”.
Each of those ###CriteriaItem### subparts may contain a marker “###TITLE###” which defines the title for the current criteria (the label of the field). Such a subpart also contains sub-subparts named “###CriteriaSelectorOption###”. Inside those subparts the markers “###LINK_HREF###”, “###SELECTED###” and “###LABEL###” will get replaced by a link pointin to a page with the criteria set to a specific value. The ###SELECTED### marker will contain “selected=”selected”” when this option is currently selected. ###LABEL### will contain the values to choose from.
In the default template the criteria selector is rendered as selector box – but it is easy to create a list of links instead. But this I leave to your cleverness.
The structure of the page-browser should be quite clear by the example template coming with the extension. It is of course possible to define other labels for each Page and for Next/Prev/First/Last via TS. See main-section “Configuration”
###PART_listing### is the most importan subpart of all because it contains the real listing of elements. The structure for singleView and listView is COMPLETELY THE SAME. The reason for this is that “singleView” is implemented very clever as listView which only shows one uid (have a look at class.tx_kbshop_pi1.php method “singleView :) )
The subpart ###PART_listing### may only contain one other subpart ###LIST_item### which gets repeated for each displayed record. This subpart ###LIST_items### may now contain markers for all fields used in a table and also their labels.
The markers which can get used in ###LIST_items### are the following. ++fieldname++ must get replaced by the “alias” set for each property. If you do not have set an alias you would have to enter the UID of the property instead for ++fieldname++ (you see now why it would have been a clever idea to enter aliases :)
###LABEL_++fieldname++### : Contains the name of the specified field as set in the property. When another language than the default is displayed of course also the alternate labels get displayed. This eases translation a lot as you don't have to have two different HTML templates if you don not have any extra text in your templates.
###FIELD_RAWVALUE_++fieldname++### : This marker contain the “raw” database value of the specified field.
###FIELD_VALUE_++fieldname++### : This marker contains the value after a “little bit” of processing. RTE fields are passed trough “lib.parseFunc_RTE” for example and database relations are resolved to the title of the records they point to (so you do not only see UID's).The contents for this marker can also get passed through stdWrap so mostly all transformations should be achievable. When stdWrap properties are defined for this value the “normal” transformations which the shop is performing (lib.parseFunc_RTE, db-rel labels) get not applied (meaing: if you define a stdWrap property for an RTE field you would have to pass it trough lib.parseFunc_RTE yourself using the .parseFunc property of stdWrap)
###COBJ_ITEM_++cobjname++### : Using this marker you can insert an arbitrary cObject “bound” to the values of each single record rendered (The fields of each record are contained in $cObj->data – you can access the fields of the rendered record with the .fields operator). This means that COBJ_ITEM markers get rendered once for each record getting displayed (and may by thus only occur in the ###LIST_item### subpart). This is different to COBJ_LISTING markers which may appear everywhere in the template and contain a cObject “bound” to the values of the FE-Plugin (The fields of the FE-Plugin tt_content record are contained in $cObj->data).
As already mentioned before you have the possibility to insert arbitrary cObjects into the template. This gives you a really great flexibility as you can insert mostly any thinkable T3 content this way. For example if you have database relations to tt_content elements in one of the tables you created you could let them get rendered in the FE-Plugin listing using a cObject.
There are two different kinds of cObjects for the template. ###COBJ_ITEM_++cobjname++### cObjects which get rendered while the values of each record are in the data array of the cObject. This means that in a COBJ_ITEM cObject you can access the fields you created using the “.field” operator of any stdWrap property. So an cObject which outputs the contents of an RTE field with all tags stripped would look like:
myTextField = TEXT
myTextField.field = rtefieldname
myTextField.stripHtml = 1
To find out where to insert this cObject in the TS configuration read on in the following section “Configuration”.
The other type of cObjects is the LISTING cObject: ###COBJ_LISTING_++cobjname++###. You can use this one at any place in your template. But the contents of such an cObject will be the same for the whole template – i.e: only rendered once. So if you place a COBJ_LISTING cObject into the ###LIST_item### subpart it will contain the same value each time.
When you define a cObject for a field in a section/container or in an overlay the marker of the cObject will be:
###COBJ_SECTION-OR-OVERLAYNAME_++cobjname++###
