From renggli at gmail.com Sat Jan 7 11:24:04 2006 From: renggli at gmail.com (Lukas Renggli) Date: Sat, 7 Jan 2006 11:24:04 +0100 Subject: [Seaside] Pier question In-Reply-To: <978BF558-AD78-4B6D-8F79-60E0949EA6A0@silverfieldstech.com> References: <978BF558-AD78-4B6D-8F79-60E0949EA6A0@silverfieldstech.com> Message-ID: <67628d690601070224p39923edbv7531671db39b438f@mail.gmail.com> > I realize that this is not a Seaside question directly, but I'm > interested in using Peir with Seaside. Problem is, I find no docs on > Pier, nor a website. Am I simply overlooking it? Pier was formerly called "SmallWiki 2", so you might find some information if you are looking for that. The following documentation is currently available: * I am about to setup a new website for Pier on my server (running with Pier), for now you can find some information at http://smallwiki.unibe.ch/smallwiki/smallwiki2/ (maintained by Damien Cassou, thanks). * There is a mailing-list about Magritte and Pier at http://www.iam.unibe.ch/cgi-bin/majordomo called smallwiki at iam.unibe.ch. An archive is available at http://impara.de/pipermail/smallwiki/. * There is also a about SmallWiki 2 (Pier), giving some more details. Right now there is no download, because it hasn't been published yet, but there will be probably soon and I can send it to anyone interested. * Yeah, from time to time I even some class comments ;-) Later today I will publish a new version with many fixes on SqueakMap. Stay tuned. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From renggli at gmail.com Sat Jan 7 18:25:57 2006 From: renggli at gmail.com (Lukas Renggli) Date: Sat, 7 Jan 2006 18:25:57 +0100 Subject: [ANN][PR][MA] New Releases on SqueakMap Message-ID: <67628d690601070925j3c9f9c09kab04d1cdef2f179c@mail.gmail.com> I published the latest code of Magritte and Pier on SqueakMap: * Magritte: Not many changes, but a few bug-fixes and small improvements. The reporting part is still experimental and incomplete, so don't complain about that ;-) * Pier: A lot of minor changes, fixes, improvements and a couple of new hooks to ensure easier extensibility without the use of overrides. Pier works with the latest version of Seaside and fully supports bookmark-able URLs on all its links. When updating an existing instance, take care that I changed the names of PRSeasideFrame, PRSeasideMain, PRSeasideConfiguration to PRPierFrame, PRPierMain, PRPierConfiguration; this might require that you re-register your kernel as a Seaside application. * Pier Unix Security: A new experimental package providing a simple unix like security system, using no overrides and being fully integrated (thanks to Magritte) into all currently available views (Seaside, Pier). When loading this package all the prerequisites such as Magritte and Pier and Seaside (if requested) will be automatically loaded. The default user name/password is admin/pier. To add/change user/groups it is required to directly use the image. Have fun, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From treaves at silverfieldstech.com Sat Jan 7 22:22:08 2006 From: treaves at silverfieldstech.com (Timothy Reaves) Date: Sat, 7 Jan 2006 16:22:08 -0500 Subject: New user questions Message-ID: <4F0CA1C3-A25C-4F70-ACF1-CAA6246FDDDE@silverfieldstech.com> 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). From dominiqued at versateladsl.be Sun Jan 8 04:08:48 2006 From: dominiqued at versateladsl.be (Dominique Dutoit) Date: Sun, 8 Jan 2006 04:08:48 +0100 Subject: New user questions In-Reply-To: <4F0CA1C3-A25C-4F70-ACF1-CAA6246FDDDE@silverfieldstech.com> References: <4F0CA1C3-A25C-4F70-ACF1-CAA6246FDDDE@silverfieldstech.com> Message-ID: > 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...") From renggli at iam.unibe.ch Sun Jan 8 11:48:26 2006 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Sun, 8 Jan 2006 11:48:26 +0100 Subject: New user questions In-Reply-To: References: <4F0CA1C3-A25C-4F70-ACF1-CAA6246FDDDE@silverfieldstech.com> Message-ID: >> 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. The SqueakSource on mc.lukas-renggli.ch is hosting the latest Pier and Magritte related projects. There are many others available on www.squeaksource.com, but I guess they are mostly not maintained anymore since they started from an university course about software design. >> 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. 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. What could I do to make it clearer, despite the lack of missing documentation? Would more method comments help? Are the existing ones useful? It is a bit hard for me to see where people are running into troubles understanding the system; I have been working (mostly on my own) on SmallWiki 1, SmallWiki 2, Pier and all its reincarnations for more than 3 years now. > 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) That's not required, just load the package 'Pier' from SqueakMap and it will pull in all the requirements automatically. It will also ask if you want to install Seaside, so you should probably answer 'yes' to this question. If you have OmniBrowser installed, it will also install a small package allowing you to conveniently browse and edit your pier instance using the Squeak image. >> 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. Upgrading Pier should be simple, the model isn't changing much anymore and there are always ways to fix possible problems in Smalltalk. All you Pier kernels are kept in a collection on the class- side of PRKernel and they are never overridden. As an example SmallWiki 1 (the predecessor of Pier) running on smallwiki.unibe.ch has been running for almost 3 years now, it has been regularly updated from an unfinished testing version to the most recent version of SmallWiki 1. This will be also possible with Pier. >> 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. Yeah, there is something included that loggs all the commands using reference streams. Have a look at PRPersistency and its subclasses. This works very well for my tests, but there is more testing required. Saving the image is always a good and easy solution. >> 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 at netstyle.ch Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From dominiqued at versateladsl.be Sun Jan 8 14:34:36 2006 From: dominiqued at versateladsl.be (Dominique Dutoit) Date: Sun, 8 Jan 2006 14:34:36 +0100 Subject: New user questions In-Reply-To: References: <4F0CA1C3-A25C-4F70-ACF1-CAA6246FDDDE@silverfieldstech.com> Message-ID: <19E8A1B2-8C4D-4A25-8C63-9C442350E13D@versateladsl.be> >> 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? It is proprietary for now but I will try to publish portions of this code in the future. >>> 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. > > What could I do to make it clearer, despite the lack of missing > documentation? Would more method comments help? Are the existing > ones useful? I think that the hardest part was to understand the architecture until I figured out that the key was to learn the design patterns used by Pier. I am still impressed by its flexibility and how it nicely complements Seaside without standing in the way. I have written an architecture document but I can't publish it. Maybe I will extract some drawings and put them somewhere. 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. >> 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 Yes, this method works but then SqueakMap doesn't update its list of loaded packages. It seems that the problem lies in its way it manages the dependencies of dependencies. > 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. From ducasse at iam.unibe.ch Sun Jan 8 16:20:38 2006 From: ducasse at iam.unibe.ch (=?ISO-8859-1?Q?st=E9phane_ducasse?=) Date: Sun, 8 Jan 2006 16:20:38 +0100 Subject: New user questions In-Reply-To: <4F0CA1C3-A25C-4F70-ACF1-CAA6246FDDDE@silverfieldstech.com> References: <4F0CA1C3-A25C-4F70-ACF1-CAA6246FDDDE@silverfieldstech.com> Message-ID: <5A5A07E7-8AED-47AC-B9CD-D588987AC3EB@iam.unibe.ch> 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). > > From ducasse at iam.unibe.ch Sun Jan 8 16:38:57 2006 From: ducasse at iam.unibe.ch (=?ISO-8859-1?Q?st=E9phane_ducasse?=) Date: Sun, 8 Jan 2006 16:38:57 +0100 Subject: New user questions In-Reply-To: <19E8A1B2-8C4D-4A25-8C63-9C442350E13D@versateladsl.be> References: <4F0CA1C3-A25C-4F70-ACF1-CAA6246FDDDE@silverfieldstech.com> <19E8A1B2-8C4D-4A25-8C63-9C442350E13D@versateladsl.be> Message-ID: >>> 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? > > It is proprietary for now but I will try to publish portions of > this code in the future. 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. >>>> 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. >> >> What could I do to make it clearer, despite the lack of missing >> documentation? Would more method comments help? Are the existing >> ones useful? > > I think that the hardest part was to understand the architecture > until I figured out that the key was to learn the design patterns > used by Pier. I am still impressed by its flexibility and how it > nicely complements Seaside without standing in the way. > > I have written an architecture document but I can't publish it. > Maybe I will extract some drawings and put them somewhere. Please, this would be interesting for us to know what we should focus on and document. > 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 From renggli at iam.unibe.ch Sun Jan 8 16:57:16 2006 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Sun, 8 Jan 2006 16:57:16 +0100 Subject: New user questions In-Reply-To: <5A5A07E7-8AED-47AC-B9CD-D588987AC3EB@iam.unibe.ch> References: <4F0CA1C3-A25C-4F70-ACF1-CAA6246FDDDE@silverfieldstech.com> <5A5A07E7-8AED-47AC-B9CD-D588987AC3EB@iam.unibe.ch> Message-ID: > 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 From damien.cassou at laposte.net Sun Jan 8 17:21:10 2006 From: damien.cassou at laposte.net (Damien Cassou) Date: Sun, 08 Jan 2006 17:21:10 +0100 Subject: New user questions In-Reply-To: References: <4F0CA1C3-A25C-4F70-ACF1-CAA6246FDDDE@silverfieldstech.com> Message-ID: <43C13BF6.7060906@laposte.net> -----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----- From renggli at iam.unibe.ch Sun Jan 8 18:10:28 2006 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Sun, 8 Jan 2006 18:10:28 +0100 Subject: New user questions In-Reply-To: <43C13BF6.7060906@laposte.net> References: <4F0CA1C3-A25C-4F70-ACF1-CAA6246FDDDE@silverfieldstech.com> <43C13BF6.7060906@laposte.net> Message-ID: <80C13F8B-3A46-4B23-811C-A79F24628AE3@iam.unibe.ch> -----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 :-) 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFDwUeEPSdrOS4Za5sRAl46AJ9EcS+WyO3W47tYQVGatoEPFvg9+QCfdht3 ImFcSvXpUfQDptc9E7BTnGo= =WGNj -----END PGP SIGNATURE----- From treaves at silverfieldstech.com Sun Jan 8 21:10:48 2006 From: treaves at silverfieldstech.com (Timothy Reaves) Date: Sun, 8 Jan 2006 15:10:48 -0500 Subject: Reinstalled, and a new browser is there... Message-ID: <129CBF00-B9B2-4C48-9DEE-E82565FCF60D@silverfieldstech.com> I just did a re-install on Seaside & Pier into a clean image. This time, I took a little time and browsed a few of the packages first. I came across OmniBrowser. This looked interesting, so I installed it. Then, when I installed Pier, a PierBrowser opened. This had not happened before. Did I miss something in the docs saying that OmniBrowser was something Pier interacted with, and to install it beforehand? Am I correct in the connection? Thanks. From renggli at iam.unibe.ch Sun Jan 8 21:57:34 2006 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Sun, 8 Jan 2006 21:57:34 +0100 Subject: Reinstalled, and a new browser is there... In-Reply-To: <129CBF00-B9B2-4C48-9DEE-E82565FCF60D@silverfieldstech.com> References: <129CBF00-B9B2-4C48-9DEE-E82565FCF60D@silverfieldstech.com> Message-ID: > I just did a re-install on Seaside & Pier into a clean image. This > time, I took a little time and browsed a few of the packages > first. I came across OmniBrowser. This looked interesting, so I > installed it. Then, when I installed Pier, a PierBrowser opened. > This had not happened before. Did I miss something in the docs > saying that OmniBrowser was something Pier interacted with, and to > install it beforehand? Am I correct in the connection? Yep, the Pier package on SqueakMap installs an extra package called Pier-OmniBrowser, if you have OmniBrowser installed in your image. The Pier-OmniBrowser package is used as just another view (to the default one using Seaside) on top of Pier model. Thanks to the power of Magritte this required only very few code and is almost as powerful as its Seaside counterpart. There is still a lot to improve, especially the Magritte-to-Morphic part is quite weak; I just put in there what is absolutely needed to run the Pier command pattern automatically. A nice thing that I just added recently is the syntax-highlighting of the wiki-source, also featuring clickable links; however there are still some major problems in that area, especially updating the selection and the lists in OmniBrowser doesn't work. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From treaves at silverfieldstech.com Mon Jan 9 03:10:42 2006 From: treaves at silverfieldstech.com (Timothy Reaves) Date: Sun, 8 Jan 2006 21:10:42 -0500 Subject: CSS question Message-ID: I don't have a good understanding of how CSS is applied. I see in the source view of the page several references to CSS files, but I do not understand what generates those entities. Would someone explain? Thanks. From treaves at silverfieldstech.com Mon Jan 9 03:19:52 2006 From: treaves at silverfieldstech.com (Timothy Reaves) Date: Sun, 8 Jan 2006 21:19:52 -0500 Subject: # of instances... Message-ID: <4555E584-E468-4F22-8631-95A0ED0BAD16@silverfieldstech.com> It I keep calling PRPierFrame.initialize, can I just keep creating instances? Or should each image only run one? Also, what is the difference in what name I give the kernel, and the context? Couldn't you just use the same name for both? Or is the name of the kernel relevant when upgrading Pier versions? From renggli at iam.unibe.ch Mon Jan 9 10:40:52 2006 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Mon, 9 Jan 2006 10:40:52 +0100 Subject: CSS question In-Reply-To: References: Message-ID: <37D5EBAE-6E14-43ED-90F4-B42D481FDC9A@iam.unibe.ch> > I don't have a good understanding of how CSS is applied. I see in > the source view of the page several references to CSS files, but I > do not understand what generates those entities. Would someone > explain? Right now they are just on http://www.lukas-renggli.ch/sw2/style.css, as referenced from PRPierFrame>>style. You might want to copy those files to one of your servers, and change that URL. I know this solutions is bad, but right now there is no easy way to include the pictures referenced from the CSS otherwise. I am definitely investigating a better solution. Avi, what do you think about slightly changing the way those libraries are working? My idea would be to map the selected libraries of an application to URLs like http://localhost:8080/seaside/ application/_lc=class&_ls=selector so that those files can be directly referenced from within each other and would be also cached across sessions. Moreover, i would like to make it possible to return a mime document so that files can be served without the need to tweak something with the web-server. This should be possible in a backward compatible way. What do you think? Should I give a go? Lukas -- Lukas Renggli http://www.lukas-renggli.ch From renggli at iam.unibe.ch Mon Jan 9 10:49:28 2006 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Mon, 9 Jan 2006 10:49:28 +0100 Subject: # of instances... In-Reply-To: <4555E584-E468-4F22-8631-95A0ED0BAD16@silverfieldstech.com> References: <4555E584-E468-4F22-8631-95A0ED0BAD16@silverfieldstech.com> Message-ID: <64607325-E327-43C4-AFC5-5348DADD6882@iam.unibe.ch> > It I keep calling PRPierFrame.initialize, can I just keep creating > instances? Or should each image only run one? No, it is possible to run several instances in one image. You can create new kernels by evaluating: PRPierFrame initialize. and then answering to the questions: Would you like to create a Seaside application for Pier? -> yes Would you like to create a new Pier kernel? -> yes Please enter the name of your Pier kernel: -> foo (this is the kernel name) Enter the entry point: -> foo (this is the url segment) Make sure the web-server is running by evaluating: WAKom startOn: 8080 and browse to http://localhost:8080/seaside/pier Cheers, Lukas > Also, what is the difference in what name I give the kernel, and > the context? The name is just used to identify different Kernels. You can inspect them by evaluating: PRKernel instances explore. > Couldn't you just use the same name for both? Or is the name of > the kernel relevant when upgrading Pier versions? Yes, you can use the same for both (but not the same URL segment). No, this has nothing to do with upgrading. Lukas -- Lukas Renggli http://www.lukas-renggli.ch From avi.bryant at gmail.com Mon Jan 9 11:22:18 2006 From: avi.bryant at gmail.com (Avi Bryant) Date: Mon, 09 Jan 2006 02:22:18 -0800 Subject: CSS question In-Reply-To: <37D5EBAE-6E14-43ED-90F4-B42D481FDC9A@iam.unibe.ch> References: <37D5EBAE-6E14-43ED-90F4-B42D481FDC9A@iam.unibe.ch> Message-ID: <32BBCE86-B83C-4811-89FB-FC6807B5D29C@gmail.com> On Jan 9, 2006, at 1:40 AM, Lukas Renggli wrote: >> I don't have a good understanding of how CSS is applied. I see in >> the source view of the page several references to CSS files, but I >> do not understand what generates those entities. Would someone >> explain? > > Right now they are just on http://www.lukas-renggli.ch/sw2/ > style.css, as referenced from PRPierFrame>>style. You might want to > copy those files to one of your servers, and change that URL. I > know this solutions is bad, but right now there is no easy way to > include the pictures referenced from the CSS otherwise. I am > definitely investigating a better solution. Check out #resourceUrl: and the #resourceBaseUrl configuration parameter. I'm not sure I totally understand the issue but they might help. > > Avi, what do you think about slightly changing the way those > libraries are working? My idea would be to map the selected > libraries of an application to URLs like http://localhost:8080/ > seaside/application/_lc=class&_ls=selector so that those files can > be directly referenced from within each other and would be also > cached across sessions. They are already cached across sessions. The idea behind the current approach is that their URL changes IFF the content changes, so that they can be cached forever. > Moreover, i would like to make it possible to return a mime > document so that files can be served without the need to tweak > something with the web-server. This should be possible in a > backward compatible way. What do you think? Should I give a go? Isn't this possible already? What changes are you proposing? Avi From cbeler at enit.fr Mon Jan 9 11:52:34 2006 From: cbeler at enit.fr (=?UTF-8?B?Q8OpZHJpY2sgQsOpbGVy?=) Date: Mon, 09 Jan 2006 11:52:34 +0100 Subject: New user questions In-Reply-To: References: <4F0CA1C3-A25C-4F70-ACF1-CAA6246FDDDE@silverfieldstech.com> <19E8A1B2-8C4D-4A25-8C63-9C442350E13D@versateladsl.be> Message-ID: <43C24072.1090100@enit.fr> 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... > > 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. > 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 at enit.fr From renggli at iam.unibe.ch Mon Jan 9 13:32:53 2006 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Mon, 9 Jan 2006 13:32:53 +0100 Subject: New user questions In-Reply-To: <43C24072.1090100@enit.fr> References: <4F0CA1C3-A25C-4F70-ACF1-CAA6246FDDDE@silverfieldstech.com> <19E8A1B2-8C4D-4A25-8C63-9C442350E13D@versateladsl.be> <43C24072.1090100@enit.fr> Message-ID: <8AE86229-0CF4-43D1-8566-033C5800AE70@iam.unibe.ch> > 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... Yes, this is something that is already in there: methods that should never be overridden (like PRCommand>>execute) do state this in their method-comment. > 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 From renggli at iam.unibe.ch Mon Jan 9 15:21:33 2006 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Mon, 9 Jan 2006 15:21:33 +0100 Subject: New user questions In-Reply-To: <43C13BF6.7060906@laposte.net> References: <4F0CA1C3-A25C-4F70-ACF1-CAA6246FDDDE@silverfieldstech.com> <43C13BF6.7060906@laposte.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -----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 :-) I fixed it, sorry for the delay. Lukas - - -- Lukas Renggli http://www.lukas-renggli.ch - -----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----- From treaves at silverfieldstech.com Tue Jan 10 23:36:05 2006 From: treaves at silverfieldstech.com (Timothy Reaves) Date: Tue, 10 Jan 2006 17:36:05 -0500 Subject: History in the default install Message-ID: <483E7C8B-D294-49A2-AE79-DD6424B8DCFA@silverfieldstech.com> What exactly is this for? What is supposed to happen when History is clicked on? From renggli at iam.unibe.ch Wed Jan 11 01:01:03 2006 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Wed, 11 Jan 2006 01:01:03 +0100 Subject: History in the default install In-Reply-To: <483E7C8B-D294-49A2-AE79-DD6424B8DCFA@silverfieldstech.com> References: <483E7C8B-D294-49A2-AE79-DD6424B8DCFA@silverfieldstech.com> Message-ID: <68123195-2BF6-4C03-B353-5250246B3879@iam.unibe.ch> > What exactly is this for? What is supposed to happen when History > is clicked on? This is a history (log) of the changes applied to that particular structure. It is not very useful right now and it doesn't even work out of the box because it requires a persistency strategy to be assigned to the kernel. You can do this manually by evaluating something like: kernel peristency: PRFilePersistency new Then browse to your wiki and execute some commands, e.g. edit a page several times. When clicking on history you should see the list of the applied commands with time-stamps. You can even open old them, look at their details and re-evaluate them, exactly as you can do with the change-sets in Smalltalk. The interface is not very sophisticated right now, but it works for a small demo and it is planned to get it improved together with new persistency strategies. Lukas -- Lukas Renggli http://www.lukas-renggli.ch From treaves at silverfieldstech.com Wed Jan 11 01:29:19 2006 From: treaves at silverfieldstech.com (Timothy Reaves) Date: Tue, 10 Jan 2006 19:29:19 -0500 Subject: Use of tables Message-ID: <5E068A0E-5655-469C-9A82-83FC09D90BA6@silverfieldstech.com> Most (current) books on XHTML will say not to use tables, to use div's instead. I understand that div's have a bit of a higher learning curve, but they are truely intended as page layout elements. Will table use in Pier be replaced by div's? From treaves at silverfieldstech.com Wed Jan 11 01:31:52 2006 From: treaves at silverfieldstech.com (Timothy Reaves) Date: Tue, 10 Jan 2006 19:31:52 -0500 Subject: [Smallwiki] Re: History in the default install In-Reply-To: <68123195-2BF6-4C03-B353-5250246B3879@iam.unibe.ch> References: <483E7C8B-D294-49A2-AE79-DD6424B8DCFA@silverfieldstech.com> <68123195-2BF6-4C03-B353-5250246B3879@iam.unibe.ch> Message-ID: <28029A18-CF1B-4D2B-B573-CC59F56CCC02@silverfieldstech.com> That was the piece of information I was missing. :) Has any thought been given (if only time were as readily available...) to creating an admin app / page for use in configuring Pier? It would seem that would be an ideal place to show what options are available, and what current configuration was. On Jan 10, 2006, at 7:01 PM, Lukas Renggli wrote: >> What exactly is this for? What is supposed to happen when History >> is clicked on? > > This is a history (log) of the changes applied to that particular > structure. It is not very useful right now and it doesn't even work > out of the box because it requires a persistency strategy to be > assigned to the kernel. > > You can do this manually by evaluating something like: > > kernel peristency: PRFilePersistency new > > Then browse to your wiki and execute some commands, e.g. edit a > page several times. When clicking on history you should see the > list of the applied commands with time-stamps. You can even open > old them, look at their details and re-evaluate them, exactly as > you can do with the change-sets in Smalltalk. The interface is not > very sophisticated right now, but it works for a small demo and it > is planned to get it improved together with new persistency > strategies. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > _______________________________________________ > Smallwiki mailing list > Smallwiki at impara.de > http://impara.de/mailman/listinfo/smallwiki From treaves at silverfieldstech.com Wed Jan 11 06:23:18 2006 From: treaves at silverfieldstech.com (Timothy Reaves) Date: Wed, 11 Jan 2006 00:23:18 -0500 Subject: Subclassing PRPierFrame Message-ID: I decided to create a subclass of PRPierFrame to start a new site. The only thing I overrode from PRPierFrame is the class method createInvironemntFor:. I remove the view widget, and reordered the other two on the left side of the display. I then initialized this new class, gave it a new kernel name and root, and opened it up. It displayed as I had expected it to. Problem is, the existing pier app now displays the new structure too. Why is this? Are some Pier classes singletons? From treaves at silverfieldstech.com Wed Jan 11 06:24:49 2006 From: treaves at silverfieldstech.com (Timothy Reaves) Date: Wed, 11 Jan 2006 00:24:49 -0500 Subject: Removing a kernel Message-ID: <52CF3E8F-69AE-45E2-8A84-22A2B8F0130D@silverfieldstech.com> What is the best way to remove a kernel? Does removing a kernel also remove all content created under that kernel (via the add command on the web page itself)? From renggli at iam.unibe.ch Wed Jan 11 07:29:31 2006 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Wed, 11 Jan 2006 07:29:31 +0100 Subject: Use of tables In-Reply-To: <5E068A0E-5655-469C-9A82-83FC09D90BA6@silverfieldstech.com> References: <5E068A0E-5655-469C-9A82-83FC09D90BA6@silverfieldstech.com> Message-ID: <9C37EEFD-BAD1-4315-946C-D11DF73F0613@iam.unibe.ch> > Most (current) books on XHTML will say not to use tables, to use > div's instead. I understand that div's have a bit of a higher > learning curve, but they are truely intended as page layout > elements. Will table use in Pier be replaced by div's? Eventually. The same is true for the Magritte Forms (see MACssRenderer). I didn't found a solution that works well without tables across all the browsers. Contributions to replace tables with div's are welcome ;-) Lukas -- Lukas Renggli http://www.lukas-renggli.ch From renggli at iam.unibe.ch Wed Jan 11 07:29:35 2006 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Wed, 11 Jan 2006 07:29:35 +0100 Subject: Subclassing PRPierFrame In-Reply-To: References: Message-ID: > I decided to create a subclass of PRPierFrame to start a new site. > The only thing I overrode from PRPierFrame is the class method > createInvironemntFor:. I remove the view widget, and reordered the > other two on the left side of the display. I then initialized this > new class, gave it a new kernel name and root, and opened it up. > It displayed as I had expected it to. If you browse to "/Environment" -- a special hidden page (sort of a meta-page) being used to layout Pier -- you are able to configure your application from the web without the need of subclassing. > Problem is, the existing pier app now displays the new structure > too. Why is this? Are some Pier classes singletons? "PRKernel instances" answers a collection of registered Pier instances. I do not take the assumption that there is just one instance, it is fine to run multiple kernels in one image. When browsing to the Seaside config interface you are able to select the kernel you want to use for your application (see screenshot below). You might have multiple instances using the same kernel. -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture 1.png Type: image/png Size: 9982 bytes Desc: not available Url : http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20060111/a76cc866/Picture1.png -------------- next part -------------- PRMacroExpander and MACachedBuilder are the only singletons that come into my mind right now. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From renggli at iam.unibe.ch Wed Jan 11 07:29:37 2006 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Wed, 11 Jan 2006 07:29:37 +0100 Subject: Removing a kernel In-Reply-To: <52CF3E8F-69AE-45E2-8A84-22A2B8F0130D@silverfieldstech.com> References: <52CF3E8F-69AE-45E2-8A84-22A2B8F0130D@silverfieldstech.com> Message-ID: <22EDFD96-9AD9-4B3F-BB7C-45D0C38FAB3E@iam.unibe.ch> > What is the best way to remove a kernel? Does removing a kernel > also remove all content created under that kernel (via the add > command on the web page itself)? There are several places a kernel can be referenced from. If you have a Seaside application then you have to remove it from the config interface. Moreover you have to remove it from the collection returned by "MAKernel instances". Then it should go away, with all its content, at the next garbage-collect. The pages are stored in the i-var 'root' within the kernel instance. You might want to inspect/explore the model to see how it is connected: kernel explore Lukas -- Lukas Renggli http://www.lukas-renggli.ch From renggli at iam.unibe.ch Wed Jan 11 07:29:33 2006 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Wed, 11 Jan 2006 07:29:33 +0100 Subject: [Smallwiki] Re: History in the default install In-Reply-To: <28029A18-CF1B-4D2B-B573-CC59F56CCC02@silverfieldstech.com> References: <483E7C8B-D294-49A2-AE79-DD6424B8DCFA@silverfieldstech.com> <68123195-2BF6-4C03-B353-5250246B3879@iam.unibe.ch> <28029A18-CF1B-4D2B-B573-CC59F56CCC02@silverfieldstech.com> Message-ID: <7ABCB687-EE87-42DB-BC68-9C52B7485AF2@iam.unibe.ch> > Has any thought been given (if only time were as readily > available...) to creating an admin app / page for use in > configuring Pier? It would seem that would be an ideal place to > show what options are available, and what current configuration was. Yeah, as a first step we could maybe setup a simple workspace with a couple of common expressions to configure a Pier instance. There is also a first step in PRPierConfiguration, accessible trough the Seaside configuration interface (/seaside/config). We should extend that to support more properties. Lukas -- Lukas Renggli http://www.lukas-renggli.ch From treaves at silverfieldstech.com Wed Jan 11 13:51:51 2006 From: treaves at silverfieldstech.com (Timothy Reaves) Date: Wed, 11 Jan 2006 07:51:51 -0500 Subject: [Smallwiki] Re: Use of tables In-Reply-To: <9C37EEFD-BAD1-4315-946C-D11DF73F0613@iam.unibe.ch> References: <5E068A0E-5655-469C-9A82-83FC09D90BA6@silverfieldstech.com> <9C37EEFD-BAD1-4315-946C-D11DF73F0613@iam.unibe.ch> Message-ID: <2B6FD7AF-83CB-4E6E-92D8-926915586CD4@silverfieldstech.com> On Jan 11, 2006, at 1:29 AM, Lukas Renggli wrote: >> Most (current) books on XHTML will say not to use tables, to use >> div's instead. I understand that div's have a bit of a higher >> learning curve, but they are truely intended as page layout >> elements. Will table use in Pier be replaced by div's? > > Eventually. The same is true for the Magritte Forms (see > MACssRenderer). I didn't found a solution that works well without > tables across all the browsers. Contributions to replace tables > with div's are welcome ;-) > > Lukas I'll get started. From treaves at silverfieldstech.com Wed Jan 11 13:50:58 2006 From: treaves at silverfieldstech.com (Timothy Reaves) Date: Wed, 11 Jan 2006 07:50:58 -0500 Subject: [Smallwiki] Re: Subclassing PRPierFrame In-Reply-To: References: Message-ID: <34CCD797-72E2-4B80-A8D5-ADFB4EE6E1FA@silverfieldstech.com> On Jan 11, 2006, at 1:29 AM, Lukas Renggli wrote: >> I decided to create a subclass of PRPierFrame to start a new >> site. The only thing I overrode from PRPierFrame is the class >> method createInvironemntFor:. I remove the view widget, and >> reordered the other two on the left side of the display. I then >> initialized this new class, gave it a new kernel name and root, >> and opened it up. It displayed as I had expected it to. > > If you browse to "/Environment" -- a special hidden page (sort of > a meta-page) being used to layout Pier -- you are able to > configure your application from the web without the need of > subclassing. > I don't understand how it would be used to layout pier; it seems to be simply the wiki nested entirely in the content pane of the wiki. From treaves at silverfieldstech.com Wed Jan 11 13:53:18 2006 From: treaves at silverfieldstech.com (Timothy Reaves) Date: Wed, 11 Jan 2006 07:53:18 -0500 Subject: Security: authorization Message-ID: Is this in the works? I'd want any editor to login, and I'd also want to selectively show content based on who you are (so that a non- logged in person wouldn't even see the edit tools). From cbeler at enit.fr Wed Jan 11 16:32:34 2006 From: cbeler at enit.fr (=?UTF-8?B?Q8OpZHJpY2sgQsOpbGVy?=) Date: Wed, 11 Jan 2006 16:32:34 +0100 Subject: [Smallwiki] Re: Subclassing PRPierFrame In-Reply-To: <34CCD797-72E2-4B80-A8D5-ADFB4EE6E1FA@silverfieldstech.com> References: <34CCD797-72E2-4B80-A8D5-ADFB4EE6E1FA@silverfieldstech.com> Message-ID: <43C52512.5010909@enit.fr> >> >> If you browse to "/Environment" -- a special hidden page (sort of a >> meta-page) being used to layout Pier -- you are able to configure >> your application from the web without the need of subclassing. >> > > I don't understand how it would be used to layout pier; it seems to be > simply the wiki nested entirely in the content pane of the wiki. yes in a view mode but if you edit it, you can reorganize widgets... with the wiki syntax... c?drick From cbeler at enit.fr Wed Jan 11 16:45:52 2006 From: cbeler at enit.fr (=?ISO-8859-1?Q?C=E9drick_B=E9ler?=) Date: Wed, 11 Jan 2006 16:45:52 +0100 Subject: Security: authorization In-Reply-To: References: Message-ID: <43C52830.7010106@enit.fr> Timothy Reaves a ?crit : > Is this in the works? I'd want any editor to login, and I'd also > want to selectively show content based on who you are (so that a non- > logged in person wouldn't even see the edit tools). > I think it should work. When you 're logged as an admin (admin/pier by default), you can manage rights for all possible commands (view, edit,... its a multiple choice list) for each page for each user and groups... -- C?drick From treaves at silverfieldstech.com Wed Jan 11 18:09:51 2006 From: treaves at silverfieldstech.com (treaves@silverfieldstech.com) Date: Wed, 11 Jan 2006 12:09:51 -0500 (EST) Subject: [Smallwiki] Re: Security: authorization In-Reply-To: <43C52830.7010106@enit.fr> References: <43C52830.7010106@enit.fr> Message-ID: <36849.155.188.191.4.1136999391.squirrel@mail.silverfieldstech.com> > > > Timothy Reaves a ?crit : > >> Is this in the works? I'd want any editor to login, and I'd also >> want to selectively show content based on who you are (so that a non- >> logged in person wouldn't even see the edit tools). >> > I think it should work. When you 're logged as an admin (admin/pier by > default), you can manage rights for all possible commands (view, > edit,... its a multiple choice list) for each page for each user and > groups... > But how is this managed? Does logging into Seaside automatically give me admin in Pier? How do I add other users? Is auth handled on a per-page basis, or is it inhearited so that I can do it on a per-tree basis? From cbeler at enit.fr Wed Jan 11 18:51:15 2006 From: cbeler at enit.fr (=?ISO-8859-1?Q?C=E9drick_B=E9ler?=) Date: Wed, 11 Jan 2006 18:51:15 +0100 Subject: [Smallwiki] Re: Security: authorization In-Reply-To: <36849.155.188.191.4.1136999391.squirrel@mail.silverfieldstech.com> References: <43C52830.7010106@enit.fr> <36849.155.188.191.4.1136999391.squirrel@mail.silverfieldstech.com> Message-ID: <43C54593.2050406@enit.fr> > > But how is this managed? > > Does logging into Seaside automatically give me admin in Pier? How >do I add other users? Is auth handled on a per-page basis, or is it >inhearited so that I can do it on a per-tree basis? > > > On the version I have, when you enter Pier you only have minimal rights (view...) On the command side, if you log with admin (pass: pier); you have all rights... usually when you don't log, you should'nt have a lot of rights. On the new version I have I have all rights without being logged (others). To change that select a page, Pier for example choose change owner then operation remove then save you can do that on all pages individually or apply it recursively on the subtree. now you shouldnt acces any pages even for viewing them (if yout let recursive checked) (but the pages remains accessible for viewing if you type the adress. (Is it normal Lukas ?) if you want to change the rights back, log as admin and set some rights... It is not unix rights, but ACM (access control mechanism). This is a link from the guy who did it, u'll find better information thant I can give lol... http://smallwiki.unibe.ch/advanceddesignlabs/designdocument/ or http://smallwiki.unibe.ch/advanceddesignlabs/slides/?action=MimeView From renggli at iam.unibe.ch Wed Jan 11 19:54:01 2006 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Wed, 11 Jan 2006 19:54:01 +0100 Subject: [Smallwiki] Re: Subclassing PRPierFrame In-Reply-To: <43C52512.5010909@enit.fr> References: <34CCD797-72E2-4B80-A8D5-ADFB4EE6E1FA@silverfieldstech.com> <43C52512.5010909@enit.fr> Message-ID: <6CB0C3F3-DEA7-46A9-BC81-AB0567FDBD16@iam.unibe.ch> >>> If you browse to "/Environment" -- a special hidden page (sort of >>> a meta-page) being used to layout Pier -- you are able to >>> configure your application from the web without the need of >>> subclassing. >> >> I don't understand how it would be used to layout pier; it seems >> to be simply the wiki nested entirely in the content pane of the >> wiki. > > yes in a view mode > but if you edit it, you can reorganize widgets... with the wiki > syntax... Indeed, it is a bit hard to describe those meta-levels with words. Maybe it is the easiest if you just edit that page. Take care not to remove the +Contents+ reference, else you are lost without having the Squeak image ready. Maybe you want to start by adding a string to the top or botton of that page and then browse around your wiki and look for differences? Another thing that is probably not well known is that you might add a new page called 'Environment' anywhere in your wiki to get a completely different widget-composition within that part. I am thinking about slightly redesigning the beast: I don't like the method #createEnvironmentFor: on the class-side of PRPierFrame. I remember having added it there in a rush to get the thing ready for a demo half a year ago. It should be probably moved into the structure or even the kernel and create it lazily. This would also give a better stability in case you accidently delete it. I will give a try tonight. Cheers, Lukas PS: If you have FireFox on your machine you can jump to a similar meta-level within your web-browser by pointing it to ;-) -- Lukas Renggli http://www.lukas-renggli.ch From renggli at iam.unibe.ch Wed Jan 11 20:20:16 2006 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Wed, 11 Jan 2006 20:20:16 +0100 Subject: Security: authorization In-Reply-To: References: Message-ID: Mhh, ok just to avoid confusions here: - Pier does not provide a security framework from out of the box. If you need security -- you probably do if you want to run it in public, you need to load one. > Is this in the works? I'd want any editor to login, and I'd also > want to selectively show content based on who you are (so that a > non-logged in person wouldn't even see the edit tools). - There are currently two independent security frameworks available (you probably shouldn't have both at the same time in your image): - Philippe build an ACL based one, that is around for quite a while now and that provides a lot of nice features. Maybe he can explain himself about the features, advantages, and on how to install and use it. - I build a small security model being very similar to the one of Unix. Every structure gets a collection of executable commands for the Owner, the Group and the Others. There is a set of commands to (recursively) change owner, group and modes (similar to chown, chgrp, and chmod). Users and groups cannot be managed trough the web right now, but that will be improved. There is no inheritance. It is very simple from implementation point of view, only a couple of classes and it also works perfectly with OmniBrowser. Load it from http:// mc.lukas-renggli.ch/pier. > But how is this managed? In the Unix Security framework it is currently only possible to add users and groups trough an inspector within the image. Users and groups are global. As far as I know this is different in Philippe's security system. > Does logging into Seaside automatically give me admin in Pier? No, logging into Seaside (/seaside/config) is a completely different story. This is just to manage the Seaside applications. > Is auth handled on a per-page basis, or is it inhearited so that I > can do it on a per-tree basis? Unix Security: per-page basis, not inherited, new children copy the permission of the parent, default username/password is admin/pier, no overrides ACL Security: Philippe? > now you shouldnt acces any pages even for viewing them (if yout let > recursive checked) (but the pages remains accessible for viewing if > you type the adress. (Is it normal Lukas ?) This is Philippe's code, I don't know. Ask him. Lukas -- Lukas Renggli http://www.lukas-renggli.ch From saidani at squeakfr.org Wed Jan 11 21:50:02 2006 From: saidani at squeakfr.org (Samir Saidani) Date: Wed, 11 Jan 2006 21:50:02 +0100 Subject: Visual works smallwiki status ? Message-ID: <87psmyv69x.fsf@info.unicaen.fr> Hi ! I'm working on smallwiki right now, and I'm trying to figure out what has been done in the visual works version in order to gather as much as possible and release a complete up-to-date version. There is three main versions of smallwiki: - the visual works one. - the squeak port done by Chris Bukert - the seaside stable image used for squeak.org The task is merging them. And merging is not easy ! For visual works: The latest version is : 0.9.53 (29 September 2004) with the comment "trying to understand publishing issue", the latest from lukas was 0.9.51 (24 June 2004) and changes from camp smalltalk was 0.9.52 (21 August 2004). I'm trying to figure out in which extent the public store version in in sync with the scg one ! The VW smallwiki development seems to have stop the last year, so it would be fun to gather the work realized instead of getting it forever lost ! When I'm connected to the scg store, I see that the latest version was 1.9.51.20.2 by greevy (23 November 2004), but don't know if it includes the changes from camp smalltalk. I tried the greevy version, but found a lot of missing methods (prepareCookies for instance) whereas the bulckaen version seems to be ok (17 September 2004). Is the bulckaen version related to the latest public store release (29 September 2004) ? or the greevy version ? Someone knows ? This archeological work will be valuable if people who participated could give some information ! For seaside: And is the seaside version based on the Chris port ? I guess so, but it seems that there is a lot of changes, no ? Anyway, I will try to figure out by testing and checking differences. Cheers, Samir From renggli at iam.unibe.ch Wed Jan 11 23:06:56 2006 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Wed, 11 Jan 2006 23:06:56 +0100 Subject: Visual works smallwiki status ? In-Reply-To: <87psmyv69x.fsf@info.unicaen.fr> References: <87psmyv69x.fsf@info.unicaen.fr> Message-ID: <70626F19-3EC4-419E-A0E0-E9F6FFB9F7C2@iam.unibe.ch> Hi Samir, thanks for your efforts merging the versions. I know about all the pain of having different versions from SqueakSource :-/ > - the visual works one. I stopped working on SmallWiki 1 in Summer 2004, so the most recent code from myself is version 0.9.51 on Cincom Public Store. Afterwards I didn't touch that code anymore because I started with SmallWiki 2 (now called Pier). > - the squeak port done by Chris Bukert > - the seaside stable image used for squeak.org The seaside image is basically the port of Chris Bukert, but we fixed a few things directly in there. I don't remember exactly, but I think the changes we made are now in the current Squeak port. > 1.9.51.20.2 by greevy (23 November 2004), but don't know if it > includes the changes from camp smalltalk. I tried the greevy version, > but found a lot of missing methods (prepareCookies for instance) > whereas the bulckaen version seems to be ok (17 September 2004). Is > the bulckaen version related to the latest public store release (29 > September 2004) ? or the greevy version ? Someone knows ? This > archeological work will be valuable if people who participated could > give some information ! Sorry, I have no idea about this. Orla? Stef? > And is the seaside version based on the Chris port ? I guess so, but > it seems that there is a lot of changes, no ? What Seaside versions are you talking about? * If you are talking about TinyWiki or PicoWiki, these are basically rip-offs taking the parser and the document representation of SmallWiki 1 and plugging that into a Seaside component. These are just small sub-sets of SmallWiki 1, as their name says. * SmallWiki 2 / Pier is a complete rewrite from scratch. Most (if not all) parts are very different. From design point of view probably only the document representation didn't change much. It should be quite easy to port back, but I guess there are not that many new features that it is worth the hassle. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From philippe.marschall at gmail.com Wed Jan 11 23:55:51 2006 From: philippe.marschall at gmail.com (Philippe Marschall) Date: Wed, 11 Jan 2006 23:55:51 +0100 Subject: [Smallwiki] Re: Security: authorization In-Reply-To: <36849.155.188.191.4.1136999391.squirrel@mail.silverfieldstech.com> References: <43C52830.7010106@enit.fr> <36849.155.188.191.4.1136999391.squirrel@mail.silverfieldstech.com> Message-ID: <66666f210601111455s3fc14f89h@mail.gmail.com> Hi Besides the links already posted by C?drick (you can find a demo image of an old version there) you can find a summary about the access control list based security model here: http://impara.de/pipermail/smallwiki/2005-September/002581.html (monticello repository is invalid, classname prefixes have changed) so I won't recap the points covered there. Basically it's similar to Windows/new-school Unix (yes, we are serious, Windows). > Does logging into Seaside automatically give me admin in Pier? Nope, it gives you the rights of this user. What that is depends, well on the user. > How do I add other users? Go to /Management/Users, if you have the permission an `Add User' command (Pier term for action) should appear. > Is auth handled on a per-page basis, Yes. Acutally per structure. A page is a sturcute, but for example a file is a structure too. > or is it inhearited so that I can do it on a per-tree basis? Once a structure is created, it gets a copy of the access rules (access control items) of its parent, from that point on, they are independend. So like Lukas. However if you add an access rule to a structure it's possible to check a box that adds it to all children (where you have the permission). The same for removing. More sphisticated tools could be implemented if needed. > I'd want any editor to login you can do that > want to selectively show content based on who you are you can do that too >(so that a nonlogged in person wouldn't even see the edit tools). That's done. IIRC Lukas does it too > now you shouldnt acces any pages even for viewing them (if yout let > recursive checked) > (but the pages remains accessible for viewing if you type the adress. > (Is it normal Lukas ?) I don't fully understand what you want to know so I'll answer visibility in general. If a user doesn't have the view permission for a structure he does not see it, not even listed in the tree. If he has the view permission for a child of a structure he is not allowed to view, then the can view this child by using a link or tying the url. If he types the url of a sturcture he is not allowed to see, he will not see it. The title is rendered though last time I checked. advantages - the actual model is simple yet powerful and flexible, or at least this is our illusion - allows you not only to grant rights, but also to deny them - fancy stuff: -- groups can contain groups -- command sets -- special groups like `everyone', `everyone who is logged in' - required commands, so for example moving a structure requires the add right on the target structure - complete user interface - magritte UI (mostly) - stay logged in with cookies - optional goodies -- users can for example have an IM address and their online status will be shown - tries to prevent dictionary attacks, after 3 invalid tries to login you have to wait 5 minutes (configurable) - green tests disadvantes - (probably) doesn't load into latest Pier, I will have to adapt it (shouldn't be too hard). It had to do some overrides before Lukas started with his work. They should no longer be neccessary so that it should work better with future versions - Didn't integrate into stock Pier as well as I'd like it to be but that should be better with the latest versions in Pier once I've made the changes (see above). So if you want to see it in action the best way is probably to use the demo image (follow the links posted by C?drick). - more complex than I'd like it to be, although most complexity is in Magritte/Seaside and the kernel didn't have to be touched for quite some time. But there's always a tradeoff between adding features and reducing complexity. - quite uncommon model, works well in theory but not really proved in the field Cheers Philippe From stephane.ducasse at univ-savoie.fr Thu Jan 12 09:25:03 2006 From: stephane.ducasse at univ-savoie.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Thu, 12 Jan 2006 09:25:03 +0100 Subject: Visual works smallwiki status ? In-Reply-To: <87psmyv69x.fsf@info.unicaen.fr> References: <87psmyv69x.fsf@info.unicaen.fr> Message-ID: <8B9D16D8-A4E2-451A-BCE3-8AA65556473F@univ-savoie.fr> Samir It would be good to merge the work done at impara to add a file saving backup. Stef > Hi ! > > I'm working on smallwiki right now, and I'm trying to figure out what > has been done in the visual works version in order to gather as much > as possible and release a complete up-to-date version. > > There is three main versions of smallwiki: > > - the visual works one. > - the squeak port done by Chris Bukert > - the seaside stable image used for squeak.org > > The task is merging them. > > And merging is not easy ! > We never tried to merge the Camp version since it was not really working. Stef > For visual works: > > The latest version is : 0.9.53 (29 September 2004) with the comment > "trying to understand publishing issue", the latest from lukas was > 0.9.51 (24 June 2004) and changes from camp smalltalk was 0.9.52 (21 > August 2004). I'm trying to figure out in which extent the public > store version in in sync with the scg one ! The VW smallwiki > development seems to have stop the last year, so it would be fun to > gather the work realized instead of getting it forever lost ! > > When I'm connected to the scg store, I see that the latest version was > 1.9.51.20.2 by greevy (23 November 2004), but don't know if it > includes the changes from camp smalltalk. I tried the greevy version, > but found a lot of missing methods (prepareCookies for instance) > whereas the bulckaen version seems to be ok (17 September 2004). Is > the bulckaen version related to the latest public store release (29 > September 2004) ? or the greevy version ? Someone knows ? This > archeological work will be valuable if people who participated could > give some information ! The version of Frederick Bulckaen was a version with a first meta description. It was working but we never really tested. Stef > > For seaside: > > And is the seaside version based on the Chris port ? I guess so, but > it seems that there is a lot of changes, no ? > > Anyway, I will try to figure out by testing and checking differences. > > Cheers, > Samir > From stephane.ducasse at univ-savoie.fr Thu Jan 12 09:27:50 2006 From: stephane.ducasse at univ-savoie.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Thu, 12 Jan 2006 09:27:50 +0100 Subject: Visual works smallwiki status ? In-Reply-To: <70626F19-3EC4-419E-A0E0-E9F6FFB9F7C2@iam.unibe.ch> References: <87psmyv69x.fsf@info.unicaen.fr> <70626F19-3EC4-419E-A0E0-E9F6FFB9F7C2@iam.unibe.ch> Message-ID: Lukas may be it would be good to republish your latest Smallwiki 1 (0.9.51) version as SmallWiki 1.0 with a comment on store. Stef > Hi Samir, > > thanks for your efforts merging the versions. I know about all the > pain of having different versions from SqueakSource :-/ > >> - the visual works one. > > I stopped working on SmallWiki 1 in Summer 2004, so the most recent > code from myself is version 0.9.51 on Cincom Public Store. > Afterwards I didn't touch that code anymore because I started with > SmallWiki 2 (now called Pier). > >> - the squeak port done by Chris Bukert >> - the seaside stable image used for squeak.org > > The seaside image is basically the port of Chris Bukert, but we > fixed a few things directly in there. I don't remember exactly, but > I think the changes we made are now in the current Squeak port. > >> 1.9.51.20.2 by greevy (23 November 2004), but don't know if it >> includes the changes from camp smalltalk. I tried the greevy version, >> but found a lot of missing methods (prepareCookies for instance) >> whereas the bulckaen version seems to be ok (17 September 2004). Is >> the bulckaen version related to the latest public store release (29 >> September 2004) ? or the greevy version ? Someone knows ? This >> archeological work will be valuable if people who participated could >> give some information ! > > Sorry, I have no idea about this. Orla? Stef? > >> And is the seaside version based on the Chris port ? I guess so, but >> it seems that there is a lot of changes, no ? > > What Seaside versions are you talking about? > > * If you are talking about TinyWiki or PicoWiki, these are > basically rip-offs taking the parser and the document > representation of SmallWiki 1 and plugging that into a Seaside > component. These are just small sub-sets of SmallWiki 1, as their > name says. > > * SmallWiki 2 / Pier is a complete rewrite from scratch. Most (if > not all) parts are very different. From design point of view > probably only the document representation didn't change much. It > should be quite easy to port back, but I guess there are not that > many new features that it is worth the hassle. > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch From ducasse at iam.unibe.ch Thu Jan 12 09:30:38 2006 From: ducasse at iam.unibe.ch (=?ISO-8859-1?Q?st=E9phane_ducasse?=) Date: Thu, 12 Jan 2006 09:30:38 +0100 Subject: [Smallwiki] Re: Security: authorization In-Reply-To: <66666f210601111455s3fc14f89h@mail.gmail.com> References: <43C52830.7010106@enit.fr> <36849.155.188.191.4.1136999391.squirrel@mail.silverfieldstech.com> <66666f210601111455s3fc14f89h@mail.gmail.com> Message-ID: <0D5FC40C-EAFE-4CB8-AA97-C20F82443B28@iam.unibe.ch> It would be nice to have the security packages working when the version stable version of Pier will be available. Stef On 11 janv. 06, at 23:55, Philippe Marschall wrote: > Hi > > Besides the links already posted by C?drick (you can find a demo image > of an old version there) you can find a summary about the access > control list based security model here: > http://impara.de/pipermail/smallwiki/2005-September/002581.html > (monticello repository is invalid, classname prefixes have changed) > so I won't recap the points covered there. Basically it's similar to > Windows/new-school Unix (yes, we are serious, Windows). > >> Does logging into Seaside automatically give me admin in Pier? > Nope, it gives you the rights of this user. What that is depends, well > on the user. > >> How do I add other users? > Go to /Management/Users, if you have the permission an `Add User' > command (Pier term for action) should appear. > >> Is auth handled on a per-page basis, > Yes. Acutally per structure. A page is a sturcute, but for example a > file is a structure too. > >> or is it inhearited so that I can do it on a per-tree basis? > Once a structure is created, it gets a copy of the access rules > (access control items) of its parent, from that point on, they are > independend. So like Lukas. However if you add an access rule to a > structure it's possible to check a box that adds it to all children > (where you have the permission). The same for removing. More > sphisticated tools could be implemented if needed. > >> I'd want any editor to login > you can do that > >> want to selectively show content based on who you are > you can do that too > >> (so that a nonlogged in person wouldn't even see the edit tools). > That's done. IIRC Lukas does it too > >> now you shouldnt acces any pages even for viewing them (if yout let >> recursive checked) >> (but the pages remains accessible for viewing if you type the adress. >> (Is it normal Lukas ?) > I don't fully understand what you want to know so I'll answer > visibility in general. > If a user doesn't have the view permission for a structure he does not > see it, not even listed in the tree. If he has the view permission for > a child of a structure he is not allowed to view, then the can view > this child by using a link or tying the url. > If he types the url of a sturcture he is not allowed to see, he will > not see it. The title is rendered though last time I checked. > > advantages > - the actual model is simple yet powerful and flexible, or at least > this is our illusion > - allows you not only to grant rights, but also to deny them > - fancy stuff: > -- groups can contain groups > -- command sets > -- special groups like `everyone', `everyone who is logged in' > - required commands, so for example moving a structure requires the > add right on the target structure > - complete user interface > - magritte UI (mostly) > - stay logged in with cookies > - optional goodies > -- users can for example have an IM address and their online status > will be shown > - tries to prevent dictionary attacks, after 3 invalid tries to login > you have to wait 5 minutes (configurable) > - green tests > > disadvantes > - (probably) doesn't load into latest Pier, I will have to adapt it > (shouldn't be too hard). It had to do some overrides before Lukas > started with his work. They should no longer be neccessary so that it > should work better with future versions > - Didn't integrate into stock Pier as well as I'd like it to be but > that should be better with the latest versions in Pier once I've made > the changes (see above). So if you want to see it in action the best > way is probably to use the demo image (follow the links posted by > C?drick). > - more complex than I'd like it to be, although most complexity is in > Magritte/Seaside and the kernel didn't have to be touched for quite > some time. But there's always a tradeoff between adding features and > reducing complexity. > - quite uncommon model, works well in theory but not really proved > in the field > > Cheers > Philippe > From ducasse at iam.unibe.ch Thu Jan 12 17:24:35 2006 From: ducasse at iam.unibe.ch (=?ISO-8859-1?Q?st=E9phane_ducasse?=) Date: Thu, 12 Jan 2006 17:24:35 +0100 Subject: Fwd: smalltalk repository References: Message-ID: <1B4E7CEA-8FBF-4C50-8D74-5E4DC7867F27@iam.unibe.ch> > http://prog2.vub.ac.be/limbo/ A good css! Stef From rleon at insario.com Thu Jan 12 17:54:56 2006 From: rleon at insario.com (Ramon Leon) Date: Thu, 12 Jan 2006 09:54:56 -0700 Subject: smalltalk repository Message-ID: <24C40DFA333DC44882F9FB0115F33D8F32B974@ARGON.insario.local> > Subject: Fwd: smalltalk repository > > > http://prog2.vub.ac.be/limbo/ > > A good css! > > Stef Did you mean CMS? From ducasse at iam.unibe.ch Thu Jan 12 18:23:47 2006 From: ducasse at iam.unibe.ch (=?ISO-8859-1?Q?st=E9phane_ducasse?=) Date: Thu, 12 Jan 2006 18:23:47 +0100 Subject: smalltalk repository In-Reply-To: <24C40DFA333DC44882F9FB0115F33D8F32B974@ARGON.insario.local> References: <24C40DFA333DC44882F9FB0115F33D8F32B974@ARGON.insario.local> Message-ID: <169BD46D-9E1D-4BCA-B3EC-BE93E29D32C2@iam.unibe.ch> Nop I mean css. It would be good that Smallwiki gets as stable as those cms and this is why lukas needs help. Stef On 12 janv. 06, at 17:54, Ramon Leon wrote: >> Subject: Fwd: smalltalk repository >> >>> http://prog2.vub.ac.be/limbo/ >> >> A good css! >> >> Stef > > Did you mean CMS? > From rleon at insario.com Thu Jan 12 18:37:14 2006 From: rleon at insario.com (Ramon Leon) Date: Thu, 12 Jan 2006 10:37:14 -0700 Subject: smalltalk repository Message-ID: <24C40DFA333DC44882F9FB0115F33D8F32B97B@ARGON.insario.local> > Nop I mean css. > It would be good that Smallwiki gets as stable as those cms > and this is why lukas needs help. > > Stef Help me out then, I don't understand your comment, that link leads to a site that's a table layout, not css layout. What am I missing? From ducasse at iam.unibe.ch Thu Jan 12 19:09:01 2006 From: ducasse at iam.unibe.ch (=?ISO-8859-1?Q?st=E9phane_ducasse?=) Date: Thu, 12 Jan 2006 19:09:01 +0100 Subject: smalltalk repository In-Reply-To: <24C40DFA333DC44882F9FB0115F33D8F32B97B@ARGON.insario.local> References: <24C40DFA333DC44882F9FB0115F33D8F32B97B@ARGON.insario.local> Message-ID: <1D2BE7D7-5AD8-4C75-A827-55BAE1D0075E@iam.unibe.ch> Ok sorry I was judging the look and not the techno. Stupidly I thought that they used a css. On 12 janv. 06, at 18:37, Ramon Leon wrote: >> Nop I mean css. >> It would be good that Smallwiki gets as stable as those cms >> and this is why lukas needs help. >> >> Stef > > Help me out then, I don't understand your comment, that link leads > to a > site that's a table layout, not css layout. What am I missing? > From rleon at insario.com Thu Jan 12 20:03:36 2006 From: rleon at insario.com (Ramon Leon) Date: Thu, 12 Jan 2006 12:03:36 -0700 Subject: smalltalk repository Message-ID: <24C40DFA333DC44882F9FB0115F33D8F32B97F@ARGON.insario.local> One of my favorite things to do is hit ctrl + shift + s in firefox, it'll disable the css and you can see immediately just how compliant any site is. A real css site will lose all layout and look totally plain, many sites still hold most of their layout so you can see css hasn't taken over just yet. > -----Original Message----- > From: owner-smallwiki at iam.unibe.ch > [mailto:owner-smallwiki at iam.unibe.ch] On Behalf Of st?phane ducasse > Sent: Thursday, January 12, 2006 11:09 AM > To: smallwiki at iam.unibe.ch > Subject: Re: smalltalk repository > > Ok sorry I was judging the look and not the techno. > Stupidly I thought that they used a css. > > On 12 janv. 06, at 18:37, Ramon Leon wrote: > > >> Nop I mean css. > >> It would be good that Smallwiki gets as stable as those > cms and this > >> is why lukas needs help. > >> > >> Stef > > > > Help me out then, I don't understand your comment, that > link leads to > > a site that's a table layout, not css layout. What am I missing? > > > > From saidani at squeakfr.org Fri Jan 13 21:51:17 2006 From: saidani at squeakfr.org (Samir Saidani) Date: Fri, 13 Jan 2006 21:51:17 +0100 Subject: Visual works smallwiki status ? In-Reply-To: <70626F19-3EC4-419E-A0E0-E9F6FFB9F7C2@iam.unibe.ch> (Lukas Renggli's message of "Wed, 11 Jan 2006 23:06:56 +0100") References: <87psmyv69x.fsf@info.unicaen.fr> <70626F19-3EC4-419E-A0E0-E9F6FFB9F7C2@iam.unibe.ch> Message-ID: <8764onq2be.fsf@info.unicaen.fr> Lukas Renggli writes: > Hi Samir, > > thanks for your efforts merging the versions. I know about all the > pain of having different versions from SqueakSource :-/ Yes, snif... It seems that forking is a fractal phenomena ;-) >> - the visual works one. > > I stopped working on SmallWiki 1 in Summer 2004, so the most recent > code from myself is version 0.9.51 on Cincom Public Store. Afterwards > I didn't touch that code anymore because I started with SmallWiki 2 > (now called Pier). >> - the squeak port done by Chris Bukert >> - the seaside stable image used for squeak.org > > The seaside image is basically the port of Chris Bukert, but we fixed > a few things directly in there. I don't remember exactly, but I think > the changes we made are now in the current Squeak port. I'm not sure, my latest attempt to merge the first port with the seaside image gives a lot of differences. I have to see further to figure out what is going on... >> And is the seaside version based on the Chris port ? I guess so, but >> it seems that there is a lot of changes, no ? > > What Seaside versions are you talking about? The website seaside image, which is basically the same than squeak.org. > * If you are talking about TinyWiki or PicoWiki, these are basically > rip-offs taking the parser and the document representation of > SmallWiki 1 and plugging that into a Seaside component. These are > just small sub-sets of SmallWiki 1, as their name says. Interesting, I didn't know the existence of these wikis, they would be a good starting point to have a tiny smallwiki kernel, and work from that point : where are tinywiki and picowiki ? What are the differences between these wikis ? > * SmallWiki 2 / Pier is a complete rewrite from scratch. Most (if not > all) parts are very different. From design point of view probably > only the document representation didn't change much. It should be > quite easy to port back, but I guess there are not that many new > features that it is worth the hassle. Ok, thanks for these informations ! Regards, Samir From renggli at iam.unibe.ch Fri Jan 13 22:06:03 2006 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Fri, 13 Jan 2006 22:06:03 +0100 Subject: Visual works smallwiki status ? In-Reply-To: <8764onq2be.fsf@info.unicaen.fr> References: <87psmyv69x.fsf@info.unicaen.fr> <70626F19-3EC4-419E-A0E0-E9F6FFB9F7C2@iam.unibe.ch> <8764onq2be.fsf@info.unicaen.fr> Message-ID: <7E0BD4AA-8B7A-45FF-945D-20DC32E2CAFC@iam.unibe.ch> >>> And is the seaside version based on the Chris port ? I guess so, but >>> it seems that there is a lot of changes, no ? >> >> What Seaside versions are you talking about? > > The website seaside image, which is basically the same than > squeak.org. I guess these are the same, Adrian gave the image of seaside.st to the people doing squeak.org because they had problems with their own. >> * If you are talking about TinyWiki or PicoWiki, these are basically >> rip-offs taking the parser and the document representation of >> SmallWiki 1 and plugging that into a Seaside component. These are >> just small sub-sets of SmallWiki 1, as their name says. > > Interesting, I didn't know the existence of these wikis, they would be > a good starting point to have a tiny smallwiki kernel, and work from > that point : where are tinywiki and picowiki ? What are the > differences between these wikis ? PicoWiki is even smaller than TinyWiki ;-) Well, I don't exactly know the differences. TinyWiki is included with SqueakSource. PicoWiki is probably used within some internal project, I don't have a reference right now. -------------- next part -------------- A non-text attachment was scrubbed... Name: TinyWiki-lr.10.mcz Type: application/octet-stream Size: 11159 bytes Desc: not available Url : http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20060113/4aec4824/TinyWiki-lr.10.obj -------------- next part -------------- Lukas -- Lukas Renggli http://www.lukas-renggli.ch From renggli at iam.unibe.ch Fri Jan 13 22:06:03 2006 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Fri, 13 Jan 2006 22:06:03 +0100 Subject: Visual works smallwiki status ? In-Reply-To: <8764onq2be.fsf@info.unicaen.fr> References: <87psmyv69x.fsf@info.unicaen.fr> <70626F19-3EC4-419E-A0E0-E9F6FFB9F7C2@iam.unibe.ch> <8764onq2be.fsf@info.unicaen.fr> Message-ID: <7E0BD4AA-8B7A-45FF-945D-20DC32E2CAFC@iam.unibe.ch> >>> And is the seaside version based on the Chris port ? I guess so, but >>> it seems that there is a lot of changes, no ? >> >> What Seaside versions are you talking about? > > The website seaside image, which is basically the same than > squeak.org. I guess these are the same, Adrian gave the image of seaside.st to the people doing squeak.org because they had problems with their own. >> * If you are talking about TinyWiki or PicoWiki, these are basically >> rip-offs taking the parser and the document representation of >> SmallWiki 1 and plugging that into a Seaside component. These are >> just small sub-sets of SmallWiki 1, as their name says. > > Interesting, I didn't know the existence of these wikis, they would be > a good starting point to have a tiny smallwiki kernel, and work from > that point : where are tinywiki and picowiki ? What are the > differences between these wikis ? PicoWiki is even smaller than TinyWiki ;-) Well, I don't exactly know the differences. TinyWiki is included with SqueakSource. PicoWiki is probably used within some internal project, I don't have a reference right now. -------------- next part -------------- A non-text attachment was scrubbed... Name: TinyWiki-lr.10.mcz Type: application/octet-stream Size: 11159 bytes Desc: not available Url : http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20060113/4aec4824/TinyWiki-lr.10-0001.obj -------------- next part -------------- Lukas -- Lukas Renggli http://www.lukas-renggli.ch From ducasse at iam.unibe.ch Fri Jan 13 22:11:55 2006 From: ducasse at iam.unibe.ch (=?ISO-8859-1?Q?st=E9phane_ducasse?=) Date: Fri, 13 Jan 2006 22:11:55 +0100 Subject: SmallWiki persistency made by impara guy In-Reply-To: <87ek3bq2lq.fsf@info.unicaen.fr> References: <87k6d6v5x5.fsf@info.unicaen.fr> <87ek3bq2lq.fsf@info.unicaen.fr> Message-ID: <78CC3943-32BF-4D75-B7CC-60F7FC51DD24@iam.unibe.ch> The version used for the seaside website, Lukas sent the link for us > and this version is currently used for squeak.org and considered as > stable. So merging this stable version with the Chris port, because I > noticed that there was several changes between both versions. Ok I see > > > Mmm what do you mean by works done by impara ? Where are this > extensions ? Which repository ? http://source.impara.de/ But it seems that we cannot read it. Mike? I could not find the email where you offered the persistency backend for SW1. Stef From ducasse at iam.unibe.ch Fri Jan 13 22:19:36 2006 From: ducasse at iam.unibe.ch (=?ISO-8859-1?Q?st=E9phane_ducasse?=) Date: Fri, 13 Jan 2006 22:19:36 +0100 Subject: Fwd: [ANN] Smallwiki storage References: <431C11D2.7040009@impara.de> Message-ID: Begin forwarded message: > Hi all, > > we just released an enhancement for Smallwiki 1 that supports > external storage. This allows Smallwiki to run completely from > disk, using the image basically as a cache only. > > Check out Thomas' (thf) posting at > http://impara.de/pipermail/smallwiki/2005-September/002569.html > > for more details and links. > > Michael >