[Engine-devel] UI plugins - next steps
Hi guys, here's my list of tasks that didn't make it into UI plugins yet. These tasks should be revisited and implemented in future patches. The list isn't sorted in any way, so feel free to comment or highlight specific tasks to raise their priority, or add your own tasks/ideas. 1. Pass proper (restapi-definition) entities to UI plugins, instead of simple "{entityId:<guidAsString>}" objects - using restapi-types mappers to map backend business entities to restapi-definition entities (Java POJOs generated from api.xsd via JAXB) - exporting restapi-definition entities for use with JavaScript (UI plugins), e.g. using gwt-exporter [1] (alternatively, we could use GWT deferred binding and do this ourselves) 2. showDialog API function should integrate with WebAdmin dialog infrastructure - shouldn't be too hard, need to create custom dialog PresenterWidget/View and bind it as non-singleton (just like other popups in oVirt GUI) 3. Extend existing WebAdmin dialogs - prototype Doron's proposal to extend Edit Cluster Policy dialog with custom options that would be passed to backend 4. Introduce form-based tabs - custom tab that would display key/value pairs organized in columns, just like in standard "General" sub tabs 5. Introduce table-based tabs - custom tab that would display grid (table) just like in standard main tabs, with API to add columns, set data, etc. 6. Improve api.addMainTabActionButton to allow different button vs. context menu item representations (only button, only menu item, both) 7. Add api.currentUserName and api.currentUserId API functions (these would return same data as with UserLogin event parameters) 8. Minor things: consider renaming UiInit to PluginInit (one-time plugin initialization, called only once, can do non-UI init stuff there as well), consider renaming api.ready to api.initialize (plugin indicates that infrastructure can proceed with initializing itself) Regards, Vojtech [1] http://code.google.com/p/gwt-exporter/wiki/GettingStarted
Nice work! See some comments inline. ----- Original Message -----
From: "Vojtech Szocs" <vszocs@redhat.com> To: "engine-devel" <engine-devel@ovirt.org> Sent: Wednesday, December 12, 2012 2:57:11 PM Subject: [Engine-devel] UI plugins - next steps
Hi guys,
here's my list of tasks that didn't make it into UI plugins yet. These tasks should be revisited and implemented in future patches. The list isn't sorted in any way, so feel free to comment or highlight specific tasks to raise their priority, or add your own tasks/ideas.
1. Pass proper (restapi-definition) entities to UI plugins, instead of simple "{entityId:<guidAsString>}" objects - using restapi-types mappers to map backend business entities to restapi-definition entities (Java POJOs generated from api.xsd via JAXB) - exporting restapi-definition entities for use with JavaScript (UI plugins), e.g. using gwt-exporter [1] (alternatively, we could use GWT deferred binding and do this ourselves)
2. showDialog API function should integrate with WebAdmin dialog infrastructure - shouldn't be too hard, need to create custom dialog PresenterWidget/View and bind it as non-singleton (just like other popups in oVirt GUI)
3. Extend existing WebAdmin dialogs - prototype Doron's proposal to extend Edit Cluster Policy dialog with custom options that would be passed to backend
4. Introduce form-based tabs - custom tab that would display key/value pairs organized in columns, just like in standard "General" sub tabs
5. Introduce table-based tabs - custom tab that would display grid (table) just like in standard main tabs, with API to add columns, set data, etc.
6. Improve api.addMainTabActionButton to allow different button vs. context menu item representations (only button, only menu item, both)
7. Add api.currentUserName and api.currentUserId API functions (these would return same data as with UserLogin event parameters)
Pushing this now. http://gerrit.ovirt.org/#/c/9998/
8. Minor things: consider renaming UiInit to PluginInit (one-time plugin initialization, called only once, can do non-UI init stuff there as well), consider renaming api.ready to api.initialize (plugin indicates that infrastructure can proceed with initializing itself)
I think we should also consider adding an option to add a button in a more general scope, for things that aren't entity-specific, but system-specific. Maybe next to the "configure" button, in the upper right corner of the screen?
Regards, Vojtech
[1] http://code.google.com/p/gwt-exporter/wiki/GettingStarted _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Hi Oved,
Pushing this now. http://gerrit.ovirt.org/#/c/9998/
Thanks!
I think we should also consider adding an option to add a button in a more general scope, for things that aren't entity-specific, but system-specific. Maybe next to the "configure" button, in the upper right corner of the screen?
I agree, this could be useful as well. Shouldn't be too hard to implement, it's just about adding dynamic links to HeaderPresenterWidget/HeaderView in WebAdmin. Vojtech ----- Original Message ----- From: "Oved Ourfalli" <ovedo@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Wednesday, December 12, 2012 2:34:25 PM Subject: Re: [Engine-devel] UI plugins - next steps Nice work! See some comments inline. ----- Original Message -----
From: "Vojtech Szocs" <vszocs@redhat.com> To: "engine-devel" <engine-devel@ovirt.org> Sent: Wednesday, December 12, 2012 2:57:11 PM Subject: [Engine-devel] UI plugins - next steps
Hi guys,
here's my list of tasks that didn't make it into UI plugins yet. These tasks should be revisited and implemented in future patches. The list isn't sorted in any way, so feel free to comment or highlight specific tasks to raise their priority, or add your own tasks/ideas.
1. Pass proper (restapi-definition) entities to UI plugins, instead of simple "{entityId:<guidAsString>}" objects - using restapi-types mappers to map backend business entities to restapi-definition entities (Java POJOs generated from api.xsd via JAXB) - exporting restapi-definition entities for use with JavaScript (UI plugins), e.g. using gwt-exporter [1] (alternatively, we could use GWT deferred binding and do this ourselves)
2. showDialog API function should integrate with WebAdmin dialog infrastructure - shouldn't be too hard, need to create custom dialog PresenterWidget/View and bind it as non-singleton (just like other popups in oVirt GUI)
3. Extend existing WebAdmin dialogs - prototype Doron's proposal to extend Edit Cluster Policy dialog with custom options that would be passed to backend
4. Introduce form-based tabs - custom tab that would display key/value pairs organized in columns, just like in standard "General" sub tabs
5. Introduce table-based tabs - custom tab that would display grid (table) just like in standard main tabs, with API to add columns, set data, etc.
6. Improve api.addMainTabActionButton to allow different button vs. context menu item representations (only button, only menu item, both)
7. Add api.currentUserName and api.currentUserId API functions (these would return same data as with UserLogin event parameters)
Pushing this now. http://gerrit.ovirt.org/#/c/9998/
8. Minor things: consider renaming UiInit to PluginInit (one-time plugin initialization, called only once, can do non-UI init stuff there as well), consider renaming api.ready to api.initialize (plugin indicates that infrastructure can proceed with initializing itself)
I think we should also consider adding an option to add a button in a more general scope, for things that aren't entity-specific, but system-specific. Maybe next to the "configure" button, in the upper right corner of the screen?
Regards, Vojtech
[1] http://code.google.com/p/gwt-exporter/wiki/GettingStarted _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 12/12/2012 02:57 PM, Vojtech Szocs wrote:
1. Pass proper (restapi-definition) entities to UI plugins, instead of simple "{entityId:<guidAsString>}" objects - using restapi-types mappers to map backend business entities to restapi-definition entities (Java POJOs generated from api.xsd via JAXB) - exporting restapi-definition entities for use with JavaScript (UI plugins), e.g. using gwt-exporter [1] (alternatively, we could use GWT deferred binding and do this ourselves)
I think its time we revisit the implications/scope of moving the UI to work on top of the REST API or just the REST entities. until then, i think just adding specific fields that make sense/are asked for for these entities should be good enough. if we see the "moving UI on top of REST API" is still too far, then doing the type mapping for just the plugins would make sense.
Hi Itamar,
I think its time we revisit the implications/scope of moving the UI to work on top of the REST API or just the REST entities. until then, i think just adding specific fields that make sense/are asked for for these entities should be good enough.
Sounds reasonable, given that we want to move UI on top of REST API anyway.
if we see the "moving UI on top of REST API" is still too far, then doing the type mapping for just the plugins would make sense.
Maybe the "moving UI on top of REST API" process could be split into two phases: 1) patching UiCommon code to work with generated REST API types, instead of internal business entities patching Frontend RPC bridge (still using Generic API) to map internal business entities to REST API types 2) patching Frontend RPC bridge to map action/query invocation to REST API HTTP requests patching Frontend RPC bridge to map REST API HTTP responses back to REST API types Doing both 1) and 2) in one sweep might be risky.. Vojtech ----- Original Message ----- From: "Itamar Heim" <iheim@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Thursday, December 13, 2012 12:39:38 AM Subject: Re: [Engine-devel] UI plugins - next steps On 12/12/2012 02:57 PM, Vojtech Szocs wrote:
1. Pass proper (restapi-definition) entities to UI plugins, instead of simple "{entityId:<guidAsString>}" objects - using restapi-types mappers to map backend business entities to restapi-definition entities (Java POJOs generated from api.xsd via JAXB) - exporting restapi-definition entities for use with JavaScript (UI plugins), e.g. using gwt-exporter [1] (alternatively, we could use GWT deferred binding and do this ourselves)
I think its time we revisit the implications/scope of moving the UI to work on top of the REST API or just the REST entities. until then, i think just adding specific fields that make sense/are asked for for these entities should be good enough. if we see the "moving UI on top of REST API" is still too far, then doing the type mapping for just the plugins would make sense.
On 12/13/2012 05:37 PM, Vojtech Szocs wrote:
Hi Itamar,
I think its time we revisit the implications/scope of moving the UI to work on top of the REST API or just the REST entities. until then, i think just adding specific fields that make sense/are asked for for these entities should be good enough.
Sounds reasonable, given that we want to move UI on top of REST API anyway.
if we see the "moving UI on top of REST API" is still too far, then doing the type mapping for just the plugins would make sense.
Maybe the "moving UI on top of REST API" process could be split into two phases:
1) patching UiCommon code to work with generated REST API types, instead of internal business entities patching Frontend RPC bridge (still using Generic API) to map internal business entities to REST API types
2) patching Frontend RPC bridge to map action/query invocation to REST API HTTP requests patching Frontend RPC bridge to map REST API HTTP responses back to REST API types
Doing both 1) and 2) in one sweep might be risky..
agree, and this would be the general idea. though once you start changing entities in the uicommon, it's kind of infecting. i suggest to start with a simple one (say, bookmark, then config, then tag, etc.). you will then find some queries don't return business entities though, rather more complex types. so you could also start by mapping all the quries not returning a simple list of entities.
Vojtech
----- Original Message ----- From: "Itamar Heim" <iheim@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Thursday, December 13, 2012 12:39:38 AM Subject: Re: [Engine-devel] UI plugins - next steps
On 12/12/2012 02:57 PM, Vojtech Szocs wrote:
1. Pass proper (restapi-definition) entities to UI plugins, instead of simple "{entityId:<guidAsString>}" objects - using restapi-types mappers to map backend business entities to restapi-definition entities (Java POJOs generated from api.xsd via JAXB) - exporting restapi-definition entities for use with JavaScript (UI plugins), e.g. using gwt-exporter [1] (alternatively, we could use GWT deferred binding and do this ourselves)
I think its time we revisit the implications/scope of moving the UI to work on top of the REST API or just the REST entities. until then, i think just adding specific fields that make sense/are asked for for these entities should be good enough. if we see the "moving UI on top of REST API" is still too far, then doing the type mapping for just the plugins would make sense.
participants (3)
-
Itamar Heim -
Oved Ourfalli -
Vojtech Szocs