Community
Participate
Working Groups
Setup the runtime widget project, add wizard page to import these project when creating new EGL project. A few things to be considered are - Dojo widget projects and Dojo runtime in two different projects are bringing confusion. Needs to be simplified - How can runtime widget project be shared between RBD & EDT
I saw the following proposed project names on the EDT RUI wiki (http://wiki.eclipse.org/EDT:IDE_RUI): org.eclipse.edt.rui.dojo.widgets.local_2.0.0 org.eclipse.edt.rui.dojo.widgets.aol_2.0.0 org.eclipse.edt.rui.dojo.widgets.google_2.0.0 I think we should take this opportunity to simplify - both the names and the number of options we give developers. I propose: org.eclipse.edt.rui.dojo_2.0.0 org.eclipse.edt.rui.dojo.remote_2.0.0 I have major doubts that anybody uses (or would use) the AOL library. I have no problem dropping this all together - will reduce dev/test time and have no real impact, other than making stuff simpler. I also don't think we need to carry over the same RBD verion levels - keeping the RBD version numbers will appear odd to any new developer of EDT. It seems the EDT EGL widgets project version should match the level of the technology (so, 0.7 for the September release and 1.0 for the first major release). I think the same for the Dojo widgets, although I sometimes wondered whether we should have somehow embedded the Dojo version level in the project name. This makes it more complicated when we need to make a change to a widget, but the Dojo level isn't changing .... Theresa - your thoughts?
We may need to think about mobile widget as a whole. When user create a new project using wizard, the widget library page will let them choose from org.eclipse.edt.rui._0.7.0 org.eclipse.edt.rui.dojo_0.7.0 org.eclipse.edt.rui.dojo.remote_0.7.0 org.eclipse.edt.rui.dojo.mobile_0.7.0 org.eclipse.edt.rui.dojo.mobile.remote_0.7.0 Maybe instead of listing all of them, we can group them into "local" and "remote" So far, my understanding is that Dojo mobile can be used standalone which means you can select dojo.mobile without selecting dojo. What will happen if user select both dojo & dojo mobile? Will that create some conflict since each of them has a "dojo runtime" inside.
I definitely see an issue if we allow the developer to select both "regular" Dojo and mobile Dojo libraries for their new project. We should try to minimize the number of Dojo JS modules that get included in mobile apps. Instead of offering both library options on the second page, what if we had separate project types? So, something like: * Rich UI Web * Rich UI Mobile Web This project selection would filter what libraries appear on the second page (I assume these libraries are contributed via extension point? If not they should be). I don't anticipate much difference in the actual structure/content of the projects, other than a flag/nature indicating the project is also a mobile web project. Knowing the user is developing a mobile web project may help us in other places as well (VE, etc). Just an idea --- I think we need to keep this option open and at least have a discussion on it .. Theresa - can you provide your thoughts ?
This idea is cool. I have another idea which makes little change to current implementation. My idea is to remove the second page, and add two checkbox like "include Mobile" and "use remote run time" in the first page which will determine the imported projects.This may be another option. (In reply to comment #3) > I definitely see an issue if we allow the developer to select both "regular" > Dojo and mobile Dojo libraries for their new project. We should try to minimize > the number of Dojo JS modules that get included in mobile apps. > > Instead of offering both library options on the second page, what if we had > separate project types? So, something like: > > * Rich UI Web > * Rich UI Mobile Web > > This project selection would filter what libraries appear on the second page (I > assume these libraries are contributed via extension point? If not they should > be). I don't anticipate much difference in the actual structure/content of the > projects, other than a flag/nature indicating the project is also a mobile web > project. > > Knowing the user is developing a mobile web project may help us in other places > as well (VE, etc). > > Just an idea --- I think we need to keep this option open and at least have a > discussion on it .. > > Theresa - can you provide your thoughts ?
I think we should work under the assumption that others (including "IBM") will want to make additional libraries (jQuery, etc) available to developers (this is key to getting other new developers interested in EDT/EGL). So, although I like the simplicity of your suggestion, it doesn't lend itself to this kind of extensibility. It's certainly worth to discussing, however. Maybe there's even a hybrid solution lurking in here somewhere .. (In reply to comment #4) > This idea is cool. > I have another idea which makes little change to current implementation. > My idea is to remove the second page, and add two checkbox like "include > Mobile" and "use remote run time" in the first page which will determine the > imported projects.This may be another option. > > (In reply to comment #3) > > I definitely see an issue if we allow the developer to select both "regular" > > Dojo and mobile Dojo libraries for their new project. We should try to minimize > > the number of Dojo JS modules that get included in mobile apps. > > > > Instead of offering both library options on the second page, what if we had > > separate project types? So, something like: > > > > * Rich UI Web > > * Rich UI Mobile Web > > > > This project selection would filter what libraries appear on the second page (I > > assume these libraries are contributed via extension point? If not they should > > be). I don't anticipate much difference in the actual structure/content of the > > projects, other than a flag/nature indicating the project is also a mobile web > > project. > > > > Knowing the user is developing a mobile web project may help us in other places > > as well (VE, etc). > > > > Just an idea --- I think we need to keep this option open and at least have a > > discussion on it .. > > > > Theresa - can you provide your thoughts ?
I like Tony's idea of making it simple checkboxes like [x] Include Dojo web support [ ] Include Dojo mobile support Think web should be checked by default and not mobile. Then we would import the needed projects based on these settings. These settings could be in a listbox so that it can be extended to other widget sets. For the naming of the projects, somehow we'll still need to relate the projects to the actual Dojo level. We can do this in the Help and project readme's...but we need to track this and make it clear to users. We don't want people to think we're using Dojo .7, which would be really old. ;-) For the remote project, I recommend we default to the Google runtime, but have the setting for AOL CDN but commented out. The file should have a clear section that outlines using remote CDNs, with a subsection for Google (including where to put the Google API key), and subsection for AOL. We may even want to cover how they would change the level since AOL is still at Dojo 1.6.0 while Google is at 1.6.1. This would keep us from having to ship another version of the project just so folks could point to a newer CDN level. We still need to decide whether we have separate runtimes for mobile and web and if the mobile one is mobile only or mobile + web. Depends on size and deployment impacts.
Like the set of generators and project templates, I think we should anticipate the list of widget library options growing over time. So, I agree with making this a list with checkboxes (like we have in RBD 8 today). I am a little concerned by us hiding the Dojo version (e.g. 1.6). I understand why we do it (so we can update/change our widgets independent of Dojo), but I wonder if we should come up with a way to surface the Dojo (or whatever widget library) level in the wizard panel and possibly in the project name. For example, in the widget library selection page of the new project wizard, we could use a table (with checkboxes) instead of a list and have columns that can provide more information about the widget libraries: |Library-------------------|Version-|Provider-----| |EGL Dojo (1.6.1) widgets |0.7 |Eclipse.org | |EGL Rich UI widgets |0.7 |Eclipse.org | Because widget libraries are contributed by extension points, a vendor could create a plug-in, implement the extension point, and then surface their own widget libraries in the wizard: |Library-------------------|Version-|Provider-----| |EGL Dojo (1.6.1) widgets |0.7 |Eclipse.org | |EGL Rich UI widgets |0.7 |Eclipse.org | |My super widget library |2.0 |Vendor ABC | (I could see us surfacing the Google Map widget library this way, for example) This does not address the scenario where multiple versions of a widget library are installed in the IDE at the same time (for example, EGL Dojo 0.7 and EGL Dojo 0.8). One idea is to make the Version column a drop-down. This way, the developer can choose a specific version of the library. I can also see a scenario where multiple versions of a widget library exist, but are tied to different levels of the underlying widget library. We may instead want to surface it this way: |Library----------------|Version----------|Provider-----| |EGL Dojo widgets |0.7 (Dojo 1.6.1) |Eclipse.org | |EGL Rich UI widgets |0.7 |Eclipse.org | The drop-down in the Version column for EGL Dojo widgets could be (in the future): 0.7 (Dojo 1.6.1) 0.8 (Dojo 1.6.1) 0.9 (Dojo 1.7.0) Although it's not necessarily critical for this to all be in place for 0.7, it's important that we get the widget library extension point correct now. Based on my quick look at it earlier, we appear close. Each should specify widget library ID (e.g. "org.eclipse.edt.rui.dojo"), a version (e.g. "0.7"), a version description (e.g. "0.7 (Dojo 1.6)"), and a provider (e.g. "Eclipse.org"). The library name and ID might have to be contributed via their own extension point - this way, the library name (e.g. "EGL Dojo widgets") is only specified in one place (not in every instance/version).
Thoughts on how to possibly handle the case of local/remote Dojo since it seems like a scenario that may happen with other widget libraries in the future ... |Library----------------------|Version----------|Provider-----| |EGL Dojo widgets (local) |0.7 (Dojo 1.6.1) |Eclipse.org | |EGL Dojo widgets (remote) |0.7 (Dojo 1.6.1) |Eclipse.org | |EGL Rich UI widgets |0.7 |Eclipse.org | Fwiw, I think this means local and remote are considered completely different libraries (i.e. different base widget library IDs). As alluded to by Theresa and others, since we are listing all the widget libraries in the wizard, we need a way to avoid conflicting library selections (e.g. EGL Dojo widgets and EGL Dojo mobile widgets). Conflicts should get surfaced as either a warning or error in the wizard page banner so the developer is made aware. One thought on how the "conflict detection" code could be implemented ... we could allow widget library extension points to specify a IWidgetLibrary (making this name up) class that would have a function to determine whether a library conflicts with this library. So, something like: public class EGLDojoWidgetsLibrary implements IWidgetLibrary public boolean conflicts(IWidgetLibrary library) { if (library.id.equals("org.eclipse.edt.dojo.mobile")) return true; else return false; end } } Can you tell I want to start coding again?! :)
Created attachment 201895 [details] Change WidgetLibraryProvider extension point, add more attributes; Change library selection page from list view to table view
code committed
(In reply to comment #8) > Thoughts on how to possibly handle the case of local/remote Dojo since it seems > like a scenario that may happen with other widget libraries in the future ... > > |Library----------------------|Version----------|Provider-----| > |EGL Dojo widgets (local) |0.7 (Dojo 1.6.1) |Eclipse.org | > |EGL Dojo widgets (remote) |0.7 (Dojo 1.6.1) |Eclipse.org | > |EGL Rich UI widgets |0.7 |Eclipse.org | > > Fwiw, I think this means local and remote are considered completely different > libraries (i.e. different base widget library IDs). > > As alluded to by Theresa and others, since we are listing all the widget > libraries in the wizard, we need a way to avoid conflicting library selections > (e.g. EGL Dojo widgets and EGL Dojo mobile widgets). Conflicts should get > surfaced as either a warning or error in the wizard page banner so the > developer is made aware. > > One thought on how the "conflict detection" code could be implemented ... we > could allow widget library extension points to specify a IWidgetLibrary (making > this name up) class that would have a function to determine whether a library > conflicts with this library. So, something like: > > public class EGLDojoWidgetsLibrary implements IWidgetLibrary > > public boolean conflicts(IWidgetLibrary library) { > if (library.id.equals("org.eclipse.edt.dojo.mobile")) > return true; > else > return false; > end > } > > } > > Can you tell I want to start coding again?! :) Hi Will, Can we differentiate the local/remote library by the "provider"? Take Dojo as an example, by making provider column to be a combo box, user can only select one provider for Dojo to avoid conflict. And it will also allow different providers to provide the same widget library. For example, we can have local(ibm), google, aol provider for Dojo now, and they are mutual exclusive.
From what I have seen, "provider" in Eclipse is typically used to indicate who produced/created whatever the object is (e.g. a plug-in, feature, etc). So, I think "provider" needs to remain "Eclipse.org" (i.e. "us") since we are providing this library. I think it still makes sense to treat local and remote as separate libraries, since they are not just different versions/levels of the same thing. (Of course, we don't want to allow the user to select both local and remote) Theresa - your thoughts?
(In reply to comment #12) > From what I have seen, "provider" in Eclipse is typically used to indicate who > produced/created whatever the object is (e.g. a plug-in, feature, etc). So, I > think "provider" needs to remain "Eclipse.org" (i.e. "us") since we are > providing this library. I think it still makes sense to treat local and remote > as separate libraries, since they are not just different versions/levels of the > same thing. (Of course, we don't want to allow the user to select both local > and remote) > > Theresa - your thoughts? I think local and remote is actually the same widget set so combine them as a list entry is more appropriate. I think we can add an attribute "source" to distinguish local/remote (even local/google/aol) and make it a combo box as "version" does.
Local vs. remote source is not necessarily a concept applicable to all widget libraries, so it might be awkward/confusing for libraries where it's not applicable. There is also a somewhat problematic scenario if we have a version of the widget library (e.g. 0.8) that only has a local option (since it's not hosted on Google yet, for example). In this scenario, the Source values would be variable based on the version selected. Would it make sense to include the source - when applicable - as part of the "Version", which is already being used to differentiate different flavors/versions of the same library?. For example: |Library----------------|Version----------|Provider-----| |EGL Dojo widgets |0.7 (Dojo 1.6.1) |Eclipse.org | |EGL Rich UI widgets |0.7 |Eclipse.org | Under the version column for Dojo would be: * 0.7 (Dojo 1.6.1) // the default, and is by default "local" * 0.7 (Dojo 1.6.1, remote) // this is the Google remote option This satisfies Theresa's assertion that "EGL Dojo widgets" local and remote are the same library (hence, shown on the same row).
We need some way to distinguish the versions of the Dojo toolkit and our widgets. Since we don't control when remote CDNs are updated, if we supported AOL it would be: * 0.7 (Dojo 1.6.1) // the default, and is by default "local" * 0.7 (Dojo 1.6.1, remote) // this is the Google remote option * 0.7 (Dojo 1.6.0, remote) // this is the AOL remote option At one point we had talked about combining Google and AOL options into a single remote runtime, with Google being the default and the AOL options commented out to help users understand how to use the AOL CDN (but not have another project). We'll have to see if people understand and use the remote/local if it's under the Version column as a dropdown, though agree it helps prevent user from bringing in both for one project. Would users ever want to bring in both remote and local for the same project, say just for testing?
The problem with "0.7 (Dojo 1.6.0 remote)" as AOL and "0.7 (Dojo 1.6.1 remote)" as Google is that we're stuck when 1.7 comes out and both Google and AOL support it. I still think we can live w/o AOL for 0.7. If we need to add it later, we can. I will open a separate enhancement request to add a longer description for each library. This will give us the ability to better describe what is in the library (i.e. which widgets) and even where it's hosted. In the case of "remote" it would be "Library files hosted on Google servers" (or whatever the wording should be).
Will, we specify the version of Dojo for Google in the remote project. So we would need to change the project and its version ie. 0.8 or 1.0, if the Dojo version changes. |Library----------------|Version----------|Provider-----| |EGL Dojo widgets |0.8 (Dojo 1.7) |Eclipse.org | |0.8 (Dojo 1.7 remote) //this is the Google option
Theresa and I discussed and agreed to go with: * 0.7 (Dojo 1.6.1) // the default, and is by default "local" * 0.7 (Dojo 1.6.1 remote) // this is the Google remote option The code to use AOL instead of Google should be commented out in the includeDojo.html - this will make it easier for developers that want to use AOL. We will use the description field (introduced by Bug 355588) to provide more details about the difference between the two versions - local and remote - of the Dojo library.
Created attachment 202114 [details] Finish the main functionality of this bug. Have included the detail pane.
Created attachment 202474 [details] Change resources project to rui plugin.Add the widget library. The widget library are manually added in this patch. In the future, the zip file will be built in automatically.
Theresa & Will probably want to update the detail text and icon of widget projects.
Verified
