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