ChiliProject is not maintained anymore. Please be advised that there will be no more updates.
We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.
Updated by Holger Just at 2012-07-11 02:31 pm
Once we have full liquid support (see #604) it is desirable to have access to about all objects from within the language with issues being the most important object type here.
I started working on an extension which utilizes a simple "treetop":http://treetop.rubyforge.org/ grammar to parse a DSL for filter specification and to subsequently create the issues and make them available to the user.
The syntax currently looks like this:
<pre>{%raw%} <pre>
{% query my_query %}
status o
author_id = 1
{% endquery %}
|_. ID |_. Subject |_. Status |
{% for issue in my_query.issues %}
| {{issue.id}} | {{issue.subject}} | {{issue.status.name}} |
{% endfor %}
You have {{my_query.count}} open issues.
{%endraw%}</pre> </pre>
This generates the following example output:
---
|_. ID |_. Subject |_. Status |
| 1 | This is an issue | New |
| 2 | A second issue | New |
You have 2 open issues.
---
What is missing yet is full support for all attributes and more user-friendly input as it currently relies on the filter representation inside the query class which sometimes is not obvious.
Also missing are facilities for sorting and a performant way of slicing (i.e. without first instantiating all previous issues).
I started working on an extension which utilizes a simple "treetop":http://treetop.rubyforge.org/ grammar to parse a DSL for filter specification and to subsequently create the issues and make them available to the user.
The syntax currently looks like this:
<pre>{%raw%} <pre>
{% query my_query %}
status o
author_id = 1
{% endquery %}
|_. ID |_. Subject |_. Status |
{% for issue in my_query.issues %}
| {{issue.id}} | {{issue.subject}} | {{issue.status.name}} |
{% endfor %}
You have {{my_query.count}} open issues.
{%endraw%}</pre> </pre>
This generates the following example output:
---
|_. ID |_. Subject |_. Status |
| 1 | This is an issue | New |
| 2 | A second issue | New |
You have 2 open issues.
---
What is missing yet is full support for all attributes and more user-friendly input as it currently relies on the filter representation inside the query class which sometimes is not obvious.
Also missing are facilities for sorting and a performant way of slicing (i.e. without first instantiating all previous issues).