At 09:42 21/02/2010, you wrote:
>I've fixed that as well.
Hi Lukas,
Please note that there are other minor rendering
issues since you added PRVerbatim. Here are two examples:
1) I had a blog post with html markups inside as
follows: <b>some text</b>. Before verbatim, I was
getting *some text* in bold as expected. Now, I get <b>some text</b>.
2) In my experimental distribution, I instantiate
a book with the following title in French:
book title: 'Maintien et développement de la qualité de l''enseignement';
Now, if I try to remove the book node, here is what happens:
2.a) *PRRemoveCommand >> confirmation* generates the following wiki string:
'!Do you really want to remove ''Maintien et
développement de la qualité de l''''enseignement''?
There are 8 child structures:
# */book/table-of-contents*
# */book/table-of-figures*
# */book/index*
# */book/introduction*
There is 1 incoming reference:
# */system/menu*
'
2.b) The above wiki text is parsed by
PRDocumentParser, but rendered verbatim, exactly
as above, and is not interpreted (specifically,
the internal links do not appear).
However, the issue disappears when I remove
*l''enseignement* from the title. It is then
certainly related to the double ' in that French word.
Regards,
Reza
Hi,
In a couple of places in my app I found that I was writing in effect a
detect: method using PREnumberableVisitor>>do. So I thought I'd add detect:
to PREnumberableVisitor which makes the intent of my code much clearer.
Would this be useful addition generally? I've attached an mcz of
the PREnumberableVisitor additions and another of tests to exercise the
additions.
Nick
Hi Lukas,
I also uploaded *Pier-Setup-razavi_acm_org.80* that fixes a minor
issue with PRBookDistribution. For more info, please see that package
and its comments.
Additionally, I'd like your attention to:
- The fact that * Pier-Book-lr.138* calls in several places
#trimBlanks, specifically in BOLatexWriter and BONote, while my Pharo
image does not contain this method and consequently the execution fails.
- The two other minor issues exposed in an email sent a few days ago,
and reproduced below.
Regards,
Reza
>Date: Tue, 16 Feb 2010 17:47:56 +0100
>To: "Magritte, Pier and Related Tools ..." <smallwiki(a)iam.unibe.ch>
>From: Reza RAZAVI <razavi(a)acm.org>
>Subject: Book navigation rendering issue report
>
>Hi,
>
>After having upgraded to the latest Seaside 3 and Pier 2 packages, I
>encounter a minor issue that could be regenerated as follows:
>1) Evaluate in a workspace "PRBookDistribution new register"
>2) Point to http://localhost:8080/pier/book/table-of-contents
>
>The navigation arrows are not rendered anymore. Instead, appear
>their textual encoding (&rarr and &larr). It is the same for
>non-breaking space that appears as   (See for example
>http://localhost:8080/pier/book), as well as other codifications like §.
>
>Otherwise, I was wondering if in:
> BOLatexWriter >> convertHtmlEntities:
>
>the following:
> copyReplaceAll: '→' with: '<-'
>
>shouldn't be rather:
> copyReplaceAll: '→' with: '->'
>
>Cheers,
>Reza
In the MARelationDescription it is possible to specify a variety of target clases that can be used. If I have more than one I cannot set the reference at the same time. This gives me trouble using MAExternalEditorComponent.
Shouldn't
MARelationComponent>>editorFor: anObject
^ (self description reference asComponentOn: anObject)
addValidatedForm;
yourself
be rather
MARelationComponent>>editorFor: anObject
^ (anObject description asComponentOn: anObject)
addValidatedForm;
yourself
?
Norbert
At 21:14 20/02/2010, you wrote:
>That's not how the one-click images are setup, thus I would prefer if
>you created your own package.
I just uploaded AAS-Pier-Widget Adaptors that:
- Adds a new *system administration* toolbar, which contains the
*widget adaptor commands*, and is only accessible to the *master* user.
- Moves all toolbars to the top of the page (instead of the bottom).
- Patches Pier code to add a Close button to system administration widgets.
May I ask you please to remove from your repository the deprecated
"AAS- Pier Commands-Widget Adaptors".
>673.
Great work; thanks for the information.
Regards,
Reza
Hi Lukas,
Thanks again for your time and precisions!
At 12:23 20/02/2010, Lukas Renggli wrote:
>Did you press 'refresh' to see the change?
No.
>Just hitting the back
>button only shows you the page from the browser cache.
Just double checked it, and you are perfectly right. The new value is
maintained. What I observed when using the back button was the value
cached by the browser.
>Maybe there are other setups where that might make sense?
Sure. For example, for practical reasons, I've preferred replacing
the *management* page with a specific *admin toolbar*, which is
actually only accessible to the *root* (and not users with *admin* rights).
>That's why I
>suggested to package the wrappers separately.
There is some progress in that direction, but some extra work is
necessary. The first package that I posted lacks usage examples. The
2nd package addresses this issue, but patches PRDistribution. Now,
I'm going to sub-class PRDistribution. However, before posting the
final package, would you please tell me your preference for one of
the followings:
1) The warper commands and the new distribution class integrated in
Pier-Setup as package.
2) The warper commands and the new distribution class integrated in a
new package.
I'd prefer the first one to avoid an additional package for a piece
of code that addresses basically the same needs than "Pier-Setup".
>If anywhere -- on potentially thousands of pages (like in the seaside
>book)
That's an interesting use case indeed. Would it be possible to
communicate more precisely the number of Pier structures that
contains Seaside book (just curious)?
> -- you (accidentally) give the permissions to edit the kernel
>name, anybody is able to change it. In the current default setup you
>just have to make sure that the system page and its children are
>protected.
Well noted; thanks for the precision. In my current experimental
distribution, I've addressed this issue as follows:
1) Added a "root" user (called *master*), and
2) Overridden PRCommand class >> #valideIn: for wrapper widgets to
return true only if the current user is master (and not superusers).
Regards,
Reza
Hi,
I noticed that the help button on the enhanced editor was broken in
Pier/Seaside 3.0. I've attached a simple fix, though as I don't entirely
understand the intent of the implementation, it would be good if someone can
review it to check the bug shouldn't be fixed elsewhere.
Nick
At 09:48 20/02/2010, Lukas Renggli wrote:
>That's a bug, I've seen that too at some time, but never managed to
>reliably reproduce.
It looks like being related to a mismatch between the actual and
cached values in MAMultipleOptionDescription >> validateKind:. I
don't have the exact context within within the bug appears, but was
wondering if it could be caused by MADynamicObject.
Hi Lukas,
Thanks for your feedback!
At 22:14 18/02/2010, Lukas Renggli wrote:
>I think that makes a good addition to Pier as an extension.
I understand your choice, and I'd basically do the same. However, let
me emphasize that I decided to develop this as an alternative to
http://localhost:8080/pier/system/management, which is proposed as a
default solution in PRDistribution, since I had two issues with that tool page:
1) 'Save' and 'Cancel' buttons in that page have a somehow
non-standard behavior.
2) To close that page, I only found the following two options:
(a) close the page
(b) use the back button
I had an issue with (a) since I simply wanted to keep using my page.
Option (b) undos your modifications, since Seaside backtracks the state.
This could be tested easily. For example:
- In "Kernel Settings" just rename the Kernel from "Pier" to "Pier2"
- Push the "Save" button. The kernel is modified and the page title
changes from "Pier" to "Pier2"
- Push the back button (actually twice, in this specific example) to
quite the page. Seaside brings back the previous Kernel named "Pier".
This is obviously not what we wanted. Am I missing something here?
>I don't
>feel like adding it to Pier-Seasde though, as commands are normally
>designed to work on a specific structures.
Yes, this mismatch is in fact a concern, although, the WtC adaptor
refers too to a structure (the dummy PRComponent created by
#widgetHolder, which is not the current structure). But, in my case,
the practical benefit justifies a kind of conceptual compromise.
>The widgets you wrapped do
>work on the complete system though.
You are right. To make this difference explicit, I'm actually making
these widget adaptors available in a separate toolbar, that looks like this:
PRDistribution >> admintoolsPage
admintoolsPage ifNotNil: [^admintoolsPage].
adminComp := PRComponent named: 'widget'.
adminComp
componentClass: PRCommandsWidget;
write: AAsWidgetAdaptorCommand allSubclasses using:
PRCommandsWidget descriptionCommandClasses.
admintoolsPage:= (PRPage named: 'admintools')
addChild: adminComp;
contents: 'Admin tools: +widget+';
yourself.
^admintoolsPage
This assumes that those widget adaptors are additionally excluded
from #commandsPage.
>Also your strategy of wrapping the
>widgets into commands makes security sort of fragile.
This is an important issue. Could you develop this a little more please?
As far as the current widget adaptor commands are concerned, the
security is the same as the management page: the are only available
to admin users. Additionally, Pier allows reenforcing this policy
quite easily, for example, by attaching specific permissions to the
admintoolsPage proposed above. Won't this suffice?
>Maybe better write
>a short mail to the list explaining the change,
Sure; well noted.
Regards,
Reza
