TYPO3.Neos

There is a Draft in the wiki, I think from Nils:
http://forge.typo3.org/projects/typo3v5-core/wiki/DRAFT_JavaScript_CGL

Nils and I will do that.

Draft CGL looks good, a few comments:

- The @private annotation is used in the example class, but should be stated clearly in the CGL
- I think we agreed to use _methodName for private methods, this should also be added

Sebastian Kurfuerst wrote:

added a file with the current JS CGL version

wow looks good so far,

for array/ object code formating we can use
http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml#Code_formatting
as discussion base

TODO: find out how to make cross-references

{@link #methodOne This is a example link to method one}

how to nicely format multiline-text inside doc comments

to have a nice multiline output in the rendert api you have to format the code with <br />, <pre> ..

 * <br/>
 * Description of the class. Make it as long as needed,
 * feel free to explain how to use it.
 * This is a sample class <br/>
 * The file encoding should be utf-8 <br/>
 * UTF-8 Check: öäüß <br/>
 * {@link #methodOne This is a example link to method one} <br/>

a single var statement

i also prefer version 1

7 ExtJS specific things

extendig a store example:

F3.TYPO3.Content.DummyStore = Ext.extend(Ext.data.Store, {

    constructor: function(cfg) {
        cfg = cfg || {};
        var config = Ext.apply(
            {
                autoLoad: true
            },
            cfg
        );

        F3.TYPO3.Content.DummyStore.superclass.constructor.call(
            this,
            config
        );
    }
});
Ext.reg('F3.TYPO3.Content.DummyStore', F3.TYPO3.Content.DummyStore);

I had a look and didn't find something to add right now. Looks already quite good. I would have something like an Appendix and put the JSlint explanation there as it has nothing to do with code style but more with testing the code style...
I will think about chapter 7 (ExtJS) I think there is more to that.

Hey,

I was thinking about @return {void} -- should we require this? I think it adds not really any value, so why add that to methods and clutter the code with it?

Greets,
Sebastian

Sebastian Kurfuerst wrote:

I was thinking about @return {void} -- should we require this? I think it adds not really any value, so why add that to methods and clutter the code with it?

For the same reason we use it in the PHP code: if it's there you can be sure it has not simply been forgotten. It tells about the intention.

It would make sense for me to have return {void} documented since it gives additional information in the method's description particularly if the method becomes a bit longer... Also, I can imagine this may be useful when reading JSDoc.

ok, I updated the CGLs, now stating that @return {void} is required if there is no return value.

The tool https://github.com/kassens/javascript-formatter looks quite promising -- It is not fully done yet and I am not fully sure if it covers all cases -- but to me it makes perfect sense to do it this way :)