Open GoogleCodeExporter opened 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
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
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
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
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
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
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
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:
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:
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
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
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:
Original comment by azizatif
on 10 Oct 2007 at 8:46
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
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
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
@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
Original comment by azizatif
on 13 Nov 2008 at 5:57
Original comment by azizatif
on 9 Oct 2009 at 9:25
Original comment by azizatif
on 18 Oct 2010 at 11:01
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
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
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
Issue 307 has been merged into this issue.
Original comment by azizatif
on 14 Aug 2012 at 6:49
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
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
Original issue reported on code.google.com by
haac...@gmail.com
on 24 Jul 2007 at 11:55