Sorry Don, just noticed I never replied to this one.
Excerpts from Don Zickus's message of 2017-05-24 11:50 -04:00:
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%??).
No CSV import/export is its own little side thing. The "systems grid" is
all the hairy stuff in controllers.py (plus some pieces in
search_utility.py) etc which is what you are seeing. It serves
https://beaker.engineering.redhat.com/ with all the search functionality
plus the related ancillary pages that share the same widget. That is
indeed the biggest remaining piece.
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???
You might have solved this by now... Will follow up on your other
thread. But you wouldn't want to change master.kid (that is the master
template which all others inherit from). It would make sense that you
have a kind of skeleton csv_import_export.kid that just calls out to
a Backbone widget to render itself on the page. We have got that for
quite a few pages now. Eventually, once all the last TG widgets are
removed, we can divorce ourselves from Kid completely, and consider
going for something fancier like a "single-page app" etc.
> > 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.
Porting each widget or page is a pretty big chunk of work unfortunately.
The main reason is because you need some more thorough test coverage
(the HTTP API is tested separately from the web UI) -- having that is
a good thing of course, but it takes time to write. And then it adds
extra difficulty if you are dealing with a particularly badly designed
(or badly aged) piece of UI that needs some love to make it behave in
a reasonable way.
--
Dan Callaghan <dcallagh(a)redhat.com>
Senior Software Engineer, Products & Technologies Operations
Red Hat