-
1. Re: Coding standards and process queries
Jesper,
I've created a new Jira for code formatting as discussed elsewhere:
https://jira.jboss.org/jira/browse/JBPROFILER-61
I've submitted one patch that reformats all the template .xhtml files. In http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193176 you provided a link to the source of ClassUtil.java as a reference for code standards but that covers Java only of course.
Can you eyeball the way I've formatted the XHTML in the patch I uploaded and let me know if there's anything I should change?
Cheers,
Rob Hills
Waikiki, Western Australia -
2. Re: Coding standards and process queries
Looks good.
One thing though - you don't have to indent attributes for an element with 2 spaces -- you can make them line up with the attributes from the previous line like<html xmlns="http://www.w3.org/1999/xhtml" xmlns:ui="http://java.sun.com/jsf/facelets" xmlns:h="http://java.sun.com/jsf/html" xmlns:f="http://java.sun.com/jsf/core" xmlns:a4j="http://richfaces.org/a4j" xmlns:rich="http://richfaces.org/rich">
makes the tag more readable IMHO.
HTH -
3. Re: Coding standards and process queries
"jesper.pedersen" wrote:
One thing though - you don't have to indent attributes for an element with 2 spaces -- you can make them line up with the attributes from the previous line like"jesper.pedersen" wrote:
makes the tag more readable IMHO.
I agree.
To further clarify the details, if a tag is too long for a line, do you then put each attribute on a separate line like the example you posted, or just break it into lines with variable numbers of attributes according to what fits on each line, indenting as you suggested in your previous post? The latter approach takes up less vertical space on the page, but the former is probably more readable IMHO. -
4. Re: Coding standards and process queries
I would also say the former -- cut the line if it is over 100 chars.
-
5. Re: Coding standards and process queries
OK, I've revised the template xhtml files accordingly and submitted another patch (using the same filename). Could you delete the first one, it seems I can't do that.
Note, some tags contain a long "style" attribute and I've not bothered reformatting those as I assume the style settings will need to be moved to the style.css file anyway.
Which reminds me, I should do a jira for that task as well, assuming you agree. -
6. Re: Coding standards and process queries
Hi Jesper,
I've just uploaded a second version of the second patch. It turns out you'd modified one of the xhtml files in the interim, so I've reverted that file to your version and reformatted it again - I tried a merge, but there were too many changes and too great a risk of losing one of your changes.
So now there are two versions of each patch. Please delete the version of each with the earliest timestamp.
It's a shame that jira doesn't allow the uploader of a file to delete/change it. -
7. Re: Coding standards and process queries
Applied, thanks !
Yes, all styles used in the web front-end should go in a central CSS file and just be referenced through styleClass.
Likewise with all message string - they should be put into the resource bundle (meesages.properties).
There are explicit widths (500px) defined on certain panels -- these needs to go away and be replaced by x% instead. The width of UI should be defined in a central place (template/template.xhtml).
And like stated previously - all HTML tags that can be replaced by JSF tags should be converted.
Valid XHTML and CSS should be a goal of the UI. -
8. Re: Coding standards and process queries
Hi Jesper,
"jesper.pedersen" wrote:
Yes, all styles used in the web front-end should go in a central CSS file and just be referenced through styleClass.
Likewise with all message string - they should be put into the resource bundle (meesages.properties).
There are explicit widths (500px) defined on certain panels -- these needs to go away and be replaced by x% instead. The width of UI should be defined in a central place (template/template.xhtml).
And like stated previously - all HTML tags that can be replaced by JSF tags should be converted.
Valid XHTML and CSS should be a goal of the UI.
OK, I've got my OCD jollies with reformatting the xhtml, so I'll jira and then sort out some of the other issues you've mentioned above. I'll look at the formatting of the java code in another day or so. -
9. Re: Coding standards and process queries
Hi Jesper,
Not sure what happened with the application of the last patch (jira-JBPROFILER-61-03.diff). I just went to update my source from the repository and the new version of loadthreadtree.xhtml showed chunks of conflicting code. When I had a look at the differences, the new version from the repository has most of my formatting changes, but also contains lots of tabs. Any idea how they got there? I took another look at the patch file and couldn't see any tabs being included in updated lines. -
-
11. Re: Coding standards and process queries
OK, that worked. There was still some trailing whitespace that caused a conflict, but that was easy enough to spot.
-
12. Re: Coding standards and process queries
I have some more formatting changes that I've just found and fixed (css file and template xhtmls). Do I reopen the same jira (https://jira.jboss.org/jira/browse/JBPROFILER-61) and upload the new patch there or do you want me to open a new jira?
-
13. Re: Coding standards and process queries
Applied patch #4, thanks !
I'll leave it open for now until all files have been checked. -
14. Re: Coding standards and process queries
I think that's a good plan.
BTW, not sure if you've noticed, but suddenly the Web app is working! I got quite a surprise when I fired it up on the train this morning (Western Australian time) after last night's changes and the pages suddenly started displaying snapshots and profiling details etc and generally looking like they should.
I'd expected to take much more effort to get to this point, but it seems that the major problems with the web app were a few broken links and some javascript typos :-D
I'll keep pushing on with tidying up. I'll work on getting rid of the inline styles next. It'd be good to have head.xhtml back so I can fix its inline styles first.