Bugzilla – Full Text Bug Listing
| Summary: | [RBD]Content assist need to reflect system predefined type automatically | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Jing Qian <jqian> |
| Component: | EDT | Assignee: | Xiao Bin Chen <xiaobinc> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | chenzhh, mheitz, pharmon, songfan, svihovec, xiaobinc, zhuzhi |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | EGLAR | ||
|
Description
Jing Qian
while fixing just IHttp might be simple. I hope the fix can look at the bigger picture of how content assist is designed, and why it would not handle IHttp, is there any others like IHttp that should be fixed. Hi Jing, Currently, some of edt content assist code are from RBD. So that some feature not supported in RBD, also will not support by EDT, If we did not MAKE SOME CHANGE TO THE CODE. The way we handle those predefined type in the system package is to maintain a type list in EGLDataTypeUtility. IF we add a new type or something, we need to add this type into this class(Actually a interface). I agree with you that Content assist in EDT need automaticly reflect those changes to system package.But we need to discuss whether it should be done in The 0.7. To achieve This will need PAUL to do some work on SystemEnvironmentManager or somewhere else which content assist could get those system things and present them. Actually, Systemlibrary and AnnotationTypeManager was used to maintain those system package's library and annotation which are initialized as the EDT start up and build the workspace. Anyway this is a defect from the user's view whatever RBD support or not, I think we need to discuss on the way HOW we handle this defect. I think we could just maintain the Predefined list so far in edt 0.7 and refactor it in 1.0 I have retrieve the system package. I think those types in System package which are not annotation, system library or exception might need to be the PREDEFINED type to show in content assist when we define a variable. Below is my list: HttpRest HttpSoap IHttp Request Response Job IRest MultiStatus Paul and tony, I have added you two to join this discuss. The SystemEnvironment currently maintains 2 maps that holds all of the system parts that were read out of the archive file(s). The getter methods for these maps are currently private, but we could make them public. This would allow content assist the ability to scan through all the parts and create an "index" for the part types it was interested in. Alternatively, we could add an extension point to allow tooling (like Content Assist) the ablity to register a listener that would be notified whenever a "system part" is deserialized into the system environment. This would provide another way for CA to create an index. Ultimatly, the solution will be to create a real index for our system parts, the same way an index is created for EGLAR parts in RBD. Once the system parts are part of the "real part index", they can be treated just like any user defined parts, in regard to our tooling. I am fine with leaving things alone for 0.7 and hard coding whatever system parts makes sense. For 1.0, we should consider getting our system parts into the index (assumine we will have EGLAR support in 1.0), or at least having content assist create it's own index of the system parts. Should this defect be 'tagged' as RBD? From what I can tell, this is an issue with EDT that does not occur in RBD. (In reply to comment #5) > Should this defect be 'tagged' as RBD? From what I can tell, this is an issue > with EDT that does not occur in RBD. Hi brian: I tested RBD8012 like below: rest IRe //content assist here and I think IRest type should be listed, but it doesn't. And IRest exists in RBD8012. So that I think this problem also exists in RBD. since this is complex, and we have short time, I think we should defer this to future when we look at CA as a whole. - maybe this one can be turned into an enhancement, mark for future - Another suggestion is maybe you can open a defect to sync up the this hard coded list with the "system eglar" right before we ship 070 https://bugs.eclipse.org/bugs/show_bug.cgi?id=362022 was opened for syc, defer this to 1.0. This is now working Moving old fixed bugs from the RESOLVED state to CLOSED. |