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