Hello Lukas,
It appears that embedding a PRChildren component is broken. This is a
little tricky to explain.
At the point of visiting the embedded component visitInternalLinkEmbed:
anObject
the context's structure is correct, namely the parent structure being
displayed. ie. PRCurrentContext value structure.
By the time it obtains the structure from which to collect the
child-items, this structure may be something else entirely.
So it appears that the PRChildren component being used is one that was
cached, and this cached widget has itself cached the #context. I.e. the
old context that it had when it was origianlly cached, not the current
one in which it is being displayed.
I have posted my solution for this...
Name: Pier-Seaside-kph.213
Author: kph
Time: 20 October 2007, 9:24:28 pm
UUID: 75264720-7f4a-11dc-a343-000a95edb42a
Ancestors: Pier-Seaside-lr.212
- fixed typo 'Highlight' labels
- components obtained from a contexts componentDictionary cache have an
obsolete context cached in their #context
cheers
Keith
All,
Pier certainly has a lot of features that the previous version was
lacking, however sometimes plain is more appealing. Has anyone setup
pier to look like Smallwiki? Using the same style sheets didn't fill
the bill, and I could probably figure out how to change
PRPierLibrary>>styleCss to make it look similar; but if someone has
already done this, I'll appreciate the help.
Thanks,
John
Hello all,
In Ramon's blog [1] he mentions:
"When creating a description for that collection, I can specify my
custom #accessor: rather than using the default #selectorAccessor:
which then writes to my domain object with #addUser: and
#removeUser:."
Looking at the code, I don't see how this is done. Isn't the write
accessor going to get a complete collection? Is the idea to just diff
the received collection from the one the object had and make calls to
#add and #remove as appropriate, or is there a way to only be told
about the new objects in the collection?
Thanks,
Jason
[1] http://onsmalltalk.com/programming/smalltalk/using-magritte-with-seaside/
Hi all,
I have a situation that brings up a couple of questions.
I have 2 classes which have a class side variable which keeps track of
the instances created (much like how Pier's PRKernel works). As a
consequence, I need these objects to be instantiated, not with #new,
but with a special message (e.g. #named:).
The second part of the equation is that, while these two classes have
their own Magritte definitions and can display themselves, there is a
"main site" component that displays all the instances from these two
classes, as options for the user. So this puts me in a situation
where the main site class needs to have descriptions
(MAToManyDescription I believe) that reference the other two objects
(i.e. the main site class wont have any instVars for these). And for
added fun, this class has a class side method named #description for
the Seaside framework.
Now, I think the issue with the main site is not so bad, I would just
define my #description methods as normal, right? Since #description
is taken already I guess I have to override it on the instance side
and call MANamedBuilder for: myself?
And the other question is, how do I enforce that when Magritte wants
to make a new instance of these other two classes that it uses my
custom constructor, not #new? Since the custom constructor is going
to expect a portion of the data already, I'm guessing I need some kind
of Memento? I suppose I could just let it create the object with new,
and then have the accessor create the "real" object from this, but
that seems very cheesy.
Thanks for any help you can provide,
Jason
hi -
I'm trying to embed a pier-blog in a vanilla pier page, using
variations of +myblog+, but that only embeds the description of the
blog -- not a view of the latest blog entries. Any simple trick?
thanks,
ts
Does MANullAccessor have to be so so... erm unusable?
If you happen to use it nothing seems to work with it.
i.e. accessor selector doesnt work, one should argue that it shouldnt,
but is it doing a good job of being a null?
Most users of read: dont test canRead: first.
I am thinking of implementing a subclass MADummyAccessor which does
implement read: just so as it can play with the other accessors in
mementos etc.
I just wondered if there was a case for making MANullAccessor more
friendly, i.e. swap its behaviour from pessimistic to optimistic, rather
than expecting all users to test canRead: first, expect those users that
really care to test cantRead:
just an idea
Keith
hi -
How does one make a widget appear only if a certain user is logged in?
How would one for instance make the 'views' box appear only if the
admin user is logged in?
(Is there a place I could have found the answer? I read the docs I
found and browsed the archives, but didn't find anything. I'm working
my way to the relevant place in the code, but a nudge would be
useful.)
thanks,
ts
In magritte MAUnlimited is a subclass of Magnitude, since MAUnlimited is
either a Unlimited Positive, or Unlimited negative and since it overrides
#adaptToNumber: andSend:, is there a reason why it shouldnt be a subclass of
Number rather than a subclass of Magnitude. it might make it easier for me
if i made MAUnlimited subclass of number instead of Magnitude in the
GemStone/s version.
thanks
Isaiah
--
View this message in context: http://www.nabble.com/Magritte-MAUnlimited-tf4606754.html#a13154302
Sent from the SmallWiki mailing list archive at Nabble.com.
