We’ve been working with DHIS2 Apps for a while now, and found the general experience (as developers) pretty good with the d2 + React combo. Something I could not find info about is how the different kind of apps change, especially the DASHBOARD_WIDGET one - does that means that an app of this kind will be rendered as a box in the main view? If so, how to specify the part that should go there vs for example a full sized page after once clicked?
Any doc or example on this would be great.
As I’m there - thanks to the team there to provide a nice to use extension point in the form of webapps - much appreciated!
Martin
···
**Martin Van Aken - **Freelance Enthusiast Developer
the dashboard widgets/apps, listed under the Apps section in the
dashboard item selector, are rendered in the same way as before.
They are loaded in an iframe in a box added to the dashboard grid.
This is also to ensure existing apps can still work in the new Dashboards app.
As for distinguishing between a full screen and a "widget" app, there
isn't anything in place as far as I know.
One way is to use a responsive layout in your app, to ensure the
content fits and is usable in both full screen and the small widget
box.
I didn't work with widget apps, so hopefully someone in the community
who has done that can help.
Cheers,
···
On Thu, Apr 26, 2018 at 10:35 AM, Martin Van Aken <martin@joyouscoding.com> wrote:
Hi!
We've been working with DHIS2 Apps for a while now, and found the general
experience (as developers) pretty good with the d2 + React combo. Something
I could not find info about is how the different kind of apps change,
especially the DASHBOARD_WIDGET one - does that means that an app of this
kind will be rendered as a box in the main view? If so, how to specify the
part that should go there vs for example a full sized page after once
clicked?
Any doc or example on this would be great.
As I'm there - thanks to the team there to provide a nice to use extension
point in the form of webapps - much appreciated!
Martin
--
Martin Van Aken - Freelance Enthusiast Developer
Not exactly, the content in the iframe is usable from within the box
in the dashboard.
There isn't a way of going full screen at the moment, but it can be
easily added.
···
On Thu, Apr 26, 2018 at 5:21 PM, Martin Van Aken <martin@joyouscoding.com> wrote:
OK, so it will render the "main" page (as refered in the manifest) as an
iframe there, with clicking on it leading to the "full page" app, correct ?
This being said, looks like something I could test easily.
Martin
On Thu, Apr 26, 2018 at 11:28 AM, Edoardo Sabadelli <edoardo@dhis2.org> > wrote:
Hi Martin,
the dashboard widgets/apps, listed under the Apps section in the
dashboard item selector, are rendered in the same way as before.
They are loaded in an iframe in a box added to the dashboard grid.
This is also to ensure existing apps can still work in the new Dashboards
app.
As for distinguishing between a full screen and a "widget" app, there
isn't anything in place as far as I know.
One way is to use a responsive layout in your app, to ensure the
content fits and is usable in both full screen and the small widget
box.
I didn't work with widget apps, so hopefully someone in the community
who has done that can help.
Cheers,
On Thu, Apr 26, 2018 at 10:35 AM, Martin Van Aken >> <martin@joyouscoding.com> wrote:
> Hi!
> We've been working with DHIS2 Apps for a while now, and found the
> general
> experience (as developers) pretty good with the d2 + React combo.
> Something
> I could not find info about is how the different kind of apps change,
> especially the DASHBOARD_WIDGET one - does that means that an app of
> this
> kind will be rendered as a box in the main view? If so, how to specify
> the
> part that should go there vs for example a full sized page after once
> clicked?
>
> Any doc or example on this would be great.
>
> As I'm there - thanks to the team there to provide a nice to use
> extension
> point in the form of webapps - much appreciated!
>
> Martin
>
> --
> Martin Van Aken - Freelance Enthusiast Developer
>
> Mobile : +32 486 899 652
>
> Follow me on Twitter : @martinvanaken
> Call me on Skype : vanakenm
> Hang out with me : martin@joyouscoding.com
> Contact me on LinkedIn : http://www.linkedin.com/in/martinvanaken
> Company website : www.joyouscoding.com
>
> _______________________________________________
> Mailing list: DHIS 2 developers in Launchpad
> Post to : dhis2-devs@lists.launchpad.net
> Unsubscribe : DHIS 2 developers in Launchpad
> More help : ListHelp - Launchpad Help
--
Edoardo Sabadelli
DHIS 2
University of Oslo
edoardo@dhis2.org http://www.dhis2.org
--
Martin Van Aken - Freelance Enthusiast Developer
Hi, jumping in on this conversation with two related questions:
is there any (documented) way for a dashboard widget to identify “instances” of itself? So that if you add two or more instances of the same widget and want to set them up to show different things (e.g. different indicators), it would be possible for the app/widget to save and restore some sort of setting.
is there any way for a widget to query for dashboard parameters (particularly the orgunit filter)?
On the topic of filtering - do the maps in the dashboard now also obey the orgunit filter? The ability to drill down the whole dashboard (rather than just each widget in isolation) is quite powerful.
···
On Fri, Apr 27, 2018 at 1:27 PM, Olav Poppe olavpo@ifi.uio.no wrote:
Hi, jumping in on this conversation with two related questions:
is there any (documented) way for a dashboard widget to identify “instances” of itself? So that if you add two or more instances of the same widget and want to set them up to show different things (e.g. different indicators), it would be possible for the app/widget to save and restore some sort of setting.
is there any way for a widget to query for dashboard parameters (particularly the orgunit filter)?
Department of Information, Evidence and Research
World Health Organization, Geneva, Switzerland
Office: +41 22 791 3683 Mob1: +33 6 4434 2931 Mob2: +47 9188 0522
Skype: knutstar
Thanks for your answer - any way to specify where the “explore” link should lead:
this would allow my app to show a small part as an iFrame, then be called in full screen on click (like the Pivot tables & chart works in the Dashboard right now)
Martin
···
On Fri, Apr 27, 2018 at 10:47 AM, Edoardo Sabadelli edoardo@dhis2.org wrote:
Not exactly, the content in the iframe is usable from within the box
in the dashboard.
There isn’t a way of going full screen at the moment, but it can be
Way of widgets identifying themselves, this is actually supposed to be for all apps, to sort of have unique-app-id that’ll unique like android apps, so names and version can change but it’ll stay the same, this is on jira but not implemented yet, would help tracking and triggering of widgets and their counterparts apps
Explore and going full screen limitations, at the moment, there’s no such features, explore simply opens the same widget iframe in separate page, with scorecard we had to write widget that’s actually a fully fledged widget, so on explore we’d check if it’s separate page to give you impression of full app and impression of just a widget on small page, but above features would definitely solve this
Access to global selections, at the moment iframe loaded apps have not been provided with means of accessing anything outside, because they’re essentially brand new page running as subpage, standards could be put such that global filters could pass selections to the iframe url of the app and trigger reload(or abandon iframe idea all together and persue much better one! Think web components and custom elements)
Rendering on native mobile apps(android & iOS), because widget are stand-alone pages but still using utilizing same page sessions cookies and page header contents, they are presented as a fake new page trying to impersonate other page, this pause a security dilemma and often forces nginx to allow such except for browser, but never torelated on native mobile and hence never working there.
Most of these concepts are already in past jira issues awaiting priority to be picked up, but should you have interesting in innovating there, three major things to solve
Abandoning iframe in favor of web components (but keeping airframe simplicity of integration) - solve global filters accesibility and other in memory info, solve security for android, allow distinction of states(full or widget)
Add app property in manifest for appid and make app urls use app ids with support for accepting more parameters
Add property in widget for corresponding appids for widgets to allow explore by reference to apps or prompting install when absent(app id would guarantee this)
HISP Tanzania can help further brainstorming and potential solutions, let me know if you’re embarking on this.
Way of widgets identifying themselves, this is actually supposed to be for all apps, to sort of have unique-app-id that’ll unique like android apps, so names and version can change but it’ll stay the same, this is on jira but not implemented yet, would help tracking and triggering of widgets and their counterparts apps
Explore and going full screen limitations, at the moment, there’s no such features, explore simply opens the same widget iframe in separate page, with scorecard we had to write widget that’s actually a fully fledged widget, so on explore we’d check if it’s separate page to give you impression of full app and impression of just a widget on small page, but above features would definitely solve this
Access to global selections, at the moment iframe loaded apps have not been provided with means of accessing anything outside, because they’re essentially brand new page running as subpage, standards could be put such that global filters could pass selections to the iframe url of the app and trigger reload(or abandon iframe idea all together and persue much better one! Think web components and custom elements)
Rendering on native mobile apps(android & iOS), because widget are stand-alone pages but still using utilizing same page sessions cookies and page header contents, they are presented as a fake new page trying to impersonate other page, this pause a security dilemma and often forces nginx to allow such except for browser, but never torelated on native mobile and hence never working there.
Most of these concepts are already in past jira issues awaiting priority to be picked up, but should you have interesting in innovating there, three major things to solve
Abandoning iframe in favor of web components (but keeping airframe simplicity of integration) - solve global filters accesibility and other in memory info, solve security for android, allow distinction of states(full or widget)
Add app property in manifest for appid and make app urls use app ids with support for accepting more parameters
Add property in widget for corresponding appids for widgets to allow explore by reference to apps or prompting install when absent(app id would guarantee this)
HISP Tanzania can help further brainstorming and potential solutions, let me know if you’re embarking on this.
Thanks for your answer - any way to specify where the “explore” link should lead:
this would allow my app to show a small part as an iFrame, then be called in full screen on click (like the Pivot tables & chart works in the Dashboard right now)
