adixon / ca.civicrm.logviewer

CiviCRM Log Viewer
Other
9 stars 11 forks source link

Add log level filter (#22) and improve display. #29

Closed gngn23 closed 3 weeks ago

gngn23 commented 1 month ago

Also use DataTable to display results (similar to proposal in #15).

Details see https://github.com/adixon/ca.civicrm.logviewer/issues/22#issuecomment-2230767292

adixon commented 1 month ago

Thanks for this. Converting to using quickform is an issue though, that's a really old part of the code base that we shouldn't be using if we don't have to.

I wonder if a really simple html GET form at the top that just does adds parameters to the url which can then filter the output might not be a reasonable way to do this? Most of the code you've written would still work as is, you'd just have to manually generate/build the html form?

gngn23 commented 1 month ago

Thanx for the feedback. I created the form with 'civix generate:form' (which generates quickform). I thought that would be better than manually generating the form ;) Can you point me to some alternatives or examples?

adixon commented 1 month ago

For sure that's the only form generation option in civix, and one I use still, though with hesitation every time.

Normally, I'd say it's an acceptable compromise, but I was hoping that since this is such a simple form, we could cheat a bit.

adixon commented 1 month ago

Thinking about this a bit more ... the stated goal of this extension is "It's useful for quick debugging during development and testing, and also useful on production sites to allow site maintainers to quickly check for errors that might not otherwise be evident, especially low-level errors that get caught and passed up".

Although I'm amenable and even enthusiastic about scope creep to the point where we can use it more effectively to track down more subtle recurring errors, I wouldn't want to lose this original goal. Specifically, I want it to depend on as few parts of the system as possible, since those parts might be throwing errors themselves. As an unlikely example, if quickform was generating errors and this extension used it, it wouldn't work.

adixon commented 1 month ago

Thinking about this a bit more ... the stated goal of this extension is "It's useful for quick debugging during development and testing, and also useful on production sites to allow site maintainers to quickly check for errors that might not otherwise be evident, especially low-level errors that get caught and passed up".

Although I'm amenable and even enthusiastic about scope creep to the point where we can use it more effectively to track down more subtle recurring errors, I wouldn't want to lose this original goal. Specifically, I want it to depend on as few parts of the system as possible, since those parts might be throwing errors themselves. As an unlikely example, if quickform was generating errors and this extension used it, it wouldn't work.