Dashboard widgets, including angular-ui-bootstrap css

@raff and others…

So within the “programs” dashboard widget in coreapps (https://github.com/openmrs/openmrs-module-coreapps/tree/master/omod/src/main/web/dashboardwidgets/programs) I’m using the angular ui bootstrap datepickerPopup, and it’s working fine, I’m just having a tough time figuring out how to include the proper css (or at least pick up the proper css). You can see the attached image.

Any hints as to the best way to make sure the CSS is properly packaged up and included?

Thanks, Mark

It seems Bootstrap css needs to be added in addition to angular-ui-bootstrap, but loading it breaks positioning of other elements of the page… I’m trying to figure out why is that…

Thanks @raff, I saw you commits… I tried to play around with adding dependencies and modifying the webpack.config css processing, but I was definitely hacking around without knowing much, so thanks for digging into it.

I do think I’m seeming what you are seeing–the date picker is now properly styled :slight_smile: but the right margin alignment is all now messed up. :frowning:

I’ll assume you are still working on it, let me know if you want to look into or test anything.

Take care, Mark

So, besides the issue with the right margin, it also looks like the glyph icons aren’t being pulled in properly… see the left and right arrows in the image below.

Thoughts? I found some info online about adding the icons via webpack, but I didn’t want to touch all the rules you’d set up in webpack since I’m not 100% sure what they all do.

Image included below…

Take care, Mark

1 Like

Acutally, @raff, for what it’s worth, at the end of the day, all I really need to do is include a datepicker widget within the programs dashboard widget. :slight_smile: I’m not quite sure why I chose the bootstrap datepicker widget over the angularui jquery datepicker we use elsewhere… I can try switching the jquery one if that makes sense. Or us another one? Thoughts? Ideas on what our overall date widget solution should be in this context?

Take care & thanks! Mark

@mogoodrich, I see! I think we should switch then to the jquery datepicker used in Reference Application to stay consistent.

Thanks @raff. Yeah, one of the downsides in working on a piece of functionality on and off over a course of a few months is I forget why I originally made certain decisions, re: using the bootstrap datepicker instead of the jquery one we use elsewhere. I’d have to assume it was because I though it was the way forward for some reason, but I easily could have been wrong. I will look to switch it out and keep you updated if I notice any issues.

Take care, Mark

@mogoodrich, pull the latest changes. I’ve already fixed it to use bootstrap-datepicker…

Yes, after I wrote the above response I noticed… awesome, thanks so much!
Something isn’t working 100%, but I’m firing up the environment now, will play around and let you know if I can’t fix it for any reason.

Take care, Mark

@raff so I’ve been pulling my hair out for a while on this and going back and forth… getting the old jquery datepicker to work with the code was becoming more problematic than I had hoped. I had to rewrite the way the date was set, and then I realized that the widget used different date format codes that angular, so I had to define both a config.dateFormatJquery and config.dateFormatAngular… then I realized since I had designed for the widget to be used multiple times on the same page (and in fact we will use it that way) then I’d have to rework the jquery code to not reference objects by ids…

Anyway, all things that probably could be overcome, but it seemed like I was “hacking in the WRONG direction”… I assume including jquery directly in the html templates is not the way we want to go long-term?

So I went back to using the angularui bootstrap datepicker–it seemed that since it was working perfectly minus the styling, figuring out how to make the styling work seemed a better use of time… I got close on that using a suggested method of “wrapping” the bootstrap css… but something still wasn’t working right, so I figured I’d step away for a bit and start a convo on Talk about datepickers… will do that now and @ you…

Thanks for the help! Mark

I started another thread about this here:

I agree we shouldn’t be putting js code directly in html as I did here https://github.com/openmrs/openmrs-module-coreapps/blob/master/omod/src/main/web/dashboardwidgets/programstatus/programstatus.html#L66-L76 (it was a quick hack for testing). We need to wrap the datepicker in an angular component and fix the issue with different date formats for angular and jquery in there (basically make the component accept angular format and convert it internally to jquery). The wrapped datepicker could be then moved to the ui components library at https://github.com/openmrs/openmrs-web-angularjs-ui-components

The uiframework uses jquery boostrap-datepicker, so I would vote to continue to use that. It’s visually more appealing to me than the angular-ui-bootstrap datepicker.

Functionality-wise the jquery datepicker has an integrated time picker, whereas for the angular-ui datepicker you need to use a separate timepicker.

I haven’t mastered css enough to quickly figure out how to fix the issues with bootstrap css and reference application. Not sure how much work it would be…

@raff, I think that’s probably the best option (wrapping the existing jquery datepicker we use in the Ref App into a angular component and including it in our openmrs-web-angularjs-ui-components).

@burke, not sure what current priorities are, but is there any chance we can prioritize getting someone from the core team to work on this? I’ve been working on creating some new widgets for program management using our new (post-UI Framework) methods, but it’s been frustrating not to have an out-of-the-box datepicker widget to use.

@mseaton fyi

Take care, Mark

I’ve created the basic component at https://github.com/openmrs/openmrs-module-coreapps/commit/ee0dd7f68cdfae03ed29049410167115bd0db762

It still needs to be extracted out to a ui library.

@mogoodrich, could you please create issues for any remaining work you see is needed?

Awesome, @raff, thanks so much for putting up with us early adopters with our feature requests… :slight_smile:

I should be able to work on this today–if there’s any additional work, I’ll see what I can do myself and make issues for what I can’t…

Are you done working on it for the day? I don’t want to step on your toes when I work on it today.

Take care, Mark

@raff… thanks again… and I’ve gone ahead and creating three tickets for remaining/outstanding issues I am seeing:

I spent some time this afternoon working on RA-1392, but for the life of me I couldn’t get it to work properly. I haven’t had much of a chance to look into RA-1393, but it wasn’t immediately obvious to me what wasn’t working there.

Finally, RA-1394 I didn’t work on at all, and I should be able to figure that one out, especially if RA-1392 gets implemented and there’s a pattern to follow. So in terms of priority, 1392 is the most important and 1394 is the least.

Take care & thanks again, Mark