Re: BRL

[<br...@us...>]

"Nic Ferrier" <nfe...@ta...> writes:

> I notice that BRL is really just a Scheme CGI interface that happens
> to use Java servlets as the backend. Your efforts seem mainly to have
> gone into writing the support stuff (you've got some really good stuff
> there now!).

I want BRL to be something one could implement on top of any Scheme
implementation, not necessarily a Java-based one.  Only recently did I
put anything in the manual documenting how to do Java-specific things
with Kawa's make and invoke.

BRL's main purpose has been as a tool for me to make Intranet web
applications, so everytime I want to do something new, I wish for a
good support tool to help do it, and then grant my own wish in BRL.
But I need to do more documenting, especially re. SQL updates.

> The first thing that struck me is that you have no session support.
> HttpSessions are provided in (latest) servlet environments with
> cookies or with URL re-writing. Wouldn't it be usefull for a webpage
> author to be able to place a Scheme list on the servlet session and
> retrieve it next time?

I might add some "session" support, but won't recommend it, for three
reasons:

1. Apps that use "sessions" often break when a user hits the back button
   once or twice to change something, then tries to proceed.
2. Relational databases are more suitable for keeping server-side
   state.  Web servers were meant to be stateless.  E.g. If there's a
   pool of web servers, it shouldn't matter which one you get for any
   particular request.
3. If you avoid any particular systems "session" objects, you can mix
   PHP, BRL, JSP, ASP, etc., letting them freely interact.

For these reasons, I recommend keeping state in hidden form variables or
URL parameters, except when security or other considerations prevent
this, in which case state should be kept in a database.

> Or perhaps some other sort of object? Perhaps store a closure so that
> you could do sort of Scheme OO? I'm not sure how the user would
> collect "state" in that case but it should be possible.

It's easy enough to (define mystate 0) in sitedefs.scm and use set! to
change that global state to whatever object  you choose.  However, I
would probably want to use the servlet state object, as some servlet
engines might save/restore state with shutdowns, or synchronize state
among a group of servers.

> The other thing is that it might be easier with Scheme to do a sort
> of MVC architecture.

The Model-View-Controller architecture I use has an SQL database as the
model, BRL pages as the view, and any BRL page that's the action of a
form being a controller.

> The biggest problem I always have with MVC is that you have to have
> so many objects. With Scheme that's not necessarily true. You could
> define a func for handling the request and the page would deal with
> the response. The func could be embedded inside the page.

WebMacro deliberately does not allow functions in web pages to strictly
enforce MVC separation.  This might be a good idea for a huge project
with lots of Java programmers and non-programmers, but sometimes it is
indeed handy to just embed a function inside a page.  Also, who's to say
that functions are only useful in the model, and never in the view or
controller?  I think BRL scales down better for simple projects.

BRL: Because non-programmers shouldn't need to know Java, and neither
should programmers.  ;-)

> The last thing that occurs to me is that you don't seem to have any
> support for the lastet things in the servlet API, like contexts and so
> forth.

Yes, I've totally ignored servlet contexts, but you can always use
(brl-context-sv-req context) to get the servlet request object, then
invoke methods to your heart's content.

Is there some functionality of contexts that would be useful in a
non-Java implementation of BRL?  If so, I'd be happy to build an
abstraction around it.

> Anyway... I'm going to muck around with BRL a bit - see if I can get
> it do stuff (I particularly like the idea of using recursion to make
> webpages work).

With sql-repeat and brl-repeat, recursion is usually hidden, which helps
people stay out of infinite loops.  However, if I were teaching a
non-programmer to do a loop, recursion would be the easiest thing to
teach.  After all, the way you get a toddler into a loop is to tell
him/her over and over to do the same thing.

(define (clean-toys) (if (toy-left) (begin (put-away toy) (clean-toys))))

Too bad other programming languages have taught people to "think like
the computer", making recursion confusing for them.

> Do you mind if I redistribute BRL with GNU-Paperclips?

No special permission is needed unless you want to modify it and then
distribute under a non-GPL license.  See COPYING for details.

-- 
Bruce R. Lewis				http://brl.sourceforge.net/