| Summary: | [M2x IDE Integration] Outlet definition dialog doesn't implement Variables | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Automotive] Sphinx | Reporter: | pdu <pierre.dufay> | ||||
| Component: | Core | Assignee: | Ali AKAR <ali.akar82> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P3 | CC: | ali.akar82, dao.hoang.gate, idydieng, quoclan, r.sezestre, stephaneberle9 | ||||
| Version: | 0.7.0 | ||||||
| Target Milestone: | 0.7.0 | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
pdu
Created attachment 205891 [details]
Patch to implement Variables in outlets
This patch enables variable handling for outlets. It opens a StringVariableSelectionDialog
Also corrected a minor bug allowing empty path on outlets when creating them
Also added javadoc comments
Ali, could you please review proposed patch and commit it to Sphinx trunk if approved? Thanks! Thank you for this contribution. I appreciate the fact that on top of providing the new feature you have spent time on adding missing Javadoc. This is greatly appreciated! I did a quick code review, and here are some remarks from my side. Please honor them when incorporating the patch into the Sphinx codebase: * EditOutletDialog(Shell parent, ExtendedOutlet outlet, boolean edit, boolean editableName, OutletProvider outletProvider): Please adjust the comment, from "Default class constructor" to "Constructor". The default constructor is the constructor that has no parameters. * handleInsertVariable(): Why is it necessary to use the clipborad here? Wouldn't a simple statement like locationText.setText(variableName) be sufficient? * validateOutletLocation(): The comment "isValidPath method is really dumb (only checks that ':' is not present in path segments)" is not appropriate and should be removed. In addition to ':' isValidPath() also looks at misplaced '\' and '/' depending on underlying operating system - so it's not as dump as it might appear. * General remark: Please make sure that // comments always start with an upper case letter and Javadoc comments are always full sentences with an upper case letter at the beginning and a period at the end. (In reply to comment #3) > Thank you for this contribution. I appreciate the fact that on top of providing > the new feature you have spent time on adding missing Javadoc. This is greatly > appreciated! > > I did a quick code review, and here are some remarks from my side. Please honor > them when incorporating the patch into the Sphinx codebase: > > > > * EditOutletDialog(Shell parent, ExtendedOutlet outlet, boolean edit, boolean > editableName, OutletProvider outletProvider): > > Please adjust the comment, from "Default class constructor" to "Constructor". > The default constructor is the constructor that has no parameters. > > > > * handleInsertVariable(): > > Why is it necessary to use the clipborad here? Wouldn't a simple statement like > > locationText.setText(variableName) > > be sufficient? > > > > * validateOutletLocation(): > > The comment "isValidPath method is really dumb (only checks that ':' is not > present in path segments)" is not appropriate and should be removed. In > addition to ':' isValidPath() also looks at misplaced '\' and '/' depending on > underlying operating system - so it's not as dump as it might appear. > > > > * General remark: > > Please make sure that // comments always start with an upper case letter and > Javadoc comments are always full sentences with an upper case letter at the > beginning and a period at the end. Dear Stephan, I really appreciated your remarks! I will reply to your question about clipboard use in handleInsertVariable() : my understanding of variable use is to be able to mix 'hard-typed' text and one or several variables, for example having "some text ${var1} some other text ${var2}"; I didn't think about full text substitution, and in this case, your solution is obviously the best ! I Fixed the bug by applying the patch provided in Comment #1, I also took into account Stephan's remarks (Comment #3). Mass-closing Resolved tickets |