a new version of Nitro is available. Here is the release info:
== Version 0.2.0 was released on 25/10/2004.
Greatly improved RDoc documentation. Cleaned up many source files, and
improved the directory structure to be more compatible with other Ruby
projects. Introduced a test suite. Important bug fixes in NDB. Tiny
example no longer requires apache so should run out of the box.
Some info about the project:
= Nitro
Nitro is an efficient, yet simple engine for developing professional
Web Applications using the Ruby language. Nitro aims to provide a
robust infrastructure for scalable web applications that can be
distributed over a server cluster. However, Nitro can also power simple
web applications for deployment on intranets or even personal
computers.
== Features
* XML server pages (.sx)
* Shaders, XSLT templates
* Multi phase evaluation (Experimental)
* Fragment Synthesis
* Object-Relational Mapping (integrates NDB)
* Distributed State
* Synchronous Server
* Request Filters
* Hierarchical Caching
* Support for 'nice' urls (Experimental)
* Advanced debuging features
* Parts
* UI Components
* Path overloading
* Localization
a new version of Nitro is available. Here is the release info:
I really like the ndb part; it would be great to roll some of that into
Rails' Active Record.
I hope you tried the new ndb example. I will try to do the oposite, roll
some cool features of Active Record into NDB. Stay tuned, a greatly improved version is coming soon. Btw new versions of NDB will be integrated with Nitro. After the API gets stabilized a new standalone version will be introduced.
For many other features of Nitro it seems Rails offers pretty good coverage
e.g. Rails' Builder approach vs. Nitro's xml+amrita template style.
Well of course Rails introduced many good ideas but there are some things I dont like: for example the way Rail forces the application design to the developer. Nitro has a different focus. Nitro aims to
be a framework for SCALABLE applications with many concurrent users online. Wherever possible we will try to optimize the rendering pipeline
as much as posible and alway select the scalable way to implement features. We 'll also try to give the developer choice. However many
features of Rails, like scaffolding and controllers will be implemented
soon.
Btw the Builder aproach is something like Amrita and has nothing
to do with Nitro .sx pages. Nitro .sx pages are something like php or jsp but FULLY xml compliant so you can use tools like xmlint to automatically validate files, use XSLT to pretansform them, it is
compatible with syntax highliting in editors etc. This is something you cannot do with Erb pages used in Rails. Moreove, .sx pages are quite flexible and can be used like Amrita templates. I 'll include an example in a future version.
Btw Nitro, just like Rails is designed to be used in Real World,
practical applications. This is no academic research project, that
looks nice with examples. In fact this is a third generation of the
engine used to develop several high profile community sites in
Greece with tens of thousands of registered users. The current version was redesigned from scratch and the API may change a lot, so that explains the low version number.
"George Moschovitis" <gm@navel.gr> wrote in message
news:clkqat$1q5a$1@ulysses.noc.ntua.gr...
things I dont like: for example the way Rail forces the application
design to the developer.
How do you mean?
Nitro has a different focus. Nitro aims to
be a framework for SCALABLE applications with many concurrent users
online. Wherever possible we will try to optimize the rendering pipeline
as much as posible and alway select the scalable way to implement
features.
Do you mean Nitro prefers a pre-compile + cache approach over fully run-time
manipulation?
However many features of Rails, like scaffolding and controllers will be
implemented
soon.
That's great to hear.
Btw the Builder aproach is something like Amrita and has nothing
to do with Nitro .sx pages. Nitro .sx pages are something like php or
jsp but FULLY xml compliant so you can use tools like xmlint to
automatically validate files,
use XSLT to pretansform them,
Or RexML on the .sx page, to continue working in Ruby?
it is
compatible with syntax highliting in editors etc.
things I dont like: for example the way Rail forces the application
design to the developer.
How do you mean?
for example forcing you to use model-view-controller.
or using the inflector to give names to variables.
or automatically populating your objects with methods...
Nitro has a different focus. Nitro aims to
be a framework for SCALABLE applications with many concurrent users
online. Wherever possible we will try to optimize the rendering pipeline
as much as posible and alway select the scalable way to implement
features.
Do you mean Nitro prefers a pre-compile + cache approach over fully run-time
manipulation?