DEPRECATION WARNING

This documentation is not using the current rendering mechanism and is probably outdated. The extension maintainer should switch to the new system. Details on how to use the rendering mechanism can be found here.

Extension Development Evaluator

Author:Kasper Skårhøj
Created:2002-11-01T00:32:00
Changed by:Kasper Skårhøj
Changed:2004-06-24T11:46:01
Author:Kasper Skårhøj
Email:kasper@typo3.com
Info 3:
Info 4:

Extension Development Evaluator

Extension Key: extdeveval

Copyright 2003, Kasper Skårhøj, <kasper@typo3.com>

This document is published under the Open Content License

available from http://www.opencontent.org/opl.shtml

The content of this document is related to TYPO3

- a GNU/GPL CMS/Framework available from www.typo3.com

Table of Contents

Extension Development Evaluator 1

Introduction 1

What does it do? 1

Users manual 2

Introduction 2

Tool: "getLL() Converter" 4

Tool: PHP Script Documentation Help 9

Tool: Create/Update Extensions PHP API data 15

Tool: Display API from “ext_php_api.dat” file 17

Tool: Convert locallang.php files to XML format 19

Tool: temp_CACHED files confirmed removal 21

Tool: PHP source code tuning 22

Tool: Code highlighting 23

Tool: CSS analyzer 26

Tool: Calculator 28

Tool: Table Icon Listing 31

Adding new tools to this extension 33

Adding links to the Top frame list of links 33

To-Do list 34

Introduction

What does it do?

A backend development module that offers tools to help developers evaluate, clean, optimize and document their PHP scripts developed for TYPO3.

The idea is that this extension will provide a long list of smaller tools provided by various people over time.

Currently the extension is able to

  • getLL() converter Read out labels from the PHP-code and move it into a locallang data structure.Makes it much easier for extension developers to prepare extensions for localization.
  • PHP script documentation help: Insert comments above PHP-functions in class files.The comments will contain empty tags for parameters. Of course the descriptions must be provided by the programmer - but the trivial stuff is automated.This can also create a function/class index for the file. Very neat!
  • Create/Update Extensions PHP API data Can read all function/class comments from the extensions classes and compile the information into a file, “ext_php_api.dat”In addition it will perform a quality check on the comments found in the class files. This allows you to check if every function and class is sufficiently commented.
  • Display API from “ext_php_api.dat” file This will render the content of the “ext_php_api.dat” file of an extension into HTML.
  • Convert locallang.php files to XML format Will help you to convert "old" "locallang*.php" files to the newer XML based format.
  • temp_CACHED files confirmed removal Helps to remove temp_CACHED_* files from typo3conf/ if there are more than one (typically generated when you have more than one filepath to the site)
  • PHP source code tuning Performs some tuning on PHP source code. Most significantly is the conversion of double-quotes to single- quotes.
  • Code highlighting Can syntax-highlight PHP, TypoScript and XML content
  • CSS analyzer Lets you analyze the CSS selector usage in an HTML source
  • Calculator Contains small conversion utilities, including: Conversion to/from UNIX time, "crypt" of UNIX passwords (for .htaccess authorization), MD5 hashing of string input, creation of colored diffs and SQL parsing test.
  • Table Icon Listing Lets you list all possible combinations of icons for a specific database table. Useful to evaluate skins substitution of icons.
  • Dump Template Tables Dumps either "static_template" (TypoScript Template Records table) or "sys_template" (Static Template records) to clear-text. Useful for comparison/diffs between versions of records. Rarely used.
  • phpinfo() Shows PHP info for the current server.

img-1

The extension adds a module in the Tools main module:

img-2

Further, you will see a developer-bar in the top of the backend with links to the most used APIs of TYPO3s core classes:

img-3

You can add your own links on a per-install basis via TYPO3_CONF_VARS - see chapter in the back of this document.

Users manual

Introduction

Some general facts about the extension:

  • The module is located in the Tools main module.
  • It is accessible for "admin"-users ONLY. And it should stay that way.
  • It can work only on extensions installed locally (that is in typo3conf/ext/ - but you can change this in the source of mod1/index.php, internal variable $localExtensionDir)
  • It should (probably) be installed on development installations only since it is a development tool

Tool: "getLL() Converter"

A tool which helps developers of extensions to (more) easily convert hardcoded labels to labels provided by the localization engine in TYPO3 (using the pi_getLL() functions).

