Bugzilla – Full Text Bug Listing
| Summary: | [Client] Reorganize javascript-namespaces | ||
|---|---|---|---|
| Product: | [RT] RAP | Reporter: | Tim Buschtoens <tbuschto> |
| Component: | RWT | Assignee: | Project Inbox <rap-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | tbuschto |
| Version: | 1.4 | ||
| Target Milestone: | 2.0 RC1 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 320993, 330225 | ||
Since i tried to keep my own opinon from the description, here is it:
(Please keep in mind that this is all very long-term speculation.)
- I slightly prefer "rap" over "rwt" as a namespace, since its more inclusive and a bit faster to type.
- I'd love to see 3 or 4 realized. I don't yet see any downside to using an temporariy alias, we only would need to find a way to organize it in a single place.
- 6-8 aren't really helping. Either have an alias (4 or 5) or a short namespace (3), or don't solve this at all.
- Regarding new namesapces (9):
-- I'd like to see a Class or Namespace "dom" for all stuff that is touching dom/bom, i.e. rendering, eventhandling and getting info from the browser. None of that stuff should be rap-specific though, i.e. only static functions that don't access other namespaces.
-- Everything concerning client-server communication (protocol/http-request) should have its own NS.
-- One namespace for classes that "organize" the RAP-UI, like startup, managers, dnd-support, etc. (e.g. "internal", "managers", "system"?)
-- An argument could be made for a sperate NS for Classes that are only used from widgets as helpers/subwidgets/renderer ("util", ...?).
- Regarding existing namespaces (10):
I brought that up because thosse NS try to echo the SWT-namespaces - is that a necessity or even useful? I think all widgets should be in "widgets", period. The stuff from "theme" could fit into "internal" (as mentioned above), and "graphics" should either have all stuff related to SVG/VML, or be removed also.
The team seems to have agreed on "org.eclipse.rap.rwt" with rwt as an temporary alias. No specifics on technical details or sub-namespaces yet. I have not yet figured out exactly where this code would be placed, but i think the alias could be done in this fashion:
write( "org = { \"eclipse\" : { \"rap\" : { \"rwt\" : { } } } };" );
write( "( function(){ ");
write( "var rwt = org.eclipse.rap.rwt;" );
write( jsLibraries );
write( "} )(); ")
I'm trying to keep this up-to-date: On the last discussion we had the idea of using "org.eclipe.rap.rwt" aswell as "org.eclipe.rap" as with "rap" as the alias. The "rwt" namespace would be used for rwt-specific classes (like Widgets, the KeyEventUtil classes), while the "rap" classes contain generic javascript-framwork classes, mostly browser-abstraction (like EventHandler/EventHandlerUtil). It should be noted that we started using aliases similar as described in point 6 in the description. A shortcut like "rap" or "rwt" is therefore no longer needed i think. The main question is still whether we use "org.eclipse.rap", "org.eclipse.rwt", "org.eclipse.rap.rwt", etc or any combination. Getting rid of the qx namespace is covered in Bug 330225. I also think this is (in the interest of maintainability) something that should finally be done in RAP 2.0. With commit 148596c1b8d5a6f4a2527d468fb22e31c01393f7 the namespaces "rwt.widgets", (for all protocol-equivalent widgets) "rwt.widgets.base" (others), "rwt.protocol", "rwt.protocol.adapter" and "rwt.remote" have been created and populated. "org.eclipse.rwt.widgets" and "org.eclipse.swt.widgets" do not exist anymore. commit f2de74ac8d0a55e4e2298089e30960f4a8ad2d74 creates the namespaces "rwt.runtime", "rwt.theme" and "rwt.util". I also updated the ClientBuilder, since the Variant class moved from qx.core to rwt.util. Fixed with commit 3637c7c5972d3ea700770d9a0f3745bd5cb759a3! Yippee! We now have the follwoing client namespaces: rap rwt.animation rwt.client rwt.event rwt.graphics rwt.html rwt.qx rwt.remote rwt.remote.handler rwt.runtime rwt.theme rwt.util rwt.widgets rwt.widgets.base rwt.widgets.util I also removed some js files by merging them or making them obsolete, cleaned up some others, and made a few class/method renames (mostly adapter->handler and ServerObject->RemoteObject). |
I'll try to sum up the discussion up to now. For easy discussion, i'll give letters to problems and numbers to possible solutions. ---------------- Main namespace: We currently have three main namespaces on the client: - org.eclipse.swt - org.eclipse.rwt - qx Since we have neither tooling nor java-like "imports", this is very inconvenient. Everytime a Class is referenced either to create an instance or use a static method, the namespace has to be written out entirely, which means a) a lot of looking up to find the correct namespace, and b) a lot of unnecessary typing. As a long term goal we should at LEAST merge those three namespaces to somewhat solve a), and ideally also solve problem b). Following suggestions have been made for a unified namespace: 1. "org.eclipse.rwt" 2. "org.eclipse.rap" 3. "rap" (or "rwt") - Increases risk of nameclash with non RAP-js stuff. 4. "org.eclipse.rap" with "rap" as a an (temporary) alias. (Or "org.eclipse.rwt" and "rwt") - The alias could be delted after declaring our Classes. Number 3 and 4 would also solve the b)-problem. Alternative solutions for this problem would be: 5. Introduce an java-like "import" feature that creates temporary aliases. 6. Same as 5, but doing it manually to prevent confusion. (E.g.: var X = xXx; qx.Class.define(...); delete X; ) 7. Create lokal aliases at the begining of each function that needs it. (Not really a solution and already done in some cases, e.g. js-tests.) 8. Add the needed classes as a member of the class. (E.g.: { "members" : { "X" : xXx, foo = function() { var bar = new this.X; } }) (Just to be thorough, nobody really suggested it.) ------------------- "Sub"-Namespaces We currently have in "org.eclipse.swt" and "org.eclipse.rwt": - * (main, also contains a lots of classes itself) - *.widgets - *.browser - *.custom - *.graphics - *.theme There are two aspects to this: c) How to organize the "new" Classes moved/refactored from "qx.*" into this? d) Same as a): Many different namespaces for essentially the same kind of stuff makes it harder to remember them all. So we possibly could: 9. Create new "sub"-namespaces to organize the many new classes. 10. Perhaps reorganize the existing namespaces (the above ones and their respective mapping of classes). Related: Since we want to steer away from qooxdoo-concepts, namespacs could also be allowed to be used to directly store very often-used functions and constants. (A "namespace" in JS is really only an simple object/map that can store anything.)