8 Jan
2006
8 Jan
'06
4:08 a.m.
no app that seemed to be a poster-child for it's
use.
It is maybe because Seaside doesn't try to solve popular problems
like database access and persistency but is all about reducing the
development cycle and focusing on the interaction flow. It just
happens that there is more interest into data-driven solutions than
flow-driven ones.
just more difficult to find that those in other
languages.
Fortunately, SqueakSource is getting popular and hosts many projects,
including applications running with Seaside and Pier. But since there
is no categorisation option on the website, they are a bit hard to
hunt down.
So someone there recommended I look at Pier
The concepts behind Pier are very close to the ones usually found in
content management systems and it can be extended to a full fledged
one just by adding new structure types.
To give an idea, I have extended Pier with structures for generating
diagrams with Graphviz and lists of items matching a query. I have
also developed Pier with visitor objects for outputting the content
of a Pier instance as a collection of static files.
to be able to develop on the web, as I travel every
week
That feature is already implemented in Seaside: click the Toggle
Halos link and then on the System Browser icon (first icon). All
classes and methods can be modified from there.
Since everything is stored into the image, you can bring it along
with you anywhere.
I've started looking at Pier's code, and
unfortunately, I'd have
to say it's not the clearest.
Yes, it is not very easy to understand how it works but on the other
hand it is quite easy to extend.
The basic idea is that for each structure type, there is a set of
commands and a bunch of visitors. Commands are used to apply actions
on structures. Visitors render the structures on screen.
The hardest part is to tame Magritte, which is used to describe a
structure. This feature is optional but gives more flexibilitiy.
Of course, this applies equally - if not more - to
Seaside. What
I'm looking for is documentation on at least getting up-and-running
with my own instance of the app.
Start with a fresh 3.8 basic image and with SqueakMap Package Loader,
install:
1. DynamicBindings (1.2)
2. KomServices (1.1.2)
3. KomHttpServer (7.0.3)
4. Seaside (2.5)
5. Magritte (1.0.6)
6. Pier (1.0.2-alpha)
Execute this command in a workspace:
WAKom startOn: 9090
The default install creates the mini-intro WIKI: am
I simply
supposed to remove all the content there and replace with my own?
That doesn't seem correct. At least, I'd be concerned about the
default classes/instances being over-written when I upgraded.
The default content is created on the fly by PRKernel>>root if the
kernel doesn't hold any item.
Continuing in that vain, documentation covering where
/ how my
data is stored / saved is critical. If I want a backup of my WIKI
at a point in time, do I just simply file-out, well, what?
Just save the image and that's it. It seems that some other modules
are in preparation to save the content outside the image.
Documentation on design and extensibility would be
great,
although I understand those would not be of the same importance as
to getting them written.
http://smallwiki.unibe.ch/smallwiki/smallwiki2/
Some documents are available there, but for some reasons, most are
inaccessible (got a message "You are not authorized to execute the
requested action on...")