FYI Search/Rights.html : The Refactoring!

For a while I have been wanting to experiment with making RT
a little more snazzy. Yesterday I started working on using AJAX
techniques to allow building searches without so many page
refreshes. Don’t worry, I plan on everything working the same
as it does now if the user doesn’t have javascript (on).

The first step is taking most of the code out of Build.html
and putting it in RT::Interface::Web::Buiuld.pm (where it
can be regression tested much easier). This also will
have the benefit that much of the search code duplicated in
Asset Tracker can be removed.

I just wanted to let everyone know what I was up to. If
you have any warnings, suggestions, or feature requests,
please send them my way.

BTW, I am working on 3.4.HEAD which seems to be logically
the same as 3.5 (except CSS layout of course). Hopefully
I am not working with soon to be distincted (?) code.

-Todd

For a while I have been wanting to experiment with making RT
a little more snazzy. Yesterday I started working on using AJAX
techniques to allow building searches without so many page
refreshes. Don’t worry, I plan on everything working the same
as it does now if the user doesn’t have javascript (on).

I’ll be very interested to see what you come up with. Doing a second
javascript implementation of the query UI was something we always wanted
to do, though I’ve largely been convinced that we should be spending
that time on a simpler search UI instead.

The first step is taking most of the code out of Build.html
and putting it in RT::Interface::Web::Buiuld.pm (where it
can be regression tested much easier). This also will
have the benefit that much of the search code duplicated in
Asset Tracker can be removed.

I’d love that patch. Note also that much of that code is horrible,
horrible duplicate code of code from the TicketSQL library that should
be refactored back into that.

I just wanted to let everyone know what I was up to. If
you have any warnings, suggestions, or feature requests,
please send them my way.

BTW, I am working on 3.4.HEAD which seems to be logically
the same as 3.5 (except CSS layout of course). Hopefully
I am not working with soon to be distincted (?) code.

Hm?

Hi,

Jesse Vincent wrote:

The first step is taking most of the code out of Build.html
and putting it in RT::Interface::Web::Buiuld.pm (where it
can be regression tested much easier). This also will
have the benefit that much of the search code duplicated in
Asset Tracker can be removed.

I’d love that patch. Note also that much of that code is horrible,
horrible duplicate code of code from the TicketSQL library that should
be refactored back into that.

I’ve also been looking at that code a while ago (and I’ve sent a bug fix
for the search code to this list, but I guess it slipped through the
cracks … ;)). I had to conclude, that those two copies, though quite
similar, are still working in different ways. While the Search code is
building a tree for the expression, the TicketSQL code is merely parsing
it for syntactic correctness while handing it off to the
DBIx::SearchBuilder module (and some undocumented part of it aswell, I
might add ;)). So I find refactoring that code is not as easy a task as
it looks.

Rolf.

I’ve also been looking at that code a while ago (and I’ve sent a bug fix
for the search code to this list, but I guess it slipped through the
cracks … ;)).

Do you know about when? Can you reforward a copy to rt-bugs?

I had to conclude, that those two copies, though quite
similar, are still working in different ways. While the Search code is
building a tree for the expression, the TicketSQL code is merely parsing
it for syntactic correctness while handing it off to
DBIx::SearchBuilder module (and some undocumented part of it aswell, I
might add ;)). So I find refactoring that code is not as easy a task as
it looks.

The search code was forked from the TicketSQL parser by a developer who
didn’t fully understand the importance of code reuse. We’ve started into
cleaning this up, but yeah, it’s nontrivial to fix.

I’ve also been looking at that code a while ago (and I’ve sent a bug fix
for the search code to this list, but I guess it slipped through the
cracks … ;)).

Do you know about when? Can you reforward a copy to rt-bugs?

I had to conclude, that those two copies, though quite
similar, are still working in different ways. While the Search code is
building a tree for the expression, the TicketSQL code is merely parsing
it for syntactic correctness while handing it off to
DBIx::SearchBuilder module (and some undocumented part of it aswell, I
might add ;)). So I find refactoring that code is not as easy a task as
it looks.

The search code was forked from the TicketSQL parser by a developer who
didn’t fully understand the importance of code reuse. We’ve started into
cleaning this up, but yeah, it’s nontrivial to fix.

I’m not going there. I just want to get the proof of concept working,
and if we get some of the perl out of the component and into a testing
module, that’s a bonus. :slight_smile:

Jesse Vincent wrote:

I’ve also been looking at that code a while ago (and I’ve sent a bug fix
for the search code to this list, but I guess it slipped through the
cracks … ;)).

Do you know about when? Can you reforward a copy to rt-bugs?

It’s already in bug #6962.

Rolf.