albertocolom / elmah

Automatically exported from code.google.com/p/elmah
Apache License 2.0
0 stars 0 forks source link

Add search and filtering to the UI #20

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
Add the ability to create UI filters. 

For example, we might add a filter link that expands a filter box (dhtml)
in the UI. That would allow us to pick which Error Codes we're interested in.

Potential Filters:
  * Date range filters.
  * User Filters (starts-with, ends-with, contains)
  * Error Filter (starts-with, ends-with, contains)
  * Type Filter
  * Code Filter

Original issue reported on code.google.com by haac...@gmail.com on 24 Jul 2007 at 11:55

GoogleCodeExporter commented 8 years ago
Also we should improve the paging, so that you can jump to a specific page # of 
errors.  This can be easily done using Telerik RadGrid or Infragistics 
UltraWebGrid 
which supports built in filtering on the columns, paging, etc.

Original comment by abdullah...@gmail.com on 1 Aug 2007 at 1:20

GoogleCodeExporter commented 8 years ago
I'm working on this. I was wondering whether filtering should be performed on 
the
client via DOM manipulation or on the server.

Original comment by simone.b...@gmail.com on 23 Aug 2007 at 10:38

GoogleCodeExporter commented 8 years ago
Since you won't have all the log data on the client, the filtering (naturally) 
will 
have to be done on the server. I think what Phil meant about DHTML in the 
original 
issue comment was that the query UI could pop-in rather than taking up screen 
real-
estate unnecessarily when it's not needed.

Original comment by azizatif on 24 Aug 2007 at 4:14

GoogleCodeExporter commented 8 years ago
Yep, that's what I meant. Just an expandable box with advanced search and 
filtering
options! The filtering would happen on the server of course.

Original comment by haac...@gmail.com on 24 Aug 2007 at 8:03

GoogleCodeExporter commented 8 years ago
Looking at Simone's question again, I think it can be interpreted another way. 
I 
think he's asking whether the filtering is done on the server and then rendered 
from 
the server or is it done via Ajax and then the result brought back into the 
current 
view. If this second interpretation of the question is more correct then the 
first 
and better approach here should be to filter and render on the server. The 
input 
from the search mask should result in an HTTP GET with a query string holding 
the 
criteria. The benefit of this approach is that the URL-based query can be 
bookmarked, exchange via e-mail and IM and the back button won't be broken. A 
more 
Ajaxy version can always be considered later.

Original comment by azizatif on 25 Aug 2007 at 9:19

GoogleCodeExporter commented 8 years ago
Yes, I'm finally going the HTTP GET way. Filtering is working fine, now I'm 
trying to
integrate it with paging, since paging stuff are simple links and throw away
filtering parameters passed on querystring.

Original comment by simone.b...@gmail.com on 27 Aug 2007 at 11:07

GoogleCodeExporter commented 8 years ago
Oh, I've gone too fast. Filtering is working fine with MemoryErrorLog, not other
ErrorLog subclasses. I think it does need to be supported at ErrorLog subclasses
level, and I've changed the signature of the GetErrors method to accept two more
parameters, a filter type and the arguments for the filter. This feature is 
trickier
than I thought, since this implies changing each ErrorLog inheritor logic. I 
hoped it
could be implemented at presentation level, but that way the paging would get 
messed
up, because you end up filtering at higher level, that is, only on the records 
you
see in the current page, and you have no knowledge of following, previous 
pages. For
example, you may find yourself with an empty page 1 and full page 2, pretty 
weird.

Original comment by simone.b...@gmail.com on 27 Aug 2007 at 11:36

GoogleCodeExporter commented 8 years ago
Here's what I've come up so far. Filtering is working on the MemoryErrorLog 
class,
and I've brought some functionality up to the base ErrorLog class, to extract 
filter
arguments info. Still paging is not integrated with filtering, my idea is to put
paging into the form I used for filtering so that all the parameters are kept 
at each
request on the query string. Actually, performing filtering on other ErrorLog
subtypes doesn't look so complicated, even if it entails changing the store 
procedure
for the SqlErrorLog class.

Original comment by simone.b...@gmail.com on 28 Aug 2007 at 12:51

Attachments:

GoogleCodeExporter commented 8 years ago
I've added filtering for the XmlFileErrorLog as well and made paging work again.
Filtering for the SQL error log is still not there yet, anyone wanna put his 
hands on
it? It shouldn't be so challenging, I just don't use to work with SQL server a 
lot.

Original comment by simone.b...@gmail.com on 28 Aug 2007 at 11:41

Attachments:

GoogleCodeExporter commented 8 years ago
Can't wait to try it out. I really need it to work with SQL Server so I can try 
it
out at work. I don't have any time to implement SQL filtering yet, but if you 
get to
it first, that's great!

