From: "Guy N. Hurst" <gnhurst@...>
Date: 2002-02-23T04:12:57+09:00
Subject: Re: Ruby for web development

Thomas Hurst wrote:
> 
> * Guy N. Hurst (gnhurst@hurstlinks.com) wrote:
> 
> > Thomas Hurst wrote:
> > > Currently what I'm after is a framework which includes stuff like
> > > version control and hierachial documents, a bit like rwiki, only
> > > without all the wiki cruft beside it and with a nice clean API I can
> > > interface with.
> >
> > I have been slowly working on something like this - but I wonder what
> > you mean when you say hierarchical documents... What sort of websites
> > do you develop?
> 
> Hierachial, as in a collection of documents like:
> 
> 1. Index
> 2. Code
>    a. Ruby
>         1. Tutorials
>         2. Projects
>    b. PHP
>         ..
>    c. Regex
>         ..
> 3. Rants
>    ..
> 4. Misc
>    ..
> 

Ok, I see what you mean by hierarchical documents. Reminds me a Tree
class I am working on that stores hierarchies of folders and their
content.

> Even better, I want to be able to collect Tutorials and Projects from
> different areas together into a metacategory, rename documents and have
> the change versioned, have 404's caught and version and spellchecked,
> and have it all done through a static URI namespace that is solid and
> clean.
> 

Sounds like the ability to move them into a new folder, which is 
something I will be including. I don't plan to implement spell check,
though. Catching 404's is a good idea, but I think that is part of
the site functionality, not the framework.

So your desired API is the use of "a static URI namespace" ?
Does that exclude the use of query strings and/or session cookies?

> Then editing can be opened up and there's the tracking of changes, who
> changed what, branches (published/wip) so documents being edited aren't
> necessarily live, and embedding dynamic content like weblogs and ToC's..
> :)
> 

Ok, I see a similarity to a wiki/weblog in what you are looking for.
I have been thinking about how to best manage keeping track of who
does what, and what they are allowed to do. I took another look at
Zope yesterday to refresh my memory on how they use roles/permissions.

You actually would probably like how Zope does things. I like their
model, but not the implementation (and some related things).



What I am working on will be something to help developers who have
to manage a lot of sites themselves, or for those who do so little
that they can't bother with telnet/ftp/editor programs. 

Another purpose is to be able to manage reusable web scripts for
freelance work. (It could even grow into something where you pull
in code from repositories elsewhere on the web and install it
into a temp section from where it gets integrated into the site.)

It will be like a seed that you plant to grow a site, and help you
to easily transplant/store versions of it. It will eventually have a 
hierarchical undo to revert to prior versions of files, or of snapshots 
of the site. If you revert to a prior version and continue developing from 
that, it will automatically branch, and you can always go back to any point 
of prior work. (Of course, in some cases this can lead to huge archives, 
but that is a lesser problem...). It will also allow for exports of the 
same, for backup and migration purposes. 


This framework/editor is web-based and is itself able to be modified by 
itself, so you can enhance it on the fly. There are built-in recovery 
options to help you in case you make a change that breaks itself. No help
is available if you modify the recovery portion, though ;-)

Think web-based smalltalk. Although it is independent of Ruby, it
wasn't until ruby came along that I was able to think about something
like this and believe it could work and be easily done. 
I am writing it in ruby, but it can be made with any other language. 
It is really a CGI thing. I intend to make a perl version of it 
eventually, for those who don't have access to ruby on their server. 
This will be able to work with any files (Ruby, PHP, Perl, HTML, etc). 

I have an abstract system of handling templated files which I will 
use this for. I also made a template engine to go with it. I actually
started on this a year ago, and only in the past week have I gotten
back to working on it. (Once again inspired by the need while doing
some subcontract work). 

It is meant for the developer only. But with it, I will make scripts that 
allow the client to manage content on their site. The neat thing is that
once the site is done, you can pack up the framework and remove it from
the site.


Guy N. Hurst