img-4

Background

TYPO3 has an API for handling localization of labels in the system. This regards both frontend and backend.

The idea is that all labels must be available in the default language, English. But they can also be translated to other languages (by interface on typo3.org). If a user selects another language he will see the labels in that language - if they are available, otherwise the default, English label is shown.

The localization is managed by inserting a function call like $this->pi_getLL() instead of the real text label in the programming code. The function takes a parameter which will return the right label value as it is stored in a so called "locallang" file in the system.

The problem is that when extensions are developed its very tiring to insert these function calls instead of the text label directly. So this tool tries to make it very easy to substitute the hard coded text labels that programmers might have inserted from the beginning.

This is the steps you take to use it:

1: Insert empty $this->pi_getLL() function calls

In your whole extension class file you insert function calls with a blank first-parameter and the second parameter set to the text label. You must use single-quotes for the two parameters in the function call.

Example:

Here we have a hard coded label in the extension PHP code:

img-5

This is substituted with this:

img-6

TIP: Tracking labels

If you want to track where labels might be in your script you can set these two internal variables in the class (extensions of tslib_pibase only):

img-7

The idea is that

All labels provided by a function call to $this->pi_getLL() will be prefixed with "##"

All labels from $this->pi_getLL() which was NOT found in a locallang file, but just passed through from the second parameter (the alternative label) will be prefixed "¤¤"

When you look at your extension output you can quickly spot which labels were not changed:

img-8

Here the label "Expanded threads view" is not prefixed with anything! This indicates that this label is not provided by the localization framework. So we look it up in the class file and insert it by the function call to $this->pi_getLL() (see above). After having done that it now looks like:

img-9

Having both the ## and ¤¤ prefix means that the label is passed through the localization system but it had no value in the locallang file (the other labels you see have that since the "¤¤" prefix is not seen for them).

2: Run the tool on the script

With the selector boxes available for this tool you select your extension and the script file within the extension. When that is done you will see content like this:

img-10

This is the source code of the script where all instances of the blank $this->pi_getLL() function calls you inserted is now substituted with a corresponding function call that returns the label based on a key string (first parameter) instead of the alternative pass-through value (the hard coded label you set as second parameter).

Since they are shown in red color you can easily check that all substitutions are as you would like them to be.

If everything is find you go to the bottom of the page and you can press a button for saving these changes.

Notice: Large unaffected sections in the script listing are shortened down by this string: [...]

3: Modify the locallang file

All the hard coded labels which were inserted in your script as the second parameter to the pi_getLL() function calls are now organized in an array structure which is shown in the bottom of the page:

img-11

After saving (or before! if you want to be safe!) you copy/paste this content into the "locallang.php" scripts "default" section (must be the locallang file which belongs to the plugin/module):

img-12

Here you can see the new values pasted in after some old values already there.

Notice the key "main_saved" has the value "Saved." which was the original, hard coded value from the example above.

4: Checking it

If all went well you should no longer see labels prefixed "##¤¤" but only "##" - since the labels are now found in the locallang file!

img-13

Note on auto detection of getLL() function type

This tool works on both plugin-classes (for frontend) and backend module scripts (for backend).

The difference is that the frontend uses the function call "$this->pi_getLL" and the backend uses "$LANG->getLL". This is automatically detected. Thus the tool will first look for the string "$LANG->getLL" and if found assume the script to be for the backend. Then it will look for the string "$this->pi_getLL" and if found assume it to be a frontend script. If neither is found an error message is returned.

Notice that the function call "$LANG->getLL" actually does NOT support an alternative label as second parameter (that is a boolean flag). So while should still use the method above for having the tool substituting the functions you must be aware that the conversion of the functions must happen since this alternative label feature of the "$this->pi_getLL" is not supported in the backend. In case you don't do the substitution the function "$LANG->getLL('','Bla bla bla')" will just return a blank value.

Tool: PHP Script Documentation Help

This tool helps you to create documentation tags in JavaDoc style for your extensions.

JavaDoc style comments look like this in a PHP-script:

img-14

They are placed over each class/function and describes what it does, which parameters it has and what it returns. This information is very important for yourself later (when you have forgotten what you can remember now) and other people using your classes.

The scenario is that these comments are likely to be ignored when development is hot and flows from your fingers. Therefore this tool will make it easy to insert the framework for these comments - all the trivial stuff. But you will have to supply the descriptions of course.

