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 but the right margin alignment is all now messed up.
I’ll assume you are still working on it, let me know if you want to look into or test anything.
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.
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. 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?
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.
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.
@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…
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.
@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.