NH ProfBalancing functionality, simplicity and form
There are two features that I want to get done before I call a feature freeze on NH Prof and just deal with any bugs and improvements that come up until I feel it is mature enough to call it v1.0.
One of them is filtering capability. This was a pretty common request once people started realizing the kind of things that they can do with NH Prof.
Ad hoc filtering into NHibernate’s activity can bring up a lot of insight, and I certainly think that this would be an good feature to have.
The problem is that while this is a good feature, it also introduce a significant amount of complexity. This wouldn’t be a problem if the complexity was on the application side. We can deal with complexity.
The problem is that I think that this introduce a not insignificant amount of complexity into the user's’ hands. Take a look at the mock UI that I created:
This isn’t the way it will end up looking, but it is a good place to start the conversation.
What is your opinion?
More posts in "NH Prof" series:
- (09 Dec 2010) Alert on bad ‘like’ query
- (10 Dec 2009) Filter static files
- (16 Nov 2009) Exporting Reports
- (08 Oct 2009) NHibernate Search Integration
- (19 Aug 2009) Multiple Session Factory Support
- (07 Aug 2009) Diffing Sessions
- (06 Aug 2009) Capturing DDL
- (05 Aug 2009) Detect Cross Thread Session Usage
- (22 May 2009) Detecting 2nd cache collection loads
- (15 May 2009) Error Detection
- (12 May 2009) Queries by Url
- (04 Feb 2009) View Query Results
- (18 Jan 2009) Superfluous <many-to-one> update
- (18 Jan 2009) URL tracking
- (10 Jan 2009) Detecting distributed transactions (System.Transactions)
- (06 Jan 2009) The Query Cache
- (05 Jan 2009) Query Duration
- (24 Dec 2008) Unbounded result sets
- (24 Dec 2008) Row Counts
For your design:
Relatively simple UI model to interact with
Requires few interactions to set up a filter
Simple to implement
Size of form will increase as more options become available.
Could be overwhelming to some users.
No live preview to see the effect changes have on your result data.
Not very funky :)
Another idea could be to have a filter builder, I've moqued up an example here:
This requires more work to implement.
My FAVOURITE filters are ones that you apply to the ACTUAL data as you're viewing it, where you can see results immediately, and tweak. So, you'd be able to click on the duration column in the results, and filter it directly. No need for a context switch.
Most backoffice views (be it desktop or html form) exists from three parts: search, overview and detail. It's a methodology we started using beginning 2001 for our online html based backoffice. Now we more and more are shifting towards WPF, IoC and Composite UI's (very roughly based on SmartClient Software Factory).
Let's say we want to query some customers. Our search screens don't perform the search itself, they only collect the input from the input element and assign them to a (disconnected) entity instance.
This instance is used to build the search query in what I find a rather simple matter:
('s' is a ISession and 'tx' is a ITransaction instance, 'cust' is the 'Customer' instance create by the search screen)
We start with a simple statement:
ICreteria q = s.CreateCreteria(typeof(Customer));
Than we start building up the where clause:
Other properties are added is a similair way.
All left to to is calling the List method to get the result:
IList <customer results = q.List <customer();
But than again, we always know what type of information we are looking for.
BTW: We use the normale DOS-like wildcards for backoffice users and replace the '*' and '?' characters with the correct sql versions ('%' and '_'). Because we check if a field contains wildcards we don't perform unneeded like queries.