The basics

First of all you will have to find the extension and PHP-file to work on. There should be a PHP-class (or functions) in the PHP file (all php and inc files are shown in selector box).

img-15

When you have selected this you will see an analysis of the PHP document. The color markup is explained below.

Basically all you have to do is to check if the changes are OK with you and if so, press the Save button. Thats all.

Notice: Large unaffected sections in the script listing are shortend down by this string: [...]

Scenario 1: A function had no comment at all

If a function is found and had no comment at all a fresh one is inserted. That is done by marking it in red so you can easily spot the new comment:

img-16

Notice that

  • A space for a function description is provided by the string "[Describe function]"
  • The parameter $filepath has been found in the function header and a line for that parameter is added.
  • A line for a return value is added (always)

The label "[type]" is explained in a second

Scenario 2: A function had a comment but is reformatted / modified

When this tool parses the PHP script existing comments are parsed and then re-formatted according to the way the script will normally do it. This means you existing comments should contain all the original information but might be re-formatted.

If that reformatting leads to a comment which is different from the existing (might even be due to white space characters) then it will be marked blue:

img-17

NOTICE: A re-formatted function may also contain new @param tags. For example if one @param tag exists but the function header has two parameters then a new, empty @param tag will be created for your convenience.

Scenario 3: A function had a comment and was not reformatted in any way.

If no change has been performed you will just see the function as plain text (comment will be in bold black):

img-18

The label [type]

When this tool add new JavaDoc "tags" - like @param and @return - then the default value for the variable type is set to "[type]". You must change this value of course so it reflects the data type of the input/output.

The values you can use is

  • integer
  • string
  • boolean
  • array
  • object
  • mixed
  • pointer
  • void (return value)

The "mixed" type is if the variable can be multiple types. Then you use the description to explain.

The "boolean" type should be used if the input value is just evaluate as "true" or "false" in PHP. This means that integers 0/1 or strings could be input as well as true/false indicators.

Use the type value "void" if a function returns nothing.

Tip: Searching for [type]

When you have added comment tags to your PHP-script the best way to find places where descriptions are needed is to search for the string "[type]". Obviously scripts which had no comments are easy to handle, but when you use this tool to add new @param tags to classes which already had comments en masse then its more practical to spot the 5-10 places you have to add descriptions by searching for the string, "[type]"

JavaDoc compatibility

Well, this tool is not a full-blown parser of the PHP-scripts so please help it a little on its way. In other words to have it correctly detect and insert JavaDoc comments please understand these basics and then follow the implicit guidelines:

