K
Kirk Haines
Iowa 0.9.1 has hit Rubyforge.
If you don't know what Iowa is, in a nutshell, it is a framework for
developing web based applications and dynamic web sites. It takes an object
oriented approach, seperates code from layout while still allowing easy
access to the code from the layout, and runs on both Windows and *nix
platforms. Iowa processes run as discrete backend processes, and can be
used with Apache + a mod_ruby handler, WEBrick, or via FCGI or even CGI
interfaces. Iowa handles sessions for you automatically, on the server side
and lets the developer concentrate on simply writing code to make things
work. Since everything is an object, one just uses regular Ruby/object
paradigms to pass information from one part of the application to another,
and creating reusable components is easy.
New for 0.9.1:
* Inline content generation. i.e. an application can generate content like
images inline, getting a URL back from Iowa that, when accessed, will
display the generated content without ever requiring that the temporary
content (images or whatever) be written to a temporary file on disk and
without requiring one to explicitly setup a seperate service to generate
the temporary content. i.e. an art gallery application may store the
images within a database. When a page with art on it is being displayed,
the code for the page can simply query the image data from the database
along with the rest of the information on the piece of art. To insert a
queried image into the content, on the code side just create a method
that invokes resource_url() with the image information, and it will return
to your template a URL that will access the resource.
* Added a simplistic demo of the above to the webrick demo, and fixed
a couple very minor bugs in the webrick demo.
* Changed the Hash.downcase_keys to a better implementation.
* Improved WEBrick support. It is simpler to use, now.
* Bindings can now be placed in a seperate file from both code and layout.
To do this, create a file with the same name as the .iwa and .html files,
but with a .bnd suffix. When used in this way, the <? ?> blocks need
not be used, though they can be. Comment lines in bindings is also
now supported. A comment is any line where the first non-whitespace
character is a #.
* The LRUCache can now support age based expiration in addition to the
strict size based expiration mode. If the class variable @@cacheTTL is
set for either Application or Session, it will be applied to the session
cache or to the page cache, respectively. @@cacheTTL is the number of
seconds to allow something to exist in the cache. Items older than that
number of seconds will be expired. The hard limit on cache sizes
expressed by the @@cachedSessions and @@cachedPages variables will
still apply, as well. That way there is always a hard limit to protect
against unbounded cache growth. For example, if one set, for Application,
@@cacheTTL to 1800 and @@cachedSessions to 100, Iowa would allow up to
100 sessions that were under a half of an hour in age to exist in the
session cache. If anyone has any suggestions for other/different/better
cache handling, please let me know.
You can get it at Rubyforge: http://rubyforge.org/projects/iowa
Documentation is online at: http://enigo.com/projects/iowa
I have changed/added documentation to start covering some of the new
features. Please let me know if you have any questions, comments, or
suggestions.
Thanks,
Kirk Haines
If you don't know what Iowa is, in a nutshell, it is a framework for
developing web based applications and dynamic web sites. It takes an object
oriented approach, seperates code from layout while still allowing easy
access to the code from the layout, and runs on both Windows and *nix
platforms. Iowa processes run as discrete backend processes, and can be
used with Apache + a mod_ruby handler, WEBrick, or via FCGI or even CGI
interfaces. Iowa handles sessions for you automatically, on the server side
and lets the developer concentrate on simply writing code to make things
work. Since everything is an object, one just uses regular Ruby/object
paradigms to pass information from one part of the application to another,
and creating reusable components is easy.
New for 0.9.1:
* Inline content generation. i.e. an application can generate content like
images inline, getting a URL back from Iowa that, when accessed, will
display the generated content without ever requiring that the temporary
content (images or whatever) be written to a temporary file on disk and
without requiring one to explicitly setup a seperate service to generate
the temporary content. i.e. an art gallery application may store the
images within a database. When a page with art on it is being displayed,
the code for the page can simply query the image data from the database
along with the rest of the information on the piece of art. To insert a
queried image into the content, on the code side just create a method
that invokes resource_url() with the image information, and it will return
to your template a URL that will access the resource.
* Added a simplistic demo of the above to the webrick demo, and fixed
a couple very minor bugs in the webrick demo.
* Changed the Hash.downcase_keys to a better implementation.
* Improved WEBrick support. It is simpler to use, now.
* Bindings can now be placed in a seperate file from both code and layout.
To do this, create a file with the same name as the .iwa and .html files,
but with a .bnd suffix. When used in this way, the <? ?> blocks need
not be used, though they can be. Comment lines in bindings is also
now supported. A comment is any line where the first non-whitespace
character is a #.
* The LRUCache can now support age based expiration in addition to the
strict size based expiration mode. If the class variable @@cacheTTL is
set for either Application or Session, it will be applied to the session
cache or to the page cache, respectively. @@cacheTTL is the number of
seconds to allow something to exist in the cache. Items older than that
number of seconds will be expired. The hard limit on cache sizes
expressed by the @@cachedSessions and @@cachedPages variables will
still apply, as well. That way there is always a hard limit to protect
against unbounded cache growth. For example, if one set, for Application,
@@cacheTTL to 1800 and @@cachedSessions to 100, Iowa would allow up to
100 sessions that were under a half of an hour in age to exist in the
session cache. If anyone has any suggestions for other/different/better
cache handling, please let me know.
You can get it at Rubyforge: http://rubyforge.org/projects/iowa
Documentation is online at: http://enigo.com/projects/iowa
I have changed/added documentation to start covering some of the new
features. Please let me know if you have any questions, comments, or
suggestions.
Thanks,
Kirk Haines