Hi!

Chris Burkert <christian.burkert at s2000.tu-chemnitz.de> wrote:
> Hi Göran
> 
> thanks for this really big answer :-)

Yeah, it turned out to more than 2 cents...

> Just for understanding. I want to build this for creating Homepages. 
> Many people can work on this Homepage, but can only work on the part of 
> the tree, where they have the right. Think of a newspaper. The man from 
> the sports shouldn't change something in the finance section.

I know. I have both been involved in building a very large system for
newspaper production AND have built the "Homepage builder" tool (but in
that tool I haven't actually added access rights etc). 

Sidenote: HB is currently only in swedish but here is one site using it:
http://bwell.se

That is a site dynamically rendered through Comanche/HttpView. And it is
easily editable through the web. But it is not "page oriented".
Whatever, I can explain that if you are interested.

> There's a page at http://www.rsv-sehmatal.de/. It has static (plain 
> text) pages, and some dynamic stuff (guestbook, calendar, news, picture 
> gallery). All this should be possible.
> 
> There should be some corporate design, so that the sports section is 
> colored blue and the finance section red. Only the structure of the site 
> should be the same.

Right.

> All this works in my PHP-Implementation but it's fulsome to extend.

Ok! :-)

> goran.hultgren at bluefish.se wrote:
> > Hi Chris!
> > 
> > Just my 2 cents below. :-)
> 
> This is 10 Dollars or even more :-)
> 
> > Chris Burkert <christian.burkert at s2000.tu-chemnitz.de> wrote:
> > 
> >>Hi
> >>
> >>I plan to develop a kind of Swiki that is more what I want (nothing 
> >>against swiki, but it's not really the thing I want :-) I think the best 
> >>is with commanche.
> >>
> >>1) What would you say is the best starting point (It should be faster 
> >>than swiki)?
> >>- start from scratch
> >>- change the existing swiki
> >>- build with seaside
> > 
> > 
> > Do not try to change the existing ComSwiki. We have done a lot of
> > extensions to ComSwiki (sessions, better searching, smarter recent
> > changes that marks unread pages as bold yadda yadda) but the
> > architecture is a pain to work with. The authors tried to create a very
> > dynamic malleable system but I think it got a bit out of hand. But it
> > was probably explorative programming trying to see how stuff turned out
> > so they are excused! :-) Just don't go there.
> 
> This convinces me.
> 
> > Don't go "from scratch". Comanche is a very nice bottom layer and it is
> > "just a HTTP server" so you can't possibly go wrong with it, no point in
> > not using it. And you can always (as we have done on many occasions) put
> > Apache in front of it to get https, virtual hosts etc.
> 
> Just a misunderstanding. I want to use Comanche! (It's my english :-(

Ah. Goodie!

> > Seaside is cool - I haven't used it yet, but Avi/Julian are bright guys
> > and Seaside can do amazing stuff. You should look at it - at least to
> > learn some new interesting ways to build web apps.
> 
> The last time I took a look at seaside, it was just to much for me. But 
> I only heard good things about it. Avi, Julian, what are the classes I 
> hav to work with?
> 
> > If you are leaning towards some form of "embed code in HTML
> > templates"-solution then there are/have been a bunch of those, I would
> > guess a few are on SqueakMap. Personally I don't like those solutions.
> 
> I'm thinking of using Templates ... is there a little powerfull 
> templateclass like IT from PHP-Pear?

Well, there have been several template efforts - I just haven't used any
of them so...

> > And then of course we have my own little pet - HttpView. Think of it as
> > a much simpler (and thus also less fancy) Seaside. It isn't well
> > documented but on the other hand I have plenty of sample code and it is
> > very small.
> > 
> > Some of the cool aspects of HttpView is that it is *all Squeak* (no file
> > templates at all), urls map very easily and simply onto methods and web
> > pages are built using an HtmlBuilder. It also does very cool things with
> > Forms. (Seaside has similar mechanisms but IIRC doesn't have "nice
> > simple bookmarkable urls". But that is a consequence of having other
> > nice things.)
> 
> The problem is, that there are people working on this Homepage who don't 
> know what Squeak is. The simplest would be to offer a form where they 
> can put their template in. Squeak then uses this as it wants.

Ok, well - that argument is of course a good one for using templates. I
have been thinking hard about how to both be able to build using Squeak
AND let designers do their stuff. Don't have any good solution though.
Personally I just use HtmlBuilder to produce nice XHTML and then do most
looks through CSS - enough for me, and it keeps it all clean.

> > Compared to Seaside I think HttpView is:
> > - Much simpler (and thus less capable of the advanced stuff, on the
> > other hand HttpView doesn't tie your hands so that you can't do things
> > "your own way" when you want to.)
> > - Much smaller (let me count - 22 classes of which you only need to
> > learn 3. The other 19 are "internal")
> 
> What are these 3 classes?

HVModule
HVHttpView
HVHtmlBuilder

HVModule is the thing you instantiate once and register in Comanche. It
is a very small class, only has 4 oneliner methods and the method
#process: which Comanche likes. It is 6 lines long and sort of
kickstarts the url dispatching by creating the top view instance for the
model. HVModule holds a "model" and a "prefix". The prefix is used to
filter out if the url is meant for this module (so you can have multiple
apps running using different prefixes). The model is the top model
object for your system.

HVHttpView is the base class for the view instances that gets created.
Currently these are created on every request (initially I toyed with the
idea of keeping them around but have not yet needed to). A view has a
reference to a model and its methods correspond to the urls - so
"calling" an url is like "calling" a method in the view and each
"directory" in the url maps to a method in the views. So if you have an
url like "/myapp/account/settings/save" - "myapp" is the prefix for the
module, "account" is the #account method in the top view. It typically
finds the account instance based for the logged in person and creates a
view with the account as a model and then continues the dispatch by
calling the #settings method in THAT view. That method typically creates
a new view on the settings object and calls #save on that, etc.etc. In
this way each request creates a chain of HVHttpView (subclasses thereof)
instances that can use their "parent" reference if needed.

HVHtmlBuilder is the object that I use to create XHTML pages. It has a
very rich protocol with many different variants for especially Forms.
When used it builds an internal collection of objects representing the
webpage and in the end it renders this structure on a stream for
Comanche to return. Sortof DOM like. The cool thing is that it can
autoconnect the posts with the previous request that built the form so
that you get the "feeling" of widgets - as you saw in my sample. No ids
(they are all autogenerated by the builder) etc.

When I build an app with HttpView I typically create a subclass of
HVModule for my app - but it very seldom do anything than override
#initialize to use a different prefix. Then I create a base view class
which inherits from HVHttpView and which I use for all the generic stuff
that all my views in this app should share. Then I create my first view
class - the top view for the model - and make it inherit this base
class.

So my app consists of one dead trivial HVModule subclass and a bunch of
subclasses of HVHttpView (with a common base class) like this:

HVHttpView
	HVMyAppBaseView
		HVMyAppTopView
		HVAccountView
		HVWhateverView

Anyway, enough blabbering - I think you get the picture.

> > If HttpView sounds interesting I can dig up some sample code for you.
> > NOTE: The HttpView on SM is not up to date. I need to scramble together
> > my latest into a release.
> 
> This would be the greatest. Göran you _are_ great!

Darn, now I just added another thing to my todo list... :-) I will get
back on this, remind me - there is a lot going on here...

