Redmine Client / Discussion / Open Discussion: Code Questions / Suggestions

I was looking at your code thinking about some ways I'd like to reinvent the UI for my own purposes and also implement the Nohal.Redmine library in some of my applications. One thing that stuck out in my mind is that the client is always pulling down a full issue list for a given project, and it seems to take some time to do it (I only have 81 open issues for the project I was testing with).

For instance, in one of my applications, I added an "Open Issues" menu option to my "Help" menu that gets populated asynchronously as the form opens, and it takes a few seconds before the menu options start appearing. I also did this with "Recent Activity", and the result there was even slower (and in both cases there was way to much information for a menu item, but that's another matter).

I'm guessing the constraint on execution time lies with the API, not with your code, but the seemingly obvious workaround would be to limit the number of results returned. Of course, I wouldn't want to always query for a limited result set, so it seems like this should be variable. Now I understand that the reason you're probably wanting to pull the entire issue list is so that you can extract Trackers, Watchers, etc. with the constraints foisted upon you by the limitations of the API, but I wonder if maybe there's a better way to query the issue list on a more limited basis and then later pull a full listing if necessary (and maybe even skip over what you have already pulled down??).

Also, I really wanted to overload the GetIssues() method to be able to filter the feed by the various fields, something like…

Redmine.GetIssues(int projectId, IssueFilter[] filters)

… or even better…

Redmine.GetIssues(int projectId, IssueFilter[] filters, int maxIssues)

..where IssueFilter would be an object containing an enumeration of the various fields available and the value to filter on, much like what you've done with RecentActivityType in the GetRecentActivity() method, but with one more layer of abstraction.

For instance, to allow a user to see all the issues they've requested and those they are watching. This would bring some interesting UI possibilities for users in my situation, where the end users have access to Redmine to collaborate with developers.

For instance, I could add a notification icon to my project and combine intermittent calls to the Redmine library to see what issues the user is watching that appear in the recent activity list in the time since the project was loaded and/or last queried the system to notify them of work done on issues that effect them in near real-time. (Yes, I know the emails do this, but lets face it, users ignore email notifications.)

I think it'd be pretty cool to get some of this functionality here encapsulated in controls that can be thrown into a production application.

As I said in my review comment, I see a lot of possibilities here, but they all rest on making the Redmine.dll a little more flexible and lean. If I'm sounding critical, that is not intentional. I really like what you've done here and I see a lot of potential. Perhaps when I get some time I can implement some of what I'm suggesting here. Also, I'd like to get your input if you see problems with my line of thought. I know I'm probably going beyond your intended scope, but I think the library itself could be very useful.

Code Questions / Suggestions

Forums

Help

Code Questions / Suggestions document.SUBSCRIPTION_OPTIONS = { "thing": "topic", "subscribed": false, "url": "subscribe", "icon": { "css": "fa fa-envelope-o" } };

Code Questions / Suggestions