Original comment by haac...@gmail.com on 29 Aug 2007 at 10:40

GoogleCodeExporter commented 8 years ago
I'm on the SQLite provider right now, but I'll see if I can do it. I just need 
to
refresh some SQL ;)

Original comment by simone.b...@gmail.com on 29 Aug 2007 at 10:48

GoogleCodeExporter commented 8 years ago
Here it is with the SqlErrorLog workin with filtering too. It needs some testing
however. I changed the store procedure to retrieve the errors, just that.

Original comment by simone.b...@gmail.com on 30 Aug 2007 at 12:26

Attachments:

GoogleCodeExporter commented 8 years ago

Original comment by azizatif on 10 Oct 2007 at 8:46

GoogleCodeExporter commented 8 years ago
Sorry or my noob question, but how do I apply this patch?  I tried getting this 
tool 
(http://gnuwin32.sourceforge.net/packages/patch.htm) but it seemed confused 
with the 
file format

Original comment by abdullah...@gmail.com on 22 Oct 2007 at 9:02

GoogleCodeExporter commented 8 years ago
Abdullah,

you don't need such tools, a Subversion client like TortoiseSVN will do. It has 
a
specific option to apply patches to a working copy.

Original comment by simone.b...@gmail.com on 22 Oct 2007 at 9:07

GoogleCodeExporter commented 8 years ago
Is there any chance this patch could be updated to be compatible with the 
current 
BETA2 version of ELMAH?  As suggested on 10/22/07, I tried using TortoiseSVN to 
apply the patch, but realized it was not in synch with the new source.  I also 
attempted to manually apply the patch, but ran into problems in a couple of 
files 
when trying to locate the code to be deleted/added.  

BTW, this is a terrific project - thanks for your efforts.

Original comment by jrn...@metrocast.net on 11 Jun 2008 at 1:35

GoogleCodeExporter commented 8 years ago
@johnrosset: The best way to search and filter right now is to download the log 
in 
CSV format (this is already addressed as issue #26 and working) and then use 
Excel's 
data filtering capabilities. You may also want to look into LogParser 
(http://www.microsoft.com/technet/scriptcenter/tools/logparser/default.mspx), 
which 
provides SQL-like capabilities on the CSV data. The CSV log was implemented 
precisely so that you can leverage existing tools instead of waiting for ELMAH 
to 
provide everything out of the box as well as match the capability of existing 
tools.

Original comment by azizatif on 11 Jun 2008 at 1:54

GoogleCodeExporter commented 8 years ago

Original comment by azizatif on 13 Nov 2008 at 5:57

GoogleCodeExporter commented 8 years ago

Original comment by azizatif on 9 Oct 2009 at 9:25

GoogleCodeExporter commented 8 years ago

Original comment by azizatif on 18 Oct 2010 at 11:01

GoogleCodeExporter commented 8 years ago
Hi Atif Aziz,

Thank you for ELMAH!
Could we not use datatable.net or jQgrid instead of a GridView for search 
facility...
Also, Bilal Haider has something called XGrid(if my memory seres right)

Regards,
naveenj

Original comment by naveen.c...@gmail.com on 30 Nov 2010 at 3:30

GoogleCodeExporter commented 8 years ago
Will this be included in v1.2?  Thanks for all the hard work!

Original comment by ddougl...@gmail.com on 10 Jan 2011 at 2:45

GoogleCodeExporter commented 8 years ago
Hi all, 

Are there any plans for this patch and the searching functionality to be part 
of future releases as standard? 

Thanks, 

-Rob

Original comment by robmorri...@gmail.com on 8 Nov 2011 at 3:55

GoogleCodeExporter commented 8 years ago
Issue 307 has been merged into this issue.

Original comment by azizatif on 14 Aug 2012 at 6:49

GoogleCodeExporter commented 8 years ago
I think the ELMAH UI is great as it is. I like the idea that ELMAH provides the 
core feature around logging and that you use the standard UI for simple things 
and something else for the more advanced things. I've successfully imported all 
my errors in Excel, which makes it possible to search, group etc. Also I've 
started the project named http://elmah.io, which makes these things possible.

Did you consider removing the UI from the core and providing this feature as a 
separate package? Giving people a good framework for building UI's on top of 
ELMAH, would probably give birth to multiple UI's. Each focusing on different 
things.

Original comment by thomasar...@gmail.com on 18 Aug 2013 at 6:36

GoogleCodeExporter commented 8 years ago
This issue has been migrated to:
https://github.com/elmah/Elmah/issues/20
The conversation continues there.
DO NOT post any further comments to the issue tracker on Google Code as it is 
shutting down.
You can also just subscribe to the issue on GitHub to receive notifications of 
any further development.

Original comment by azizatif on 25 Aug 2015 at 8:15