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.
Chiliproject on Sinatra / Datamapper
Added by Lazaridis Ilias at 2011-05-24 01:34 pm
During the evaluation of ruby Web-Frameworks, I noticed the "Chiliproject".
I use currently "trac" (python based, customized with navigation bar/tree, pdf book creation and some more).
I like to move to a ruby based system before I start to implement my new collaboration system.
I saw "redmine", but it is based on RoR, so it is immediately "off-list" (main reason: non OO centric approach)
"Chiliproject" seems to prioritize community involvement/contributions.
Is there any chance that the "Chiliproject" is ported to the Sinatra/Datamapper Frameworks?
Something like "Chilliproject" 2.0- based on the Sinatra Web-Framework, which combines simplicity with the power of OO
- based on the DataMapper Data-Framework, which enable OO centric design.
- very simple extension due to overall Object Orientation
Replies (7)
RE: Chiliproject on Sinatra / Datamapper - Added by Holger Just at 2011-05-24 01:51 pm
ChiliProject is a fork of Redmine and as such also uses Rails. This is not going to change.
However, I'm interested in where your idea about Rails not being object oriented came from? In fact Rails (and ChiliProject) is written in an object oriented way throughout the whole stack. The MVC pattern, which is the core of Rails would be very hard to implement without applying OO principles. Also while Sinatra is nice, a port would lead to a re-implementation of many parts of Rails which is neither feasible nor reasonable.
I suspect you have a wrong idea of what Rails does and how it works. Maybe you got confused by the Ruby way which is sometimes largely different from the Java or Python way to do things.
RE: Chiliproject on Sinatra / Datamapper - Added by Konstantin Haase at 2011-05-24 01:52 pm
Hi Lazaridis Ilias,
Thank you for your interest in both Chiliproject and Sinatra. While I do understand that improving the overall code quality is wanted (by, among other things, embracing object oriented principles even further), I have to disagree about the OO argument when it comes to Sinatra vs. Rails. Having spend a lot of time in both code bases, I find that both are highly object oriented. Could you please elaborate further at what point Sinatra is more OO than Rails?
Rewriting Chiliproject from scratch could definitely improve it, both feature and performance wise, esp. since other choices, like using a document database rather than a relational one, could be made. However, Chiliproject has a large code base and a user base by far outnumbering its developers, so rewriting it from scratch might be totally out of scope. Simply no one has time for it.
And even if we would rewrite it from scratch, going fully Sinatra would not be a wise choice. A project the size of Chiliproject would need lot of boilerplate, and there is nothing wrong with Rails for a project the size of CP. Of course, if you would move to a more client-site application and only have a Ruby back-end serving say a JSON API, or would move to a multi-process web service structure, Sinatra would be a good fit. But I honestly don't see a need for that right now. Combining Rails with Sinatra in the future, like serving the Rest API with Sinatra (similar to what Github does) would of course be an option, but, unless you start contributing, this should be up to the developers, not the users of CP (there would not be a difference from the outside).
I would rather target Rails 3.1 for CP 2.0.
RE: Chiliproject on Sinatra / Datamapper - Added by Lazaridis Ilias at 2011-05-25 02:29 pm
I really don't want to go into detail why "Rails" does not offer this, 'cause this can lead to a large discussion - and sadly I have time constraints.
Possibly only this correction of my initial statement:
Sinatra enables - due to it's high flexibility - the implementation of an OO Centric Analysis & Design approach (e.g. in combination with DataMapper).
I understand that there is no possibility that Chiliproject goes "off Rails", so my basic question is answered.
Thank you for your quick response.
RE: Chiliproject on Sinatra / Datamapper - Added by Konstantin Haase at 2011-05-25 02:35 pm
I still would like to know what you meant by that. I agree that Sinatra is way more flexible than Rails, but that's also inherent to the things Sinatra is simply not dealing with and in Sinatra being more a library than a framework. But how is Sinatra + DataMapper more OO than say Rails + DataMapper, or even Rails + ActiveRecord? Both Rails and Sinatra strictly follow Smalltalk-style OO principles, both DataMapper and ActiveRecord follow the active record pattern, which is hightly OO, too. Maybe I'm not seeing it. It's a shame you don't have time to go into this further, since I, as the maintainer of Sinatra, am interested in understanding what you mean by your statements.
Konstantin
RE: Chiliproject on Sinatra / Datamapper - Added by Lazaridis Ilias at 2011-05-25 04:46 pm
I still would like to know what you meant by that. I agree that Sinatra is way more flexible than Rails, but that's also inherent to the things Sinatra is simply not dealing with and in Sinatra being more a library than a framework.
a) Sinatra and DataMapper can enable an OO centric Analysis and Design (OOAD). Of course, if you let the wrong people implement a framework on top of Sinatra/DataMapper, you'll get wrong results.
Both Rails and Sinatra strictly follow Smalltalk-style OO principles,
Only Smalltalk can follow Smalltalk.
Even if: following principles does not mean that you achieve a "full stack OOAD".
But how is Sinatra + DataMapper more OO than say Rails + DataMapper, or even Rails + ActiveRecord?
see a)
"Rails" has a legacy marriage to "ActiveRecord".
both DataMapper and ActiveRecord follow the active record pattern, which is hightly OO, too.
This is not correct.
And I prefer to rate from practical things, like the implementation(!) and usage(!) of the 2 libraries:
- DM is Model Centric (Abstracts underlying datastore, strict OOAD)
- AR is (Relational)Database Centric (and for sure not "highly OO").
Maybe I'm not seeing it.
Essence: "plumbing around" in relational tables (as a fundamental A&D) has nothing to do with OOAD.
It's a shame you don't have time to go into this further,
I am currently focused to find a commercial task and thus I try to keep public conversation to a minimum. When I am more "relaxed", I'll come possibly back to this.
since I, as the maintainer of Sinatra, am interested in understanding what you mean by your statements.
Ruby is an elegant dynamic(!) OO language. And Sinatra could become the flexible (and legacy free) library which enables real OOAD web-development on top of ruby.
There are some more libraries, but for now Sinatra looks that it's the one with the highest potential.
Hope I've clarified now what I meant.
RE: Chiliproject on Sinatra / Datamapper - Added by Konstantin Haase at 2011-05-27 10:10 am
Lazaridis Ilias wrote:
I still would like to know what you meant by that. I agree that Sinatra is way more flexible than Rails, but that's also inherent to the things Sinatra is simply not dealing with and in Sinatra being more a library than a framework.
a) Sinatra and DataMapper can enable an OO centric Analysis and Design (OOAD). Of course, if you let the wrong people implement a framework on top of Sinatra/DataMapper, you'll get wrong results.
Both Rails and Sinatra strictly follow Smalltalk-style OO principles,
Only Smalltalk can follow Smalltalk.
I think you did not understand my point.
Even if: following principles does not mean that you achieve a "full stack OOAD".
But how is Sinatra + DataMapper more OO than say Rails + DataMapper, or even Rails + ActiveRecord?
see a)
"Rails" has a legacy marriage to "ActiveRecord".
both DataMapper and ActiveRecord follow the active record pattern, which is hightly OO, too.
This is not correct.
It is. I recommend you read "Patterns of Enterprise Application Architecture" by Martin Fowler.
And I prefer to rate from practical things, like the implementation(!) and usage(!) of the 2 libraries:
- DM is Model Centric (Abstracts underlying datastore, strict OOAD)
- AR is (Relational)Database Centric (and for sure not "highly OO").
Yes, I understand this point. But that is just a real small aspect (basically where you define fields, and I like the DM approach more). It does however not influence the overall OO-ness of the system, only of one small aspect.
Maybe I'm not seeing it.
Essence: "plumbing around" in relational tables (as a fundamental A&D) has nothing to do with OOAD.
It's a shame you don't have time to go into this further,
I am currently focused to find a commercial task and thus I try to keep public conversation to a minimum. When I am more "relaxed", I'll come possibly back to this.
since I, as the maintainer of Sinatra, am interested in understanding what you mean by your statements.
Ruby is an elegant dynamic(!) OO language. And Sinatra could become the flexible (and legacy free) library which enables real OOAD web-development on top of ruby.
You seem to like buzz-wording around without actually saying anything.
There are some more libraries, but for now Sinatra looks that it's the one with the highest potential.
Hope I've clarified now what I meant.
No, not a bit.
Until proven otherwise, you sir have been marked as Troll.
Konstantin
RE: Chiliproject on Sinatra / Datamapper - Added by Lazaridis Ilias at 2011-05-28 03:57 am
Konstantin Haase wrote:
Lazaridis Ilias wrote:
[...]
a) Sinatra and DataMapper can enable an OO centric Analysis and Design (OOAD). Of course, if you let the wrong people implement a framework on top of Sinatra/DataMapper, you'll get wrong results.
[...]
Both Rails and Sinatra strictly follow Smalltalk-style OO principles,
Only Smalltalk can follow Smalltalk.
I think you did not understand my point.
You understood my point: keep Smalltalk out (the essence was/is in the next line)
Even if: following principles does not mean that you achieve a "full stack OOAD".
[...]
"Rails" has a legacy marriage to "ActiveRecord".
[...]
both DataMapper and ActiveRecord follow the active record pattern, which is hightly OO, too.
This is not correct.
It is. I recommend you read "Patterns of Enterprise Application Architecture" by Martin Fowler.
No need, the information in the next lines (reality) supersedes patterns/books (theory).
And I prefer to rate from practical things, like the implementation(!) and usage(!) of the 2 libraries:
- DM is Model Centric (Abstracts underlying datastore, strict OOAD)
- AR is (Relational)Database Centric (and for sure not "highly OO").
Yes, I understand this point.
Very nice.
But that is just a real small aspect (basically where you define fields, and I like the DM approach more). It does however not influence the overall OO-ness of the system, only of one small aspect.
So we disagree in the weight of this aspect.
- you say: "just a real small aspect"
- I say : it's the thin (but significant) detail which breaks the OOAD stack.
It's not "OOAD" when you have to start with relational tables and when you have to go back to relational tables again and again (e.g. when incrementally extending the application).
[...]
Essence: "plumbing around" in relational tables (as a fundamental A&D) has nothing to do with OOAD.
[...]
Ruby is an elegant dynamic(!) OO language. And Sinatra could become the flexible (and legacy free) library which enables real OOAD web-development on top of ruby.
You seem to like buzz-wording around without actually saying anything.
If you focus on the sum of words rather then on the words, you'll see the essence.
There are some more libraries, but for now Sinatra looks that it's the one with the highest potential.
Hope I've clarified now what I meant.
No, not a bit.
Until proven otherwise, you sir have been marked as Troll.
Your mind is strong, you don't need this attitude.
(1-7/7)