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 <dcall...@redhat.com> Senior Software Engineer, Products & Technologies Operations Red Hat
signature.asc
Description: PGP signature
_______________________________________________ Beaker-devel mailing list -- beaker-devel@lists.fedorahosted.org To unsubscribe send an email to beaker-devel-le...@lists.fedorahosted.org
