Hi,
I was totally confused about my blog today. I always
expected that people can comment on blog posts. Having
a look today first showed that there was no entry form
for entering a comment.
I started to fiddle around with the permissions on the
blog page but this was kinda strange. As soon as I added
the "Add commment" permission to others a link "add"
was added at the bottom beside login and view. Clicking
on the link opened the normal add command that would
let me add post, component,...
Removing the permission again removed the link again. I
know this sounds strange and I'm also sure that it is
probably not what really happened.
Now it is so that only the first post has the comment
add form and no other post. Well, it is the only one
in this month so it could also be that. Aren't all blog
post supposed to be commentable?
thanks,
Norbert
Hello to all,
I'm involved in a project which uses the Pier wiki. We hope that this
project will have mass appeal and involve many users. Unfortunately,
we've seen a problem with the edit box. If one pastes something from a
non-UTF-8 compatible world processor, it is rejected with an error
message reading, "Input is Invalid." Unfortunately, this is not a very
helpful error message, and it will make using the Pier wiki impossible
for those of us who aren't at least mid-level geeks. Would it be
possible to make some changes which would allow a more user-friendly
error message?
I see two possible ways to handle this.
1.) Replace the current message with a message that reads, "Your input
cannot be read because it is not UTF-8 compatible. Please set your
word-processor to produce UTF-8 compatible text and try pasting your
input again." Such an error message could even connect to Pier's help
system which could explain how to set various word-processors for UTF-8.
I'm not a Squeak programmer, but I'd be happy to write help text for the
word processing programs I own.
2.) The second is to devise a more forgiving edit window. Instead of
giving an error message and rejecting the input, it could accept the
input and replace characters it can't read with a question mark, or one
of those square boxes, then output an error message, something like:
"There was a problem reading your input because your word processor is
not set to UTF-8. Characters which could not be read have been replaced
with a "?". Please click here to continue." I think this is the better
of the two alternatives, though obviously it involves more programming time.
A more sophisticated version of the second solution could present users
with a small, pop-up edit box containing the text that is causing
problems. The users could then use their keyboards to make the
appropriate changes.
As things stand now, the edit box is very "user-unfriendly." I don't, of
course, insist that my solutions be used - it's entirely possible that a
better way exists than I imagine above - but the present situation will
make things very difficult for users who don't have serious computing
skills.
Thanks in advance for any help you can offer.
Alex
> GemStone can't migrate an object that is on the stack (as a receiver), this means that the normal Magritte mechanism for creating variables doesn't work in GemStone...callers of readUsing: ... the solution for GemStone is to flip the logic:
I don't understand the problem. As far as I understand this only
appears when the MAAutoSelectorAccessor is used. Magritte itself (with
the exception of the respective test case) and Pier does not make use
of this functionality.
Personally I never use MAAutoSelectorAccessor, I rather use the
refactoring tools. If nobody opposes I would propose to remove it?
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
Hi all,
I made 2 small changes to the add-on Pier-Twitter so the "agoString" is
properly calculated for timezones with offsets other than 0 from UTC.
I've posted the mcz file here: http://drop.io/Pier_Twitter_jtr_10
Hopefully it's properly done as I've not used Monticello before other
than to load stuff into Squeak. Be sure to let me know if this should be
handled in a different manner in the future.
Take care,
John
Hi,
I asked some moons ago about the possibility to have parameterized
component links. I'm not that familiar with pier so my solution to this
might be a bit cheesy.
I wanted to have for multiple reason the ability to do
+mycomponent1|key=value+
to parameterize a component at rendering time. The problem is
that the string is parsed to a link and the link has the parameters.
So the question is how the component gets notice of these. The
last possible call to do I recognized to be
PRViewRenderer>>visitInternalLinkEmbed:
I added the following to it at the beginning
(anObject target isComponent) ifTrue: [
anObject parameters do: [:each|
(self context componentAt: anObject target) propertyAt: each
key put: each value.
]
].
So I just copy all the parameters over to the component. I found
that PRComponent has already properties so I'm using these. Is this
feasible to do? Is there a better way to do? Can this be added to
pier?
I use this for two scenarios:
- advising a component what type it should filter
- to select a child component from a Magritte container (not done, yet)
thanks,
Norbert
----- "Lukas Renggli" <renggli(a)gmail.com> wrote:
|
| > I ask, because I have had to make GemStone-specific changes to some
| of the packages, so it's not quite as easy as just loading the newer
| versions of the packages...
|
| What are these issues? If possible I would like to make this easier.
| Especially if Pier moves towards Seaside 2.9, I would like to package
| all platform dependent code separately.
The list isn't real big (i'd have to do a diff to get the little changes), but the main change that I'm thinking/worried about is actually a Magritte issue that overflows into Pier.
GemStone can't migrate an object that is on the stack (as a receiver), this means that the normal Magritte mechanism for creating variables doesn't work in GemStone...callers of readUsing: ... the solution for GemStone is to flip the logic:
if an 'object readUsing: aDescription' fails with an ErrCantBecomeSelfOnStack error, because object is a receiver on the stack, I retry doing 'aDescription accessor read: object'...object isn't on the stack so the migrate succeeds ... unfortunately there are a number of places where I have to insert GemStone-specific code ... in Magritte and Pier ... doing anything else would have been even more intrusive and probably broken a ton of code to boot...
Offhand there are probably only 20 methods affected but they are sprinkled around the system...
Dale
Hi,
I try to figure out how to organize my environments in
pier. In one area of the site I need only to exchange
one single component per navigation level. I'm looking
for a way to only specify the environment on the top
most node.
The structure value link is one thing that might solve
this problem. Is there a way to add something to the
structure that the value link resolved? Then I could
specify something like this
+value:structure/neighbours+
to resolve a neighbours entry local to the seen page.
This way I can have a more heavy weight environment on
the top and would just specify neighbours entries on
each page.
Or is there another way to accomplish the same?
thanks,
Norbert
----- "Lukas Renggli" <renggli(a)gmail.com> wrote:
| > I had anoter look and Pier-Documents in my gemstone is
| >
| > Pier-Documents-lr.12
| >
| > from
| >
| > http://source.lukas-renggli.ch/pieraddons
| >
| > That is strange. I upgrade to -lr.14 but it doesn't work.
| > Probably I would need a magritte update for parameterName: ?
| > And renderInstance? I saw in PRHaloRenderer but nowhere
| > else.
|
| Yes. This requires you to update to the very latest versions of
| Magritte-Core, Magritte-Seaside, Pier-Core and Pier-Seaside.
|
Lukas,
Are these updates part of Pier 1.1.1 (which is what I moved to with GLASS.230-dkh.209)? At the time I moved to 1.1.1 I used the 1.1.1 image that was distributed - at the time there were later versions of some of the packages, but I was reluctant to load packages that may be meant to be part of the release...
Is there a later version of Pier available (later than 1.1.1)?
I ask, because I have had to make GemStone-specific changes to some of the packages, so it's not quite as easy as just loading the newer versions of the packages...
Dale
Hi,
I'm still trying to change my application that is pure seaside
to pier. I need to keep the layout of the page that means I
need some control over the markup created. On the other hand
I want to be able to "document" components that means to be
able to put some text before and/or after the component.
So imagine a page that contains three components. I want to
do some specific markup for the layout of these components.
And at the same time I want to be able to press edit and write
some help text above component No. 2.
Regarding layout I would need to do HTML markup. Can a pier
page be enriched by HTML markup? Or is this possible by
tweaking the environment? As far as I understand it the
contents component in an environment determines the place
in the tree where the page is rendered into. Can you have
more than one in an environment?
thanks,
Norbert
Hi!
I need to do the typical "Contact Us" form where the user can put the name
the email and the question and then this email to the webmaster email
account.
I look there was a Pier-EmailSender which seems to do what I need. However
It has different walkbacks in Pier 1.1.1.
Keith Hodges: do you think it's rather to make it work that doing my own ?
It is very simple to reproduce. Just open a fresh Pier 1.1.1 and add that
widget.
Thanks!!
Mariano
