Wicket-dashboard quolification questions

[PhantomYdn]

Hello @decebals ,

I'm concidering your great library for my project: https://github.com/PhantomYdn/Orienteer.

It looks find except few questions:

1) Is it possible to specify width of a widget? In my case: there should be 1 full-width widget with dynamic height and configurable set of subwidgets. For the rest it will be cool to use 2 columns. 2) Do you know some example where settings of a widget can be opened in a modal window instead of just inplace? 3) Is design ui responsive? According to my playing with demo: whenever you resize window - you will have 2 columns. Are you planning some work on that?

[decebals]

1) Is it possible to specify width of a widget? In my case: there should be 1 full-width widget with dynamic height and configurable set of subwidgets. For the rest it will be cool to use 2 columns.

In branch layout I introduced the DashboardLayout concept with two concret implementations: ColumnDashboardLayout and GridDashboardLayout. First implementation is the default/classic implementation and the last implementation is based on Gridster. The work is in progress. Maybe GridDasboardLayout is what you search.

2) Do you know some example where settings of a widget can be opened in a modal window instead of just inplace?

No but I think that can be possible with some modifications.

3) Is design ui responsive? According to my playing with demo: whenever you resize window - you will have 2 columns. Are you planning some work on that?

It is not responsible. The dashboard panel space (width) is divided into N equal columns.

Right now I am busy with other projects and I don't have to much time for this project. Sure any contribution (PR, code snippet are welcome).

[PhantomYdn]

Thank you! That sounds good for me:) And it's cool that you are on a github: so PRs will be applied without huge delays.

[PhantomYdn]

Questions: 1) It seems that DashboardContext might be just one per application. Is that right? In our case it should be possible to have several contexts.

Any ideas how to workaround that? It seems that DashboardContextInjector should be removed and replaced by some proper version... But it looks like a hack.

2) Widgets should be able to take some data from page where they are displayed. So content of widgets on one page should differ from content on other pages. Do you hava ideas how dynamically pass data source to widgets dynamically?

[PhantomYdn]

Our requirements for a widget subsystem: just in case if you are interested in wide picture.

https://github.com/OrienteerDW/Orienteer/wiki/Widgets-requirements

[decebals]

1) It seems that DashboardContext might be just one per application. Is that right? In our case it should be possible to have several contexts.

DashboardContext it's a holder for some components of the framework (WidgetFactory, WidgetRegistry, DashboardPersister, WidgetActionsFactory). It's one instance per application. Why do you need more contexts per application?

2) Widgets should be able to take some data from page where they are displayed. So content of widgets on one page should differ from content on other pages. Do you hava ideas how dynamically pass data source to widgets dynamically?

You can do this theoretically in your WidgetView (for custom widgets). The widgets supplied with wicket-dashboard are not built with this request in mind.

[PhantomYdn]

Example. There is need to have several dashboards: for server monitoring parameters, for business indicators, geo locator parameters. In this example all 3 dashboards should have different set of available widgets.

Some other results after close review of wicket-dashboard: 1) There is almost no difference between DashboardSettings and DashboardContext: both can have only 1 runtime instance. In this case it might be better even merge them from user API standpoint. 2) There is no way to have different dashboards per user. It can be workarounded by custom DashboardPersister which will get current user's session and load accordingly. But it might be a little better to allow pass dashboard identification for DashboardPersister. For example case with several dashboards per user already hard to implement...

[decebals]

Example. There is need to have several dashboards: for server monitoring parameters, for business indicators, geo locator parameters. In this example all 3 dashboards should have different set of available widgets.

In my mind, an widget (as type) is something generic: a chart, a table, an indicator, an alert. On each dashboard I can put any widget (as type) with a concrete DataModel. You can have instances of the same widget type (ChartWidget) with different DataModel. This DataModel is given by the settings of that wicket instance (ChartType, ChartModel, StartDate, EndDate, ...). Maybe the best approach is to made a filtering when you press "Add widget" button in a dashboard. You can classify widgets (outside of wicket-dashboard) on application startup and apply a filter when you show all widgets available for a dashboard.

2) There is no way to have different dashboards per user. It can be workarounded by custom DashboardPersister which will get current user's session and load accordingly. But it might be a little better to allow pass dashboard identification for DashboardPersister. For example case with several dashboards per user already hard to implement...

Maybe my response in #1 for sskjames help you.

[PhantomYdn]

Yes - it's possible to persist dashboard per user, but it's hard to have several boards per user and on the same page.

And one more problem that I still see: how to bind data for a widget with a page where user is currently viewing.

Regarding type of a widget: I just realized that in our case there are 2 types of settings for a widget: user UI settings and system "data-binding" related settings. Second type of settings should be stored even if widget was removed from a dashboard.

[decebals]

NextReports uses a fork (one of first version) of this library for dashboarding. You can see in action the dashbaording section of NextReports at http://demo.next-reports.com (username: demo, password: demo). In my opinion this library is better than the version from NextReports but this is another story. In that project I know the persistence layer (Java Content Repository - Jackrabbit) but in this library I must have an abstract layer - DashboardPersister. All the persistence of dashboards is realized in DashboardService. You can observe that DashboardService is more complicated then DashboardPersister because in NextReports I have multiple dashboards per user and each user can share their dashboards with other users. It's a more complicated picture. I don't want to complicate wicket-dashboard with advanced features (multiple dashboards, dashboards per user, ...) and I prefer to move this complexity in the application that uses wicket-dashboard. I feel that definition of DashboardPersister is imperfect and I wish to improve it but I don't want to force all the developers of this library to deal with complex concepts. @solomax uses wicket-dashboard in apache openmettings project and maybe he can tell us his scenario and how he resolved some issues.

And one more problem that I still see: how to bind data for a widget with a page where user is currently viewing.

In theory (see NextReports) in your WidgetView.onInitialize you have access to page via getPage() and of course to username via getSession() and you can create a DataModel according these variables. If this is not what you want please describe with more words your scenario.

Regarding type of a widget: I just realized that in our case there are 2 types of settings for a widget: user UI settings and system "data-binding" related settings. Second type of settings should be stored even if widget was removed from a dashboard.

The settings are saved when you save the widget. If you want to keep some settings even if widget was removed from dashboard then maybe you can do it with a custom DashboardPersister.

I see from your requirements that for your application you want a relative complex dashboard system and I am afraid that wicket-dashboard in actual form is not an out of the box solution.

[PhantomYdn]

Thank you for detailed reply! NextReports looks quite interesting and, actually, intersects with what Orienteer was designed for. Will dig deeper.

[decebals]

@PhantomYdn Can you contact me please on private (see my email address on my github profile)? I didn't found other method to have your contact address :smile: It's not related to wicket-dashboard. Thanks!

[PhantomYdn]

@decebals, sent email to you! Not sure that you got it.