On Wed, May 24, 2017 at 03:37:07PM +1000, Dan Callaghan wrote: > Excerpts from Don Zickus's message of 2017-05-22 17:08 -04:00: > > Hi Dan, > > > > A recurring theme we seem to encounter when working through various features > > we want to implement in beaker, is the challenges the front-end poses to add > > code. It isn't just a straight-forward add code (once you understand the > > technology), but there is an added bonus of understanding the strange quirks > > the legacy code is laying upon the current code. :-) But you already know > > that. :-) > > > > > > I wanted to reach out and understand what the initial thoughts were to > > migrate away from the legacy stuff. Obviously your team made an initial > > effort and stopped. And there is still plenty of work to be done. Was a > > process to move forward ever documented? > > Well, we never stopped (up until this year I mean). About 75% of the > TurboGears code has been ported to Flask + Backbone. Our process was > that whenever we needed to add a new feature or make substantial changes > in a TG widget, we would first port it to Flask + Backbone and then > fix/improve it. But you are right there are plenty of pieces unported > (systems grid is the last problematic one). Beaker's UI is huge.
And maybe that is where I foolishly started. Is the csv_import_export.py stuff part of 'systems grid'? I guess I was looking at all the class inits in bkr/server/controllers.py::Root() and thought there was a ton of work to do (are you saying that is only the last 25%??). > > > Granted things are a little bit better now that we understand how to > > run the > > server in developer mode better and have the corresponding lengthy > > dependencies installed. But I still struggle just to convert one page to > > strictly flask and still involves using kid files to pass back to > > cherrypy??? > > Well once a whole page is ported over there will be no CherryPy stuff > left. Just a shell of a Kid template to emit JSON and a Backbone widget > (and those can go away once master.kid is not needed). Hmm when trying to convert csv_import_export, I found myself creating a new csv_import_export.kid file because I couldn't figure out the why my changes were not being called from the master.kid. I should re-test because maybe it was an install problem that run-server.sh fixes??? > > But you are probably thinking of the system page, which is still > a mixture of TG and Backbone widgets. Bear in mind it is by far the > biggest single page, containing I think 10 independent tabs and many > widgets. Of those only 3 are not yet ported. So long as there are TG > widgets left on it, the outermost rendering for that page is still done > in CherryPy. > > > With all the changing technology out there, it would be nice to have > > beaker > > be updated easily to match our needs. So I was trying to wrap my head > > around an easy process to migrate things to a better place. > > It would be nice... There is no easy process except to start rewriting. I saw some of the task and job rewrites and noticed that too. I was hoping to explain this to various folks so they could just put in a few hours here and there and port it. But it does not appear to be as mechanical. > > Now you can probably appreciate when people said "why does it take you > guys so long to churn out Beaker features? why haven't you done mine > yet?" it's not because the three of us were just sitting around > twiddling our thumbs. :-) No, I definitely appreciate/understand the effort here. But at the same time it saddens me when various features are blocked because the effort is rather large due to this problem. Which is why I wouldn't mind helping resolve this and move back into making features easy again. Thanks for the info! Cheers, Don _______________________________________________ Beaker-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
