Bug Parade Component Review

Joan Garcia Vila jgarciavila at uoc.edu
Wed Nov 25 15:18:46 UTC 2009


Hi michelle.

I wrote a first local implementation (without remote access).
I will place the old code for the "unconnected mode" and a new parameter to choose (connection-less mode or similar).
Also I'll try to apply your suggestions.

cheers,
joan.

--> Missatge original de Michelle (michelle.dsouza at utoronto.ca) per a Joan García Vila enviat el 24/11/2009 23:10:06

Hi Joan,<br/><br/>I've taken a quick look at the bug parade component. I need to spend a little more time with it before I can give you some more in depth feedback. Here are a few starting points that you could knock off quickly in the mean time. <br/><br/>1. I think you've left some testing code behind in the parade.html file such as the afterRender listener and the 'inlineRichTextEditSetup' whose contents should just be in 'demo.initInlineEdit'. <br/><br/>2. You don't need to use fluid.wrap to wrap your selector when creating a component. The call to 'fluid.initView' will find the container for you.<br/><br/>3. The 'go' function has a couple of problems. It is not in a namespace which in the javascript world means that it is in the global namespace. It is also being bound to the button in the html tag. It's better to add click handlers to a button in an init block instead of mixing javascript code in html. It seems to me in this case that the button would be something of interest to the component. I would add it to the selectors for the component and bind the click handler in the component creator function. <br/><br/>4. We generally try to create our components so that they 'work' to some degree when simply loaded from the file system. This helps to involve more people in the component development process - for example there is no reason to require a back end for someone who is working on look and feel for a page. It looks like you've got some demo data in the component so perhaps when loaded from the file system you can use demo data instead of doing an actual search.<br/><br/>5. Use jslint.com to check your javascript. I generally select 'good parts', 'assume a browser' and deselect 'one var per function'. We tried to create a list of things to select in the wiki but jsLint is continually evolving and improving so that list may be a little out of date. Some of the things that jsLint will tell you will be minor like whitespace issues. These are nice to follow just so that everything is consistent in the repository. Note that Crockford's convention (which we follow) is to use 4 spaces instead of tabs. You can configure eclipse to do that automatically. Other problems that jsLint will point out seem minor but can result in cross browser bugs. For example trailing commas in object literals will throw errors in IE. I recommend that you take a look at Crockford's 'Good Parts' book or watch his javascript videos because he points out lots of interesting and useful details about the language. <br/><br/>Hope this is useful,<br/><br/>Michelle<br/><br/><br/><br/><br/><br/>------------------------------------------------------<br/>Michelle D'Souza<br/>Software Developer, Fluid Project<br/>Adaptive Technology Resource Centre<br/>University of Toronto<br/><br/><br/><br/>


More information about the fluid-work mailing list