Hi Pavel,
> there are some missing classes in the latest published version of
> Magritte. MAUnlimited class >> initialize fails because classes
> M2PositiveUnlimited and M2NegativeUnlimited don't exist.
thanks for reporting, this issue should be fixed with the latest
commit. These changes are not used yet, it is just a first step
towards propre multiplicities. The latest commit also contains a
change that avoids recursion when validating recursive graphs,
however it is untested for now.
> If you'll agree, I would like to prepare Magritte and Pier for
> translation into other languages. That means mostly simple adding the
> #translated messages to string literals but in some cases it will be
> more complicated.
I don't think that is a good idea for two reasons:
1. The #translated mechanism is specific to Squeak and wouldn't work
with the ports to other dialects.
2. The #translated mechanism is global to an image. We have several
web applications using Magritte where the language (german, french,
italien, english) is defined per session and can be even switched on
the fly. I don't see how that would work with #translated?
Please correct me if I misunderstood your proposal.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
hi
in one of my application I have an object that represent a
bibliographic entry.
I has a set of fields that really depends on the type of the entry.
An article will have different fields than a journal....
Now how could I use magritte to describe such object.
Should I have a dictionary that returns MAdefinition at the object
level (the table could be shared between all the instances
of the classes.
Stef
Hi,
I have a problem with infinite recursion in Magritte. This
problem was discussed on this list before. The problem is
having circular dependencies in descriptions.
I tried to utilize the hints from Lukas to use
reference: (MADynamicObject on: (MyObject
descriptionsWithoutReferences))
Having a descriptionsWithoutReferences introduces an infinite
loop by itself. So I changed it to getDescriptionsWithoutReferences.
This prevents the infinite recursion but doesn't work really
well with the ActiveRecord implementation from Ramon (at least
in my case).
So I decided to change Magritte not to do infinite recursion. I
changed
MADescriptionBuilder>>for: anObject
^ cache at: anObject ifAbsent: [
cache at: anObject put: true.
cache at: anObject put: (self build: anObject).
].
I know this looks very ugly but I don't have an idea how to do
this more elegant. My question is if this change introduces
problems elsewhere in Magritte? I don't like to fix one problem
by creating another one :)
thanks,
Norbert
Hi Lukas,
Please have a look at
http://smallwiki.unibe.ch/moose/mseformat/
there are three links on resources which are not rendered as HTML
links. For each link an MSE file has been uploaded, but after
successful upload the link just showed up as text.
cheers,
-- Adrian
Hello everyone,
I'm working on a widget that could display the complete structure of Pier
(actually based on something like PRTreeWidget). The widget is here for
displaying purpose and it instanciates a visitor which walk over the
structure and gather the information. I assume that I need this visitor if I
want
to achieve my goal but a question remains: what if I want to list
every piece of content like images,...?
For example, I have a page with an image and my widget shows:
a PRDocument
PRInternalLink
PRText
How can I know if there is an image here? In other words how could I display
more details?
Cheers,
Sébastien
Hi Eric,
> I am looking into using Pier just so that I can use a wiki based on
> Smalltalk and get more experience with it (Pier and Smalltalk). My
> question is based on the persistence... it seems all of the data is
> being saved in the image. Is there any 'safe usage' suggestions?
> Or do I just save the image from time to time? I noticed there was
> a magma backend, and I was curious as to whether one could start
> out with using the image for persistence and later move to magma?
> I'm thinking of this, as I just don't want to start with magma
> (yet). One step at a time. Do you have any suggestions or tips
> for persisting the data safely? (Just don't want to lose
> everything I put in it)
please check the mailing list archive, there has been a lot of
discussion on this topic.
Personally I use the image persistency for all my running instances,
and it works well so far. Of course there is also a certain danger,
if you don't have backups and screw up your image. With OSProcess
loaded the snapshots are taken in a forked instance of the vm, doing
the whole thing transparently in the background.
The magma persistency is certainly very interesting, but I don't know
if it works with the latest version of Pier. As far as I know the
Magma persistency can be activated later on as well, but you have to
ask Keith, the author of this plug-in.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
> What are the odds of getting the code you use for doing the image
> persistancy with OSProcess? (Or is that already in Pier)
Yes, it is already in Pier. You just have to load OSProcess from
SqueakMap and use an Unix VM.
Cheers,
Lukas
>
> :-)
>
> Cheers,
>
> Brian
>
> On Feb 8, 2007, at 1:06 PM, Lukas Renggli wrote:
>
>> Hi Eric,
>>
>>> I am looking into using Pier just so that I can use a wiki based on
>>> Smalltalk and get more experience with it (Pier and Smalltalk). My
>>> question is based on the persistence... it seems all of the data is
>>> being saved in the image. Is there any 'safe usage' suggestions?
>>> Or do I just save the image from time to time? I noticed there was
>>> a magma backend, and I was curious as to whether one could start
>>> out with using the image for persistence and later move to magma?
>>> I'm thinking of this, as I just don't want to start with magma
>>> (yet). One step at a time. Do you have any suggestions or tips
>>> for persisting the data safely? (Just don't want to lose
>>> everything I put in it)
>>
>> please check the mailing list archive, there has been a lot of
>> discussion on this topic.
>>
>> Personally I use the image persistency for all my running instances,
>> and it works well so far. Of course there is also a certain danger,
>> if you don't have backups and screw up your image. With OSProcess
>> loaded the snapshots are taken in a forked instance of the vm, doing
>> the whole thing transparently in the background.
>>
>> The magma persistency is certainly very interesting, but I don't know
>> if it works with the latest version of Pier. As far as I know the
>> Magma persistency can be activated later on as well, but you have to
>> ask Keith, the author of this plug-in.
>>
>> Cheers,
>> Lukas
>>
>> --
>> Lukas Renggli
>> http://www.lukas-renggli.ch
>>
>>
>>
>> _______________________________________________
>> SmallWiki, Magritte, Pier and Related Tools ...
>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>
--
Lukas Renggli
http://www.lukas-renggli.ch
I'm playing with porting an existing model driven application to
magritte and I'm hitting very frequent conflicts on the method name
#description. I would urge you to change this in the future to
something less generic like modelDescription.
Just sharing my pain. :-)
-Todd Blanchard
Hello all,
I have been working with Pier a bit lately, and I noticed a couple of things
I was curious about.
First, in my image, if you go to a page and then go to lunch, come back and
hour later and click a link you get dropped back to the front page because
your session has expired. But I thought Pier used the URL to be able
bookmark, surf the side via URL etc. In fact, I thought it even worked this
way before I put the security package in.
Has this been fixed? It seems like if you click on a link that has a URL,
but an old session Pier could just make a new session and apply that to the
page the user is trying to go to. If the user is not allowed to see that
resource with the blank session then kick them back to the front like now,
but if the page is not restricted they should see it.
Second, is there any plan to expand on the RESTfulness of Pier? I mean, I'm
not a die-hard REST person or anything, but there are times it would be nice
to use URL's. I think the above suggested handling would probably be
enough.
One thing that makes me want this is the difficulty of pointing to another
page in your Pier site from a custom component. I know you have the #goto:
message on anchor, but (1) I need it anywhere a URL could be used, since I
am using "html tag:" to do some tags not in seaside (an HTML image map to be
specific). And (2) the #goto: message expects a structure that can be tough
to get a hold of sometimes. The easiest thing for me would be if I could
simply point my image map at the URL as a string, since that part is public
and I don't care if the user is logged in or not.
And lastly, I have had some users complain about the ugly URL's. I know you
can say that they shouldn't look at the URL, etc. etc., but if we can make
this better why not?
What I was thinking was, how hard would it be to change Pier so that the URL
part stays, but at least the session (and maybe the command and view fields
as well) could optionally be cookies. And this could even be something
configured in the /seaside/config/pier page.
Thanks in advance. You may have ways to do all these things by now, but I
thought I would check.
Jason
_________________________________________________________________
Valentines Day -- Shop for gifts that spell L-O-V-E at MSN Shopping
http://shopping.msn.com/content/shp/?ctId=8323,ptnrid=37,ptnrdata=24095&tco…
Hi,
I have a question about PRReportView.
In Pier-Seaside-lr.125, PRReportView reveals all contents for any user.
PRReportView>>buildStructures
^ self context enumerator all contents
I think that the pages which are prohibited for the user should not be
reported. So that, the code will be modifyed like this.
PRReportView>>buildStructures
^ Array
streamContents: [:stream | self context structure enumerator all
do: [:each | (each isValidCommand: self context command class in: self context)
ifTrue: [stream nextPut: each]]]
-- !
Koji Yokokawa <koubo2006(a)yengawa.jpn.org>
http://yengawa.com/
^self new!
