[Q] CMS/Swiki development

Chris Burkert christian.burkert at s2000.tu-chemnitz.de
Wed Mar 5 20:49:56 UTC 2003


Göran, (and all the others interested in this discussion)

goran.hultgren at bluefish.se wrote:
[snip]
> 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.

So if I have commanche behind an apache this would be a distributor for 
different domains. For example this is used when apache maps
   http://www.my-domain-is-longer-than-your-domain.net/
to
   comanche:port/my-domain-is-longer-than-your-domain
and
   http://www.short-domain.net/
to
   comanche:port/short-domain
. Right?

> 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.

If I wanted to dynamically create and delete pages, I had to compile new 
methods, right?

It would be better for me to register these url-keywords in a dictionary 
which holds other pageobjects. So for example 'myapp' holds 'account', 
'foo' and 'bar'; 'account' holds 'settings' and 'settings' holds 'save'. 
myapp can give the request to the object at 'account', this can give it 
to settings and this to save. save answers and the answer goes back in 
the tree (this is like Morphic ?!?). Only save answers because there is 
nothing left in the url. If an url doesn't exist there is nil answered 
and myapp will raise an 404. (self subpages at: 'nonExistingPage' 
ifAbsent: []).

This way I didn't have to compile new methods.

> 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.

This is cool. I'll play with it.

[snip]
>>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.

I don't want to hassle you with PHP-Code, but if you want it, I can send 
it to you. 420 lines of code.

Or just wait. When I finish the first steps of my application it will be 
SqL and on SqueakMap :-)

[snip]

Some other thoughts:

Each page has the ability to save itself (to Magma, File, whatever).

There's also a kind of Scriptholder and each page can call Methods of 
that. So for example (<squeak> printGuestbook </squeak>) the page sends 
printGuestbook to this Scriptholder and that answers the correct output 
for this user with these rights. Examples for scripts are:
- printGuestbook
- printCalendar
- printSitemap

I also think of managing all through some kind of Session that holds 
information of the user, the current page and the current permission the 
user has on this page. This way the Scriptholder could answer depending 
on the Sessionobject (printing the forms for deleting entrys in the 
guestbook only when the user has the permission). This Object would be a 
new instance on every request (holds the GET and POST vars, the USER, 
PERMISSION and PAGE) and will be deleted after that, just a kind of 
transfered request. Safety ...

Corporate Design ... in my PHP-Version the user can only edit a little 
part of that page and some colors. So it shouldn't be to difficult to 
create a big template where a few keywords are replaced ({Content}, 
{Title}, {LastEdit}, {LastUpdateBy}, ...) and the page could answer a 
local stylesheet with /myapp/foo/bar.stylesheet

There could also be a page history by /myapp/foo/bar.1

This seems to be good. Or not? critism? ideas? Nice XP discussion :-)

Cheers
            Chris Burkert
-- 
------------------------------------------------------------------------
Student of applied Computer Science at Chemnitz University of Technology
      http://www.chrisburkert.de/            chris at chrisburkert.de
------------------------------------------------------------------------
"I invented the term Object-Oriented, and I can tell you I did not have
  C++ in mind." - Alan Kay --> http://www.whysmalltalk.com/



More information about the Squeak-dev mailing list