[SNIP] 
> > Simple. I just use a normal Form together with cookies. You can get
> > basic auth to work too - Jonas added that for our internal ComSwiki, but
> > who cares.
> 
> I've built my own login class in PHP. It works quite good. (logout after 
> idle time, logout after expired, some more things). I want to use the 
> same scheme for this.

Sounds like more or less what I do/have.

> >>- permissions (from user to admin)
> >>- permissions are bound to a user/page combination and are
> >>   inherited down the tree.
> >>- Squeakcode in <squeak> ^'Hello World!' </squeak>
> > 
> > 
> > Personally I would instead use some form of HtmlBuilder (like in
> > HttpView or Seaside). Cleaner. And yeah, btw - I do have a Swiki syntax
> > single class that transforms the Swiki syntax (a bit extended) into
> > HTML. It is a very simple to use reimplementation of the syntax in
> > ComSwiki - I use it in another project called "Homepage Builder". You
> > don't want to try to extract that code from ComSwiki...
> 
> I think it would be better to forget about the Swiki systanx, or make it 
> a additional feature. But it would be nice if I could take a look.

It is very easy to use. Just create an instance and tell it to swikify a
text, like this:

formatter _ WBHtmlFormatter base: 'http:/yaddayadda/' model: aModel.
html _ formatter swikify: aText.

Hey, I even have a bunch of silly tests in that class, what do you
know... :-)

> > So in short - go with Comance + Seaside/HttpView and build it from
> > there. The Swiki syntax class you can get from me or Avi (he may have
> > improved it). I also have lots of other code around like an "upload
> > documents" facility etc.
> 
> I will ask for this, when the time is right :-) For now I will mainly 
> think of design.

Sure. It is easy to "plug in".

> > Btw, just to give you a little taste of HttpView, here is a little
> > "hello world" I just typed into one of my running webapps (I did
> > *nothing more* than to add the method seen below), you can see it in
> > action at:
> > 
> > http://hb.bluefish.se/hello
[SNIP of code]

> This looks great for using it for my danymic pages (guestbook, calendar, 
> news, picture gallery), so I can edit a page that looks like:
> 
> foo
> <squeak> printGuestbook </squeak>
> bar

Ah, right. Now I get what you mean. You want to give the end users the
ability to "plug in" stuff like the guest book. Sure, the Swiki syntax
class is easily extended to handle some simple scheme I think.

> > regards, Göran
> 
> Again ... thanks a lot for this long answer! It helps more than any 
> documentation. I think of putting together a page, which describes the 
> possibilitys for creating webapps in squeak. Just for an overview.

Yeah, I should document HttpView much better...

regards, Göran

PS. Btw, the Homepage Builder project I did also uses ImageSegments for
very easy persistence. It also offer the users a "test site" and a
"published site". And they can easily revert to an earlier snapshot of
the whole site.