>> - PRPathLookup class>>star:path: you removed that, but it is
>> needed all trough the system
>
> Sorry I dont think that I meant to remove that method. Its the Pier-
> Caching package that is supposed to hook in to these methods.
Then this must be caused by the subsequent merges of the different
branches ...
>> - PRCommand: I moved the mutex from the kernel into the
>> persistency, it seems to belong there so that we don't violate
>> demeter. Now instad of having the critical section within the
>> command, the command passes itself to the persistency by sending
>> #execute:. The persistency strategy then can call #doValidate and
>> #doExecute at the right point in time. I think this is more
>> elegant and should even work better with object database, xml, ...
>
> sounds good
Yes, this seems to be much more logical to me. It does not enforce
the prevayler model (snapshot/changes) to the persistency, but let it
basically do anything it likes: before a command is executed, between
the validation and the execution, after the execution, etc.
>> - I don't understand the code to rename a kernel (why should that
>> matter?) and the code
>
> Because the kernel is looked up by name in the database.
Why don't you give your persistency strategy a unique id then? Pier
(currently) does not enforce unique names for kernels.
> But once everything is set up, what if you want to change things. I
> do frequently. I expect my image to change frequently, and my
> persistent store to hold my data.
>
> With my approach you can switch between persistency schemes on the
> fly. I thought that it was quite flashy to be able to switch from
> "everything in memory", "everything in memory, back up to
> persistent store" persistence to full "serve from persistent store".
That's cool, I completely agree.
> At your suggestion I guess I could begin a Pier-Persistency-Manager
> package to put this and the migration methods in.
Yep, that sounds nice to me.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
Hi Keith,
> I have had a go at porting the class that you were missing into 2.7
>
> I have once more attempted to merge my changes with yours in the
> current repositories. I am hoping that you might be able to adopt
> them into the mainstream now.
I had a look at your changes. I cannot merge them directly, since
they break several parts of Pier and all my productively running images.
I just committed a manually merged version of your code, below you
find the comments:
Pier-Model-kph.107:
- PRPathLookup class>>star:path: you removed that, but it is needed
all trough the system
- PRCommand: I moved the mutex from the kernel into the persistency,
it seems to belong there so that we don't violate demeter. Now instad
of having the critical section within the command, the command passes
itself to the persistency by sending #execute:. The persistency
strategy then can call #doValidate and #doExecute at the right point
in time. I think this is more elegant and should even work better
with object database, xml, ...
- PRFilePersistency: I removed that class for now, it does not work
- PRPersistency >>#log: this is not needed anymore
- I don't understand the code to rename a kernel (why should that
matter?) and the code related related to #realize. I think most
people don't want to start right from a database, the use of a
persistency strategy other than the default PRNullPersistency should
be only possible after everything is setup.
- PRPersistency has no #snaphost method anymore, there was no need
for that anymore.
Pier-Seaside-kph.109:
- PRPierMain>>#structureAtPath: this breaks a possible setup with
Apache, I restored my old code but wrapped #start: into the root
context, so that it basically has the same effect as your modification.
- PRPierControlPanel: I would suggest that you add this class into a
separate package and/or transform it to a normal WAComponent so it
can be directly used from within Pier. I usually remove the config
application from productive servers. Moreover it introduces
dependencies to external packages that might not be loaded (Pier Unix
Security) and duplicates functionality that I already ported to that
package earlier on.
Hope these changes help to finally merge all the code again?
Thanks for your contribution!
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
With the left menu in a Smallwlki being dynamic (can grow up or down
depending on user's selection) how can one place a box underneath the
menu so that it moves dynamically with the growth of the menu? Is there
a way to do that w/o hacking the image?
--
brad fuller
http://www.Sonaural.com/
+1 (408) 799-6124
Hi there!
I'd like to ask Pier users what kind of tools could be useful in order to
easily maintain their wiki (something like some reporting tools, specific
search queries and so on...). We (me and a colleague) will
work on this subject and try to make Pier's administrators life easier
;), with the help of Stef Ducasse. We have already some ideas but any
other useful ideas are welcome.
In the end, we would like to define an advanced query component for Pier.
By the way, Lukas, you said that you have already
done some work on a previous query component but you lacked the time
to finish it. Can you send us what you have done or at least give us
some hints? Thanks in advance.
Cheers (and happy new year!),
Sébastien
---------- Forwarded message ----------
From: Thomas Koschate <koschate(a)gmail.com>
Date: Dec 20, 2006 2:34 PM
Subject: [Seaside] Magritte for VisualWorks
To: seaside(a)lists.squeakfoundation.org
I've released a reasonably functional port of Magritte into the Cincom
public StORE. Load MagritteForVisualWorks - it will prompt you to
load any further required parcels. There's some chaff left from stuff
that isn't supported in VisualWorks, but nothing that will impede
functionality.
--
============================================================
Thomas Koschate
_______________________________________________
Seaside mailing list
Seaside(a)lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Hi all!
Pier is using Seaside File Libraries (PRPierLibrary) to store CSS and
images for the look'n'feel. Using a small extension that I just
committed it is now very easy to change the look'n'feel by just changing
the file library to another one.
Name: Pier-Seaside-cw.107
Author: cw
Time: 26 December 2006, 12:56:04 pm
After loading this patch a variable will be available in the seaside
config that allows you to change the default File Library to any other
you need to provide before (any subclass of WAFileLibrary is available).
This way the look'n'feel may be changed on-the-fly and you may store
your own File Library with your CSS and image files in a repository of
your choice.
Good night!
Chris
--
--------------------------------
Christoph Wysseier
Länggassstr. 74
3012 Bern
T +41 31 972 92 08
M +41 78 616 35 35
chris(a)wysseier.net
--------------------------------
>> May I suggest that you remove #asString from UndefinedObject and
>> replace all #asString
>> sends by #displayString in Magritte. Once you have an inventory of
>> all these replacements,
>> you will just need to apply them to the Squeak package and do
>> another port. I found about
>> 15 occurences of #asString sends in Magritte. Of course this would
>> have to be
>> negotiated with Lukas. That's why I copied him.
>
> I seem to be haunted by #asString in every Smalltalk dialect I come
> across. In my real life (a VisualAge/GemStone/ObjectStudio shop),
> we've adopted #displayString as well. While I'm willing to make
> that change, I'd certainly prefer it if we could prevail upon Lukas
> to do it, if only to avoid coordination issues.
The problem here is that this will turn the Magritte-Core package
dependent on the Seaside package, because it already defines
#displayString. Otherwise I don't see a problem to adopt this in the
Squeak Code.
>> 2) Among others, the Seaside-VW bundle includes bundle Squeak.
>> This bundle is intended
>> to group all extensions that are needed by VisualWorks to look
>> like Squeak. It is used by
>> Seaside but can be used by any project that is ported from Squeak.
>> I could see that your
>> Magritte port contains a lot of extensions that would be better
>> placed in the Squeak bundle.
>> May I propose the following. I can create a version of the Squeak
>> and Seaside bundles in
>> the public store with as many as poissible of the Squeak
>> extensions needed by Magritte.
>> When it is ready, I let you know, then you will be able to remove
>> the extensions from your
>> Magritte port.
>
> I'm quite happy to go this route. I was getting a little dismayed
> at the number of Squeak-isms that I had to implement for the port,
> and any work done getting them out of the Magritte package will
> help other porting efforts.
If you have any idea to reduce these I am happy to accept patches.
> A question for Lukas: I came across the use of
> SystemChangeNotifier in Magritte. I ended up either removing or no-
> oping operations related to it. Is there something I'm losing as a
> result? I couldn't find any uses outside of Magritte that didn't
> appear to be related to the development environment itself.
There are two uses of SystemChangeNotifier, they should be probably
moved to the MACompatiblity class.
1. MAAutoSelectorAccessorTest: this one is only needed to prevent
from marking the test-package dirty as this tests adds/removes i-vars/
accessors.
2. MADescriptionBuilder: this one makes sure that the description
cache is flushed whenever a description method is changed/added/removed.
The first one isn't critical, as this is only a tweak to make the
test run clean. The second one is more critical, without it you need
to flush the description cache manually by executing
MADescriptionBuilder default flush
There were some concerns in the beginning that rebuilding those
descriptions over and over again is very costly, therefor I added the
caching. I don't know if this is still relevant. Probably it hurts
more than it helps, but we have to check.
> Lukas, I've uncovered a small bug in MAReportComponent. While the
> #renderContentOn: method calls #labelId, that method is not
> implemented in the class hierarchy. I'm not sure if the
> implementation from MAElementComponent should be moved up, or if
> something else was intended for the report hierarchy. For
> reference, this is in package Magritte-Seaside-pmm.206.
I think this change was introduced by the latest change of Philippe,
maybe he can have a look?
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
