Ross, I'm trying to make the SKOS plugin dispatcher aware but my original Cocoon sitemap doesn't seem to work well with Dispatcher so I should consider rewriting them probably looking at the DOAP plugin.
At the same time, the DOAP plugin is using a fixed base path (projectDetails) for its samples. Now, do you think I should follow the same approach as in the DOAP plugin or strive to make it work using sourcetypeaction? SinDoc On Tue, July 17, 2007 1:48 pm, Ross Gardler <[EMAIL PROTECTED]> said: > On 16/07/07, Sina K. Heshmati <[EMAIL PROTECTED]> wrote: >> The development of the Baetle plugin was suspended [1] and the priority was >> given >> to >> the SKOS plugin. Now, I think that the community could already start to >> brainstorm >> around the design and development of the plugin in question. >> >> Meanwhile, I'm discussing [2] with Henry Story to setup standard procedures >> to >> extract data from issue tracking systems (starting with JIRA), so that we'll >> be >> able to build our first samples of the plugin. >> >> The idea is to have a customizable Bug Dashboard for each project using >> Forrest. >> The Bug Dashboard consists of an arbitrary number of widgets, each of them >> associated >> with a specific search filter (content aggregation). What's more, Bug >> Widgets can >> communicate with the XML web server asynchronously (AJAX) to respond to >> user's >> requests for information. A simple and small, yet useful web-app, that is. > > I'd focus on manipulating the Baetle docs rather than the extraction > of data from Jira. Create some sample docs to use in the plugin, > otherwise you are likely to find yourself waiting for the JIRA > integration which we should not be looking at in any detail within > Forrest. > > I'd also caution against trying to create a fully functional "bug > dashboard". A projects chosen issue tracker should be doing that. What > I think would be useful for a Baetle plugin would be to have a bunch > of dispatcher contracts that allow us to embed select information > within another page. For example, suppose we had a critical security > issue in the webapp version of Forrest. We could drop a contract > indicating the current status of the bug fix onto our home page. > Another use case might be a "most popular" issues page in which we > display the top five issues with respect to votes and invite people to > visit the issue tracker to add their own votes to key issues. > > Looking further forward it might be interesting to expose the Baetle > data as a JSON file. This will allow us to use tools such as Exhibit > to provide the "Bug Dashboard" you describe. As it happens, I recently > committed some code to the DOAP plugin that does this with our DOAP > catalogue data. This could almost certainly be leveraged in your work > if you want to give it a go. > > I'm sure you have some use case ideas as well, you can bring in any > idea you like. > > So, I'd suggest working along the following lines, don't feel > constrained by this though, feel free to jump into whatever interests > you, or to modify this with any other ideas that might come from the > communty: > > - learn the dispatcher (probably by making your SKOS plugin dispatcher aware) > - create a basic Baetle plugin that can produce our "top 25 issues" page > - create a dispatcher contract that does our "top 25 issues" content > - extend the dispatcher contract to allow it to be customised (top 5 > issues, displayed data etc.) > - samples, samples, samples > - produce JSON > - embed Exhibit > > This sounds like a really cool plugin and is the one I was really > looking forward to seeing. > > Ross >
