ANN: Iowa 0.9.1 Released

[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

 

[Michael Neumann]

Iowa 0.9.1 has hit Rubyforge.

Great!

I've again two questions.

1) Is it possible to use Iowa without sessions?

2) I'd like to create an Iowa session whenever the URL /comment/PageName
is invoked, where PageName is variable. I'd like to show all comments
for "PageName", and the user should be able to add his/her comments,
too. My question is, how to create the session with the specific
information ("PageName") filled in and then issue the request. Sure, for
this kind of application, session are not required at all, but they
probably are for Iowa.

Thanks in advance.

Regards,

Michael

 

[Kirk Haines]

On Thu, 19 Aug 2004 20:32:38 +0900, Michael Neumann wrote

1) Is it possible to use Iowa without sessions?

At the current time they are pretty much implicit, even if what one is
doing, like you describe below, isn't an application that uses sessioning.
There's very little performance penalty to the sessioning, though. It just
means that your session gets stuffed into a cache.

2) I'd like to create an Iowa session whenever the URL
/comment/PageName is invoked, where PageName is variable. I'd like
to show all comments for "PageName", and the user should be able to
add his/her comments, too. My question is, how to create the session
with the specific information ("PageName") filled in and then issue
the request. Sure, for this kind of application, session are not
required at all, but they probably are for Iowa.

First, let's make sure I am answering the right question. You want to
receive requests at /comment/FOO, where FOO can be anything. You want to
then invoke some component with the value of FOO passed to it so that it can
query the right set of comments to display, right?


Kirk

 

[Michael Neumann]

First, let's make sure I am answering the right question. You want to
receive requests at /comment/FOO, where FOO can be anything. You want to
then invoke some component with the value of FOO passed to it so that it can
query the right set of comments to display, right?

Exactly!

Regards,

Michael

 

[Kirk Haines]

On Fri, 20 Aug 2004 00:31:28 +0900, Michael Neumann wrote

Exactly!

Okay. In general, what you want to do is to setup a Main.iwa that is
something like this

class Main < Iowa::Component

def setup
comment_parameter = File.basename(session.context.request.request_uri)
dispatch_page = page_named('YourComponent')
dispatch_page.comment_parameter = comment_parameter
dispatch_context = Iowa::Context.new(session.context.request,
session.context.response)
dispatch_context.sessionID = session.context.sessionID
dispatch_context.requestID = session.requestCount
dispatch_page.handleResponse(dispatch_context)
session.currentPage = dispatch_page.dup
end
end


What this does is takes the request and pulls the last part off of the
path. It then creates an instance of the component that you actually want
to have handle the current request, and passes that last bit of the path
into a variable in that component. Then is passes the execution along.

This is actually a common enough activity in my code that I really should
provide a simple method for taking care of all of the exposed mechanics
above. I'll make that a part of the next release.

Give me a shout if I can help out further.

Thanks,

Kirk Haines