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
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
> With all the changing technology out there, it would be nice to have
> 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!