It now has been 2 years since Oxyliquit first breathed the air.

Oxyliquit has been the idea of a community platform, however - the diminishing positive response in large attributable to the withering of Nitro and Og support in general leaves me with one laughing and one crying eye.

As this is a completely community driven application, it lives and dies with its community.

That said, I still think Oxyliquit is a good source for Nitro, so it will stay as long as there are still interested people browsing through it, it might however reopen in a slightly different form.

The Nitro concept of elements is terribly flexible. Whatever you put inside the elements tag is available through the content method. You could for instance parse this as YAML and take it as configuration for how the element should render.

variant: big background: #3f7 no-footer: true

I'm assuming you've installed Lighttpd with the package manager of your distribution of choice. Next you need to enable the fastcgi module.

If you're using Debian or a variant (like Ubuntu) you can use the lighty-enable-mod script:

lighty-enable-mod fastcgi

This will create a symlink from /etc/lighttpd/conf-available/10-fastcgi.conf to /etc/lighttpd/conf-enabled/10-fastcgi.conf. Open this file in your editor. If this doesn't work for you simply edit the main configuration file /etc/lighttpd/lighttpd.conf.

To enable the module you need this line:

server.modules = ( "mod_fastcgi" )

If you find any fastcgi.server portions in the configuration comment them out, we won't be needing them. Now add a fresh portion: fastcgi.server = ("" => (( "bin-path" => "/path/to/app.rb", "socket" => "/tmp/nitro.socket", "check-local" => "disable", "max-procs" => 1, "bin-environment" => ("RUBYOPT" => "-rubygems -I/path/nitro_repo/script -rlib/glycerin") )) )

Issue

sudo /etc/init.d/lighttpd force-reload

and you should be all set. Keep an eye on /var/log/lighttpd/error.log in case stuff doesn't work right.

h2. Configuration

# # Using Apache 2.0 and 2.2 as a reverse proxy # for a Nitro application. # # Note that Apache 2.2 offers a load balancing # proxy. Oxyliquit tutorial forthcoming... # # This scheme is based on Apache's NameVirtualHost # feature. The following line should appear # in your httpd.conf file: # # NameVirtualHost *:80 # # Next, add the following. # # You *could* put this directly in httpd.conf. # # But with large numbers of virtual hosts, # it makes sense to have an include directory # under your_apache_install/conf and add this # to httpd.conf: # # Include conf/vhosts/* # # or # # Include conf/vhosts/foo.com # Include conf/vhosts/bar.com #

By default cookie session store is used in Nitro pre-0.50

The line in application.rb that does this is

@session_store ||= Raw::CookieSessionStore.new

In my app setup I tried this:

require 'raw/context/session/memory'

app.session_store = Raw::MemorySessionStore.new

The problem with that is the 'require' looks like it digs a little deeper into the Raw framework than it should. Shouldn't there be a simpler way to do this?

The head of this side is going for a vacation for a week, and I use the brief time before that to make a little more news:

• Nitro 0.49 (beta release before 0.50) will be coming out after Facets 2.0
• That release will have many Nitro improvements as well as a much better testing structure due to RSpec.

I thank the many visitors of this page, which despite the site not having recieved much content in the last few decades keep coming back. I bow before the community, thanks to you I'm alive.

So, if you are one of those coming back often (you know who you are) looking for content: if you have an idea what that content should be, why don't you just ask for it? :) (me don't bite. promis. will work for food!)

I need to stay backwards-compatible to ActiveRecord..

How can I use 'id' instead of 'oid' in MySQL Tables created by Og?

What other gotcha's do I need to be aware of?

thanks

LoxAuth

LoxAuth is a dropin solution for basic authentication for Nitro apps. Can be used to login your users as well as registering them. It's customizable by settings if you need registering for example, since this is deactivated by default.

Copyright (c) 2006 Fabian Buch under MIT license. See LICENSE file for details.

Requirements

• Nitro 0.40.0
• Og 0.40.0

May work with other versions with small adjustments

USAGE:

in your run.rb:

require 'part/auth' Nitro::Server.map['/auth'] = AuthController

before your controllers and models!

in your Controller

class MainController [:edit, :add] # This action is now protected. When someone tries to # go to /edit while not being logged in, he will be # redirected to a login screen and after having logged # in he will be redirected to `edit` again. # The same happens with `add` and any other protected # action. def edit(id) # do something end end

Part Auth has its own User model, if it's not sufficient for you, just extend it by monkey patching. Currently the User has the properties :name, :email and :password, so if you need it to have an additional age do the following in your own User model:

class User property :age, Integer end

Same goes for relations:

class User has_many :articles, Article end

If your application defines a Page skin class (Element) it'll integrate nicely into your Page design.

Configuration

To enable Registering:

LoxAuthPart.register_enabled = true LoxAuthPart.register_welcome_msg = "Successfully registered. You're logged in now!"

To disable Roles:

LoxAuthPart.roles_enabled = false

Adapting LoxAuth

Apart from adding additional properties to User or Role you can also modify how it looks.

Copy the xhtml templates from the LoxAuth template folder to auth/ (subfolder of your template folder, standard is template, modifyable by the setting Nitro::Template.root = 'template').

Having the .xhtml now in yout template/auth folder, you can modify them just like all your other templates.

Contributors

In other systems you'd maybe call them Plug-ins, but in Nitro they are called "parts". These parts can be dropped into your Nitro Web-Application and extend your Application with fully functional app parts. You could for example add a Blog to your current Application by adding a Blog Part.

This guideline will show you how to make a Nitro Part at a kinda general example. It uses "partname" or PartName as the name of your Part, so you'd typically replace that with the actual name of your Part.

Directory Layout

The directory layout of a typical Nitro Part looks as follows.

part/partname.rb part/partname/ part/partname/controller/ part/partname/helper/ part/partname/model/ part/partname/public/ part/partname/template/

Helper, model and public directory are optional of course, if your Part doesn't need them.

It's recommended to use this layout for all parts, even if Nitro's layouts can be done in any way the developer chooses, it'll be easier to integrate your part in other applications, especially utilizing "gen part".

partname.rb

This is the main file of your part, kinda the equivalent of the run.rb of typical Nitro apps. Parts usually don't have a run.rb.

Require everything your part needs in here. Try to avoid requireing in other files (like your models and controllers). Take into account that a part will be required as follows in a random app:

require 'part/partname'

So requireing controllers, models of your part in your partname.rb:

require 'part/partname/helper/something' require 'part/partname/model/user' require 'part/partname/model/article' require 'part/partname/controller/main'

Additionally this file is for a standard Nitro::Server.map, even though this will probably be overridden by a Nitro app.

PartnamePart class

Usually directly in partname.rb too, there can be a PartnamePart class, which you can use for various settings you can use later on in your Part. Thistime my example is of a BlogPart:

class PartnamePart setting :title, :default => "Lox Blog" setting :subtitle, :default => "My life with Lox" setting :entries_per_page, :default => 10 setting :trackback, :default => false # Trackback can lead to lots of spam setting :tags, :default => true setting :categories, :default => true setting :version, :default => '0.9.0' setting :public_root, :default => '/part/partname' setting :charset, :default => 'utf-8' end

All these settings are optional of course. But if you incorporate stylesheets or pictures in your Part, using the public/ directory, you should probably set "setting :publicroot" to '/part/partname', since that's the directory "gen part" is creating for you in a random Nitro app, so you can use "PartnamePart.publicroot" for links and such in your Part.

Controller

Every controller of a Part should have the following method, so that the right templates are found:

def self.setup_template_root(path) super @template_root