chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] rails-like framework


From: F. Wittenberger
Subject: Re: [Chicken-users] rails-like framework
Date: Sat, 22 Apr 2006 19:48:10 +0200

Am Samstag, den 22.04.2006, 10:08 -0700 schrieb Shawn Rutledge:
> > If anyone is interested: having a decent userfriendly Scheme CMS would
> > be *very* useful too :)
> 
> Yes as I mentioned, I wanted to build a wiki.  But lately I've been
> thinking that editing wiki-style text should just be one possible UI. 
> It's hard to say that the wiki syntax is a canonical way of storing
> web content when nobody can even agree on that syntax (Alejandro's,
> Felix's, MediaWiki etc. are all different).  So I want to build an
> object tree that represents a web page and store that, and dynamically
> generate a wiki-like editing UI.  Then an alternative UI could be a
> Javascript one where you have wordprocessor-style controls rather than
> having to use wiki syntax; and another would be a full GUI; etc.

OK, that's exactly the thinking behind the wiki style I included in
Askemos/BALL.  I'd never store syntax, which is hardly readable in 200
years.  It stores plain HTML (as parsed tree in the pstore module and
standard XML syntax in the file system) plus some XML for meta data,
lock handling etc.

You can edit HTML or wiki syntax.  For that to work, the XML tree is
serialised in wiki syntax from the template.  (
http://www.askemos.org/A849640f672ed0df0958abc0712110f3c/template?template=source
This might loose information and be vary of round trip problems.)  So
wiki syntax applies only on the UI.  Otherwise: the law, you know, XML
(see previous posting regarding german JComG).

BTW: I do have a pointer around here, were a nice JS editor could turn
our text fields into a browser based editor.  Yust nobody had the time
to care.

> I'm also thinking about how to do version control within the object
> system rather than having to rely on external things like subversion
> or whatever.

That's sort of a weak point of mine.  We have one level backup copies
right now.  It would be so easy to keep all versions.  But I'd rather
have an ((S)XML) tree diff run over the data.  With proper indentiation
this would be more effective on Scheme or XML as line-by-line diffs are.

So much for the dream.  But where's the code?  I don't have it.

> I may choose prometheus for the object system, but there are a couple
> things I don't like about it.  And then I have to tackle persistence. 

I don't know much, if anything at all, about prometheus.

But I know the persistence feature of RScheme.  (Frankly it has been
stressed hard by my own work.  And gotten much better in response.)  It
makes it so easy: anything reachable from a pivot object is persistent.
But it's waste for large objects.  Much better on reads than parsing xml
from files.  Writes depend on total size of the data base.  Can be long.
No problem if used asynchronously.

> I think I would like to just write something to a file that looks like
> an assoc tree, but can be parsed back into an object structure.  That
> could stand a chance of outliving the particular object system.

The other day I did somehting like that extending wt-tree from slib.
Now you can give an optional argument to make-wt-tree-type: an access
encapsulation for the actual objects.  Now you can read the objects from
memory (as before), file system, Askemos whatever you like.  Since
that's pretty new and under testing, it's not yet fed back to slib, but
only in askemos tar ball.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]