Classes and functions

  • If a class or function has a comment above it then it should get detected without any problems.

  • If a class or function does not have a comment above, then one is inserted IF the first non-whitespace character found above the function is a ending brace - }Therefore: In some cases you may have to insert an empty JavaDoc comment and then it will get detected!

  • JavaScript functions: You will experience that JavaScript functions which are a part of the content inside functions may be seen as a PHP function! To avoid this, add “//” in the end of the lines defining JavaScript functions. Eg:

    function myJavaScriptFunction(var1, var2)  {       //
    ...
    
  • Make sure that curly brace, {, is the last char on the lines with function and class definitions - otherwise they are not registered!

  • All functions and classes should be defined on a single line, eg:

    class blablabla {
    

    or

    function blablabla() {
    

    Don't mix in characters before or after this on the same line - then they are not detected.

  • Internal variables in a class should a) all be places before the first functions and b) will NOT be detected one by one but included as text for the class name in the definition saved for the API display data. Thus they can be displayed in the API overview, but in a rather simple manner.

  • Make sure there is an empty line above a JavaDoc comment - otherwise the indentation will be a little funny... (Indentation of the comment is based on the indentation of the first line, which is "/**")

    So this is not right:

    class tx_extdeveval_module1 extends t3lib_SCbase {
            /**
             * Init function
    

    But this is (there is a blank line):

    class tx_extdeveval_module1 extends t3lib_SCbase {
    
            /**
             * Init function
    
  • Make sure to use 1 tab prefix for the first line of a comment (“/**”) and 1 tab + 1 space for the rest of the lines (“*” and “*/”)

Looks like this (one comment for the class, one for the function inside):

/**
 * Class for the PHP-doc functions.
 *
 */
class tx_extdeveval_phpdoc {
        var $fileInfo=array();
        var $includeContent=500;
        var $sectionTextCounter=0;

  /**
   * The main function in the class
   *
   * @param       string          The absolute path to an existing PHP file which .. analysed
   * @return      string          HTML content from the function
   */
        function analyseFile($filepath) {
                        // Getting the content from the phpfile.
                $content = t3lib_div::getUrl($filepath);

Section comments?

Sometimes it is very practical to divide your class into sections with various kinds of functions. To do so you can add an additional JavaDoc style comment like the one marked with red in the example below.

This comment has three attributes:

  • It is a helpful visual guide for you when scrolling down the document
  • It is NOT a part of the JavaDoc specs - I made it up
  • It is detected by this tool and will also appear in the class/function index - which is nice!

In this example notice all the whitespace between the ending of a former function (in top) and the function "moderatorList()" in the bottom. This whitespace is optional but works great in addition to the red JavaDoc comment with the text "Functions assisting....". The idea is that this comment - here called a section comment - is a head line for the following 10-20 functions and the formatting should make it easy to find the section start when scrolling the script in an editor.

...
                return $content;
        }



















  /***********************************************
   *
   * Functions assisting the major display functions (above)
   *
   **********************************************/

  /**
   * Creates the HTML-output for the list of managers and supervisors as shown ...
   * Will select managers and supervisors from the tt_content fields 'tx_mailli...
   *
   * @return      string          HTML-output
   */
        function moderatorList()        {
                $output='';
                $showUserUidPid=intval($this->conf['tx_newloginbox_pi3-showUidPid']);
...

Section comments will be detected as the second JavaDoc comment found above a function / class. Using the long spans of ****** is only a visual aid.

Read more about how section comments are used in the class/function index in a section further down on this page.

The script header

The script header should contain:

  • A license notice (red)
  • A script comment (with author tag and a short description of the content in general) (green)
  • Optional: a class/function index comment (purple)
  • Optional: Initiating PHP code (orange)
<?php
/***************************************************************
*  Copyright notice
*
*  (c) 2003 Kasper Skårhøj (kasper@typo3.com)
*  All rights reserved
*
*  This script is part of the TYPO3 project. The TYPO3 project is
*  free software; you can redistribute it and/or modify
*  it under the terms of the GNU General Public License as published by
*  the Free Software Foundation; either version 2 of the License, or
*  (at your option) any later version.
*
*  The GNU General Public License can be found at
*  http://www.gnu.org/copyleft/gpl.html.
*
*  This script is distributed in the hope that it will be useful,
*  but WITHOUT ANY WARRANTY; without even the implied warranty of
*  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
*  GNU General Public License for more details.
*
*  This copyright notice MUST APPEAR in all copies of the script!
***************************************************************/
/**
 * @author        Kasper Skårhøj <kasper@typo3.com>
 */
/**
 * [CLASS/FUNCTION INDEX of SCRIPT]
 */


require_once(PATH_tslib.'class.tslib_pibase.php');
require_once(PATH_t3lib.'class.t3lib_readmail.php');


/**
 * Class for the PHP-doc functions.
 *
 */
class tx_extdeveval_phpdoc {
        var $fileInfo=array();
        var $includeContent=500;
        var $sectionTextCounter=0;
Cool feature! Class/Function index

This tool has a very cool feature call a class/function index. It is enabled and then automatically created/maintained by simply inserting a comment like this in your script header (see above):

/**
 * [CLASS/FUNCTION INDEX of SCRIPT]
 */

That's all you need. Then next time you use this tool on the script you will find that an index over classes, functions and section comments in the file is created. That could look like this:

/**
 * [CLASS/FUNCTION INDEX of SCRIPT]
 *
 *  109: class tx_maillisttofaq_pi1 extends tslib_pibase
 *  157:     function main($content,$conf)
 *  204:     function listView($content,$conf)
 *  390:     function listFAQ_HOWTO()
 *  486:     function listArchive()
 *  615:     function managerStatus()
 *
 *              SECTION: Functions generating HTML output
 *  857:     function listThreads($res)
 *  879:     function pi_list_header()
 *  912:     function pi_list_row($c)
 *  997:     function pi_list_searchBox()
 * 1019:     function categoryBox()
....
 * 2583:     function getUserNameLink($fe_users_uid,$showUserUidPid=0,$prefix='')
 *
 *              SECTION: MAIL transfer functions:
 * 2621:     function transferMailsFromInBox($number=10)
 * 2656:     function storeMailInMLtable($row)
 * 2765:     function collectOrphans()
 * 2805:     function getPlainTextContentOut($cArr)
 * 2854:     function htmlToPlain($in)
 * 2871:     function searchForParent($items)
 *
 *              SECTION: MAIL FEED functions:
 * 2914:     function readMails($mconf)
 * 2973:     function feedMails($mconf)
 *
 *              SECTION: Experimental / Development functions
 * 3031:     function makeFeUserStat($fe_user_uid)
 *
 */

As you can see - a nice over view of the available functions in the class, referred to with their line number and with the section comments (first line) used as a head line!

A few details about parsing:

  • All stand-alone functions should be placed before any classes since all functions found after a certain class name will be registered as belonging to that class.
  • The class/function index comment is identified on the first line having the exact value, "[CLASS/FUNCTION INDEX of SCRIPT]" - so don't change that for fun.

Tool: Create/Update Extensions PHP API data

A tool which will read JavaDoc data out of PHP class scripts in the extension and store it in a "ext_php_api.dat" file for rendering by another tool in this extension, “Display API from ext_php_api.dat file”.

There is also an extension, "phpapife", which can display a unified API on a website based on a bunch of these data files.

Anyways, in the interface you will see this:

  • All PHP files in the extension is listed.
  • You can select which files will go into the ext_php_api.dat file of the extension
  • For all selected files you will see an evaluation of the quality of comments plus usage count for functions/classes looked at internally in the extension (useful to spot if there are functions not used anymore!)
  • If there is an ext_php_api.dat file in the extension already the module will show you a message (see below) that it has been detected.

img-19

In the bottom of the screen you will find these options:

img-20

Here you can do the remaining configurations of the ext_php_api.dat file you will write. This explains itself more or less.

Just notice one thing ; For extremely large extensions you might want to be careful with adding code abstract and usage count - this can take much much more than 30 seconds which is the default PHP timeout!

Quality of comments

The module has a brilliant analyzer of code documentation comments. It will check if all arguments has been commented and whether the comments has a reasonable length, whether the data type is correct etc.

An example of such error messages could be this:

img-21

If you take the function “renderAPIdata” as example it looks like this in the source:

/**
 * [Describe function...]
 *
 * @param    [type]        API data array
 * @param    string        blabla
 */
function renderAPIdata($apiDat,$phpFile)    {

        // Initialize:
    $content = '';

Obviously this function is not really commented, the first argument has no valid type, the second argument has a very short comment considered too short to be valid and there was no return tag!

All this is what makes the red warning above.

In all your scripts you should seek to get rid of all red and orange (less fatal) errors for comments - this will testify to a beautiful source code!

Tool: Display API from “ext_php_api.dat” file

This will simply look for a “ext_php_api.dat” file in the currently selected extension and if found, it will show the API data as HTML with a little index in top etc:

img-22

This feature is meant as a quick way to get API documentation - full- blown documentations should of course be done with PHPdoc or doxygen or some other external tool.

Saving API as HTML

A great feature of the instant-API here is if you click the little link “Open API in new window” - this will show the API in a separate HTML page with no external resources used (like stylesheets) - and thus perfect for saving right away and send by email or put out for download.

img-23

This is how it looks:

img-24

Tool: Convert locallang.php files to XML format

TYPO3 ver 3.7+ contains a new XML based format for storing localized versions of various labels. Traditionally this has been stored in PHP- files ("locallang-files") containing an array called $LOCAL_LANG in which all translations for a label was stored. The new XML format contains the same data including some meta information and additionally all labels are in the same charset (utf-8) rather than mixed charsets.

Applications that wish to convert existing locallang*.php files to the XML format can use this tool to do so. It will read the $LOCAL_LANG array, convert charsets and dump it as XML in the same filename but with ".xml" as ending.

img-25

Usage
  • Select the extension
  • Select the "locallang*.php" file from the filelist. Now you should see a few form fields below it.
  • Enter a description of the labels in the locallang file. This is a part of the meta information in the final XML file.
  • Select "Type"; You can select "Module labels" for backend modules, "Database" if the locallang file is for database table/field names and finally "CSH" if the labels are for Context Sensitive Help.
  • If you selected "CSH" you should also enter the (pseudo) table name for which the CSH is for. Please see more information about that in "Inside TYPO3".

After creating the XML file you should probably do stuff like:

  • If the original locallang file was included directly with "include()" you have to change this to using the API function "$LANG->includeLLFile()" instead, eg. "$LANG->includeLLFile('EXT:templavoila/mod1/locallang.php');". Then it will look for the XML file automatically and use that.
  • Remove the old "locallang*.php" file. If you use CVS please use the CVS commands to remove it from the repository (this will also delete it from your local machine).
  • Using CVS, you should also add the new xml file to the repository of course.

The XML based format is not translated online on TYPO3.org but rather with a backend module (see extensions "llxmltranslate")

XML format

The XML content of a conversion can look something like this example:

<T3locallang>
    <meta type="array">
        <description>Standard Module labels for Extension Development Evaluator</description>
        <type>module</type>
        <csh_table/>
        <fileId>EXT:extdeveval/mod1/locallang_mod.xml</fileId>
        <labelContext type="array">
            <languageKey index="mlang_tabs_tab"/>
            <languageKey index="mlang_labels_tabdescr"/>
        </labelContext>
    </meta>
    <data type="array">
        <languageKey index="default" type="array">
            <label index="mlang_tabs_tab">ExtDevEval</label>
            <label index="mlang_labels_tabdescr">The Extension Development Evaluator tool.</label>
        </languageKey>
        <languageKey index="dk" type="array">
            <label index="mlang_tabs_tab">ExtDevEval</label>
            <label index="mlang_labels_tabdescr">Evalueringsværktøj til udvikling af extensions.</label>
        </languageKey>
        <languageKey index="de" type="array">
            <label index="mlang_tabs_tab">ExtDevEval</label>
            <label index="mlang_labels_tabdescr">Das Extension-Entwicklung Evaluationstool.</label>
        </languageKey>
....

Tool: temp_CACHED files confirmed removal

Certain strange problems can be experienced if you de-/install an extensions and the "temp_CACHED" files found in typo3conf/ does not get removed. If your TYPO3 installation happens to exist in more than one absolute path on the server (eg. via symlinks on Unix) then you will have more than one set of "temp_CACHED" files (since this is based on the absolute path to the installation) but (a bug) in TYPO3 3.5.0 means that only the current set of files gets removed while all of them should be!

This tool helps you to analyze a) the ability of the TYPO3 installation to remove the cache-files and b) the ability to remove all of them if you need to.

img-26

This is the two current "temp_CACHED" files used for the current instance of this script. These are returned from the extension management class.

The two current cache-files (#1) are also seen here in the list of actual PHP files found in typo3conf/

These are additional cache-files which must have come from either an earlier position in the file system of the website or because it is currently duplicated in another position via symlinks. These are the files that are currently not removed when extensions are installed...

Click this button and ALL files with "temp_CACHED_*" will be removed (#2+#3)

Click this button and the current cache-files will be removed (#3)

Click this button to refresh without any action done.

Just ignore these - have no function with this function.

Tool: PHP source code tuning

This module is written by Rene Fritz and he will hopefully document it at some point...

Tool: Code highlighting

Here you can submit PHP, XML or TypoScript and it will be syntax highlighted for you.

Highlighting TypoScript code

In this example TypoScript is syntax highlighted:

img-27

You can even feed it with syntax errors and it will be shown:

img-28

Highlighting XML code

For XML highlighting you can also see how the parsed XML will look in a PHP array:

img-29

If you are having Syntax errors in the XML code you will also see this:

img-30

Highlighting PHP code

If you highlight PHP code you will also be able to see the line numbers:

img-31

From this screen it is very easy to copy/paste the highlighted code into eg. Open Office for TYPO3 documentation :-)

Tool: CSS analyzer

This tool allows you to analyze HTML source code for the hierarchy of CSS selectors. This is very useful whenever you need to do some CSS styling - whether for a TYPO3 skin, a frontend plugin in TYPO3 or any other website for that matter!

The tool looks like this when in use:

img-32

The various points are explained here:

Here you paste in the HTML source code you want to analyze

Here you can enter a prefix you want to remove. For instance if the list of selectors all start with “BODY DIV....” and you enter “BODY” in the field, then only “DIV...” will be shown.

Here you can enter which prefix is required for a selector to be listed. Lets say you have two selectors listed, “TABLE TR” and “DIV P”, then adding “TABLE” in this field means that only selectors starting with “TABLE” will be shown - and thus the “DIV P” selector is removed from the list.

This will transfer this selector to field #3

This will transfer this selector to field #2

In this field the result is shown in a mode which is easy to copy / paste into a stylesheet - which is where you then begin to add the style content for the selectors you have extracted from the HTML source.

Tool: Calculator

Contains various "calculation" tools.

Time

This tool enables you to convert Unix time (seconds since sometime in 1970) to a human readable date/time. You can convert both ways:

img-33

Crypt string

For ".htaccess passwords" this might come in handy for you:

img-34

MD5 hash of string

Sometimes you might want to create a hash of a string in order to compare two strings (see if they are alike which they are if the hashes are the same).

img-35

Diff of strings

This tool allows you to see the difference between two strings visually. Simply paste the two strings into the fields and select one of possible diff-types. The result is color coded so that removed content is red and added content is green:

img-36

Select "Classic diff" to see which lines went out and which went in:

img-37

If you prefer the unified diff you can also select that:

img-38

You can also see the text compared word-by-word:

img-39

SQL parsing

TYPO3 contains an SQL parser (class.t3lib_sqlparser.php) which defines the "TYPO3 SQL standard". This field lets you analyze a line of SQL and see if it could be parsed and what the internal structure of the parsing was like. This tool is related to Database Abstraction (DBAL).

img-40

Tool: Table Icon Listing

In TYPO3 3.6.0 the automatic generation of icons has been disabled by default - because this was one of the main problems of using PNG instead of GIF, but also a problem if the integration of alternative skins should be a reality.

This tool allows extension developers to test-drive ALL icons that can possibly be needed for a table in TYPO3 - and subsequently they can produce these icons.

Example with the “pages” table

If you take the pages table and analyze that, you will see that for all combinations of hidden, starttime and endtime, these are the icons shown:

img-41

Obviously you can add more combinations of settings and in fact not all will have an icon! For instance the Spacer page type as no pre- made icon for the combination of hidden and starttime:

img-42

Then the “__x” icon is just shown. But this is a matter of priority - otherwise we should have 700 pre-made icons which does not make sense. So the priority predicts that a hidden/starttime spacer icon is probably never needed and thus no icon is made - hence the “__x” icon is used instead (to show that at least the page is not normal ).

Custom tables evaluation

For custom tables the situation might very well look like this:

img-43

Here you can see the path of the default icon - which is never a problem really.

However when the icon is shown as Hidden there is no icon! This should produced as “icon_user_3dsplmxml_bfssubindustry__h.gif” in which case it would be found and used.

In any case it should be a priority to make the “__x” icon for ALL icons - this will be the default icon to display if none other can be shown - and will substitute the red-question-mark-on-white-icon shown to the left in the above screenshot.

See the details about icons in Inside TYPO3 documentation.

Adding new tools to this extension

If you want to add more features to this extension you can do that relatively easy.

  • Add a new menu item in "index.php"
  • Create an entry in the switch construct back in the modules "index.php" file
  • Create a class file with all the stuff you need to do the processing you need
  • Send it to Kasper (who maintains the extension)
  • Maintain it via CVS on sourceforge, project “typo3xdev”, CVS module “tx_extdeveval”

((generated))

Example:

Here the tool "PHP Script Documentation Help" is added to the menu selector box in upper right corner:

img-44

Then in the switch construct:

img-45

All this content is added as a part of your tool, but notice that the class "class.tx_extdeveval_phpdoc.php" is included and instantiated right after. This class must exist and should do the rest.

To-Do list

((generated))

Visions

This extension is created as a framework which is easy to add to (see chapter before this)

Personally I would like more features such as:

  • An analyzer which would try to spot where HTML in the PHPscripts might not be be XHTML compatible and highlight the places. That would be checking ending of <img>, <input>, <br> and <hr> tags, alt- attributes for images, lowercase tag and attribute names, non- shorthand attributes (eg. "nowrap", "checked", "selected").
  • A tool reading files with TypoScript structures in and reading any comment lines before properties and building an OpenOffice document with a property table - which can manually be copied to the real manual.
  • A tool which can help Extension Reviewers to analyze an extension for a number of function and sql usages which are normally important to check.In addition the module could be useful if it made automatic code highlighting.Maybe such a module could even provide the step by step analysis of the extension with input fields for comments and thus result in the review report being made?

img-46 Extension Development Evaluator - 34