7 Jan
2006
7 Jan
'06
10:22 p.m.
Not too long ago (yesterday) I decided to re-check if Seaside had
progressed in its maturity. It seems to done so. However, I was
somewhat amazed that there was no app that seemed to be a poster-
child for it's use. I shouldn't have been; it seems Smalltalk apps
are there, just more difficult to find that those in other
languages. Anyway.
So I asked on the Seaside list about apps that showcased it; I had
really expected there to be several in the vein of CMS, blog, web
forums, and WIKIs. As I am really wanting to switch from OpenCMS, I
had hoped...
So someone there recommended I look at Pier (as I'm sure most of the
people here also read that list, big surprise). I truly am
impressed. The sample out of the box looks amazingly good for a
WIKI. I tend to subscribe to the clea, non-clutered approach to web
apps. And just looking at the default app makes it seem Pier /
Seaside is just the ticket (as another wish item is to be able to
develop on the web, as I travel every week).
I've started looking at Pier's code, and unfortunately, I'd have to
say it's not the clearest. This may simply be because I've only been
looking at it for several hours over the last day. But the other
issue is the lack of documentation. 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. 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.
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? Documentation
on design and extensibility would be great, although I understand
those would not be of the same importance as to getting them written.
Lastly (for the moment anyway :-} ), I understand that Pier is a
relatively new app, and there is adequate warning that this is
experimental software, use at your own risk, not in production, etc.
Well, I'm looking for some stable. And able to be used in a
production environment. Does that mean I should stop looking at
Pier? Is there a timeline for when a stable, production quality
version will be available?
Please do not infer from anything here that this is a bitch e-mail.
I've not intended it as such. I just find Pier very promising, and
want to use it. I'm just tired of needing to switch products (like
JSPWiki, then OpenCMS, etc.) when I find that I've reached the limit
of what they can do, or in OpenCMS' case, where the source code is so
bad that there is no hope of me contributing to cleaning it up.
Thanks for your time (and hopefully answers).
8 Jan
8 Jan
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...")
11:48 a.m.
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. 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 hardest part is to tame Magritte, which is used to
describe a
structure. This feature is optional but gives more flexibilitiy.
We have written a (yet unpublished) paper about SmallWiki 2 and
Magritte, that is still valid for Pier and presents major concepts. I
can send it to anyone interested if you send me a private mail, as
far as I know we are unfortunately not allowed to put it online right
now.
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) 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. > 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?
You can enable the logging by evaluating
kernel persistency: PRFilePersistency new.
and then create a snapshot by (manually) sending:
kernel persistency snapshot.
You will end up having two files, 'snapshots.obj' with all the
snapshots and 'logs.obj' with all the logged changes of your
instance. There is no automatic way to restore the snapshots yet, but
there is a simple seaside interface called history to inspect and
reapply the commands.
> Well, I'm looking for some stable. And able
to be used in a
> production environment. Does that mean I should stop looking at
> Pier? Is there a timeline for when a stable, production quality
> version will be available?
No, there is no timeline: I need to finish my master at university, I
am writing papers and I also need to spend some time working for a
living, else Pier and everything else will just starve ;-)
Of course there is always the possibility to get commercial support
or to hire me to build or extend something specific:
Lukas Renggli
netstyle.ch GmbH, Terrassenweg 18, CH-3012 Bern
Phone: +41 31 356 42 56 Fax: +41 31 356 42 57
http://www.netstyle.ch mailto:info@netstyle.ch
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
2:34 p.m.
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.
That sounds very interesting? Is it proprietary or do you have an
URL so that other people could use your extensions as well? 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. 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)
That's not required, just load the package 'Pier' from SqueakMap and it will pull in all the requirements
automatically.
It would be a nice addition if Pier could start automatically the
http server if the KomHttpServer package was not previously installed.
4:38 p.m.
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.
That sounds very interesting? Is it proprietary or do you have an
URL so that other people could use your extensions as well? 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. I still have some troubles when I want to extend Pier
with complex
structures. For example, I have a structure to represent a project
with its history and its stakeholders. It requires a lot of
subcommands and subviews and it feels a bit clunky. I am not sure I
am making a good use of Magritte reports.
I imagine. We have to learn how the design scales.
Stef
9 Jan
9 Jan
11:52 a.m.
Hello :)
Seeing this post, this is the occasion for me to give my (raw)
impressions on many points. Probably you won't understand some as I have
not a very clear vision so just skip over them :)...
But It might help to understand newbee's problems...
Lukas is saying that the Report is
still experimental in his last
annoucment. I played a bit with...and I understand because it's a so
general and powerful component that it has to be done last I think
I find not handy the edit meta command at this stage (ok for me but
could be hard to get for a user...)...
Does Damien work on description from database tuple could be generalized
?... For instance, to make a dash-board report and the possibility to
modify tuple from Pier...
Connecting Pier with a database like that complicate my already limited
understanding... what is saved then with the persistency mechanism ? is
it compatible with database evolutions etc...
I think that's all for now... hope it's not too blur...
Cédrick
--
*/Cédrick/**/ Béler/*
E-mail: cbeler(a)enit.fr <mailto:cbeler@enit.fr>
This is good to know that people are making business with it. Indeed
if a group of people would find interest in
contributing actively this would be great. Lukas developed SW1 and SW2
and Pier with the idea of build a community around
these tools.
that would be great ! When I see Pier (with seaside), ma first and naïve
impression is that if we have there a killer-app for squeak..smalltalk &
co...
To me, the way to spread smalltalk is to access the companies world
(especially small and medium ones) and there is a big demand on
organisationnel tool (like groupware, web app).
I think a Pier version should be far more elegant and clean thant a php
one...
I may be totally wrong but I think that we (maybe including myself is a
bit premature) could develop a kind of mini-ERP in Pier/seaside... based
on component... for small companies...
If we can do that then no doubt that will a good smalltalk global
interest revival...
does it seem possible to you ? or naive ;)
>>>> I've started looking at Pier's code, and unfortunately, I'd
have
>>>> to say it's not the clearest.
>>>
>>>
If it was only Pier :)
the thing is I always struggle with understanding complex (because
modular) packages... Possibilities are huge but it's hard to know where
to start and the limits... maybe we should collect the bad practices
patterns :) to avoid people break the differents frameworks...
To me, what makes Pier hard to understand is probably Magritte and
seaside. To "fully" understand Pier I think one have to understand
Magritte first and it's hard not to blend all concepts (visitor in
magritte, visitor in pier, a renderer is a visitor for Pier, renderer in
Seaside...) - at least for me...
Also, and maybe worst, Seaside main concepts has to be known too...
I think maybe to introduce Pier, it would be good to have a seaside and
magritte overview first... what it is and what it is not...
>>
>> What could I do to make it clearer, despite the lack of missing
>> documentation? Would more method comments help? Are the existing
>> ones useful?
>
yes personnaly I like method comment... :). Especially in a framework I
like to have information on methods that should or should'nt be
modified... One of my problem is that I always change code in place
where I shouldn't...
I also agree that tests are a good doc... would it be possible to have
access to the tests when browsing a class ? maybe dynamically copy the
test code in the related tested class comment pane ?
I still don't understand well how MAMemento works (I know it's a kind of
proxy but I cannot see him while exploring objects except in some fatal
error due to bad manipulations...).
somethink also what should be good is the steps needed to add a new
magritte structure... (define the structure and the different
visitors.... I see that you (Lukas) create your defaults visitors with a
class method... is it something reproductible ?)
also MAgritte first reflex is to associate a description to each object
attributes that need beeing edited and viewed. But what's look very
powerful to is the dynamic construction of descriptions... but I just
have no idea on how to proceed (what I'm authorized to do and what I'm
not).
also, the PRCommand stuff is still not clear for me... the principle is
ok (command acting on a Pier Structure that get logged... important for
the prevalence persistency).
Like for adding a description in Magritte, I need examples or guidance
on steps to add a command, a widget (the tutorial of Damien were good
for that...)
Does the prevelence orientation makes traditionnal persistency
mechanisms (relationnal or object databases) irrelevant or complementary ?
I don't really see how it works together, I mean in a complementary
way... and as people are used to work with databases and always ask for
that...
Last Point I'm lost with PRQueryVisitor :)
and what are the binary visitor ? related to persistency ?
I still have
some troubles when I want to extend Pier with complex
structures. For example, I have a structure to represent a project
with its history and its stakeholders. It requires a lot of
subcommands and subviews and it feels a bit clunky. I am not sure I
am making a good use of Magritte reports.
1:32 p.m.
I may be totally wrong but I think that we (maybe
including myself
is a bit premature) could develop a kind of mini-ERP in Pier/
seaside... based on component... for small companies...
If we can do that then no doubt that will a good smalltalk global
interest revival...
does it seem possible to you ? or naive ;)
Sure, something like that should be possible. Give it a try :-)
To me, what makes Pier hard to understand is probably
Magritte and
seaside. To "fully" understand Pier I think one have to understand
Magritte first and it's hard not to blend all concepts (visitor in
magritte, visitor in pier, a renderer is a visitor for Pier,
renderer in Seaside...) - at least for me...
Also, and maybe worst, Seaside main concepts has to be known too...
I think maybe to introduce Pier, it would be good to have a seaside
and magritte overview first... what it is and what it is not...
Yes, it is a requirement to understand Seaside first. The basics of
Magritte (what are descriptions, how are they built and collected,
how is a ui built, ...) can be learned within a few minutes. To
extend and deeply understand it a lot more time is required of
course, after all it is a meta-framework ... something similar (but
simpler) to the object/class/meta-class thing in Smalltalk.
>> What
could I do to make it clearer, despite the lack of missing
>> documentation? Would more method comments help? Are the existing
>> ones useful?
yes personnaly I like method comment... :). Especially in a
framework I like to have information on methods that should or
should'nt be modified... One of my problem is that I always change
code in place where I shouldn't... I also agree that tests are a good doc... would it be
possible to
have access to the tests when browsing a class ? maybe dynamically
copy the test code in the related tested class comment pane ?
Most classes MAFoo have an associated test-class called MAFooTest.
For pier the pattern looks like PRBar has an associated test-class
PRBarTest. You might also browse the references of classes to
understand its use.
I still don't understand well how MAMemento works
(I know it's a
kind of proxy but I cannot see him while exploring objects except
in some fatal error due to bad manipulations...).
The mementos are used to cache the state of described objects while
they are being edited. So the editors work on the mementos instead of
the real objects to be able to 'cancel' edit operations. Since every
read and write access of Magritte is dispatched trough #readUsing:/
#write:using: (implemented in Object and some subclasses) we are able
to capture and delay read/writes to the model by using the mementos.
somethink also what should be good is the steps needed
to add a new
magritte structure... (define the structure and the different
visitors.... I see that you (Lukas) create your defaults visitors
with a class method... is it something reproductible ?)
Well, this class method was just used to create the initial
structure. I guess, that if you add a new structure class you also
add a new visit class at the same time. Yeah, this is certainly
something you might forget, but this is not doable in an clean
automatic way.
So when creating a new structure add the following code and
everything should work (it is not even necessary, when you don't want
to distinguish your visitors from their superclass).
NewStructure>>accept: aVisitor
aVisitor visitNewStructure: self.
PRVisitor>>visitNewStructure: anObject
self visitStructure: anObject.
also MAgritte first reflex is to associate a
description to each
object attributes that need beeing edited and viewed. But what's
look very powerful to is the dynamic construction of
descriptions... but I just have no idea on how to proceed (what I'm
authorized to do and what I'm not).
You are afraid to add new descriptions to existing classes trough
method-extensions? Go ahead, this is exactly made for that ;-)
Does the prevelence orientation makes traditionnal
persistency
mechanisms (relationnal or object databases) irrelevant or
complementary ?
You could use any of those with that prevalence persistency
mechanism. It is just a way of how the history is kept (by keeping a
log of all the commands). Right now I just use simple reference
streams, but anything else could work as well.
Last Point I'm lost with PRQueryVisitor :)
It is partly broken. Sorry. Browse its tests and other references.
and what are the binary visitor ? related to
persistency ?
Yes, this is part of Magritte to be able to serialize described objects.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
8 Jan
8 Jan
5:21 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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...")
Can Stephane or Lukas have a look at it ? If my documents are not
accessible anymore, it is not cool :-)
- --
Damien
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDwTv23hhx1vOEX5sRAt0/AJ99aJE5b6dDn7X53KcPHGpsoUKgbgCeOrnR
aPL+KNLDzlRbELuidPkr5Oo=
=mmU2
-----END PGP SIGNATURE-----
6:10 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I agree completely.
Sorry, this is a problem with the permissions, I will fix this monday
morning when I am at home with a more stable internet connection.
Lukas
- --
Lukas Renggli
http://www.lukas-renggli.ch
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...")
Can Stephane or Lukas have a look at it ? If my documents are not
accessible anymore, it is not cool :-) -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFDwUeEPSdrOS4Za5sRAl46AJ9EcS+WyO3W47tYQVGatoEPFvg9+QCfdht3
ImFcSvXpUfQDptc9E7BTnGo=
=WGNj
-----END PGP SIGNATURE-----
9 Jan
9 Jan
3:21 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I fixed it, sorry for the delay.
Lukas
- - --
Lukas Renggli
http://www.lukas-renggli.ch
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...")
Can Stephane or Lukas have a look at it ? If my documents are not
accessible anymore, it is not cool :-) - -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFDwnEEPSdrOS4Za5sRAg3HAJ93JBvOXpdlVciwRUq+R8tclf+iMACePDBy
9v0lVjUdBSkHztgp75S+xYM=
=pZEw
- -----END PGP SIGNATURE-----
-----BEGIN PGP
SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFDwnFuPSdrOS4Za5sRAj6iAJwKt6EVTXgiielxpzRp1iBZP/O1bQCfbGi+
a/PtvzeWP2qci0Rs7L/QY4c=
=ZW4M
-----END PGP SIGNATURE-----
8 Jan
8 Jan
4:20 p.m.
You can have a look at SmallWiki and there is a doc of SmallWiki one.
Part of the document model is the same as the one in pier. You can
read the paper http://www.iam.unibe.ch/~scg/cgi-bin/scgbib.cgi?
query=renggli to see the difference between
pier and SW1.
Stef
PS: if people using already pier wants to help for documentation,
this is welcome :)
On 7 janv. 06, at 22:22, Timothy Reaves wrote:
Not too long ago (yesterday) I decided to re-check if
Seaside had
progressed in its maturity. It seems to done so. However, I was
somewhat amazed that there was no app that seemed to be a poster-
child for it's use. I shouldn't have been; it seems Smalltalk apps
are there, just more difficult to find that those in other
languages. Anyway.
So I asked on the Seaside list about apps that showcased it; I had
really expected there to be several in the vein of CMS, blog, web
forums, and WIKIs. As I am really wanting to switch from OpenCMS,
I had hoped...
So someone there recommended I look at Pier (as I'm sure most of
the people here also read that list, big surprise). I truly am
impressed. The sample out of the box looks amazingly good for a
WIKI. I tend to subscribe to the clea, non-clutered approach to
web apps. And just looking at the default app makes it seem Pier /
Seaside is just the ticket (as another wish item is to be able to
develop on the web, as I travel every week).
I've started looking at Pier's code, and unfortunately, I'd have
to say it's not the clearest. This may simply be because I've only
been looking at it for several hours over the last day. But the
other issue is the lack of documentation. 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. 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.
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?
Documentation on design and extensibility would be great, although
I understand those would not be of the same importance as to
getting them written.
Lastly (for the moment anyway :-} ), I understand that Pier is a
relatively new app, and there is adequate warning that this is
experimental software, use at your own risk, not in production,
etc. Well, I'm looking for some stable. And able to be used in a
production environment. Does that mean I should stop looking at
Pier? Is there a timeline for when a stable, production quality
version will be available?
Please do not infer from anything here that this is a bitch e-
mail. I've not intended it as such. I just find Pier very
promising, and want to use it. I'm just tired of needing to switch
products (like JSPWiki, then OpenCMS, etc.) when I find that I've
reached the limit of what they can do, or in OpenCMS' case, where
the source code is so bad that there is no hope of me contributing
to cleaning it up.
Thanks for your time (and hopefully answers).
4:57 p.m.
Part of the document model is the same as the one in
pier. You can
read the paper http://www.iam.unibe.ch/~scg/cgi-bin/scgbib.cgi?
query=renggli to see the difference between
pier and SW1.
But Stef, the PDF link doesn't work and I guess we are not allowed to
publish the PDF yet, right?
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
6922
days inactive
6924
days old
11 comments
6 participants
participants (6)
-
Cédrick Béler -
Damien Cassou -
Dominique Dutoit -
Lukas Renggli -
stéphane ducasse -
Timothy Reaves