Hello,
When I switch my pier 2 website to use session cookies I get nice restful
URL's. Only there is a question mark behind the URL even if there are no
query parameters.
I tracked this down to the WUrl>>purgeSeasideFields method. The question
marks disappears when I change the method to:
purgeSeasideFields
self queryFields keys do: [ :each |
(self isSeasideField: each)
ifTrue: [
self queryFields removeKey: each ifAbsent: [ ].
self queryFields isEmpty
ifTrue: [ self queryFields: nil ] ] ]
It is also possible to change the WAUrl>>encodeOn: method to check for an
empty queryFields collection.
Jan.
Hi,
I've been experimenting with the code in PRContentsWidget all day and I've
noticed that an #onAnswer callback was added for all components regardless
of whether the command was a view command or not. I experimented with only
adding the #onAnswer callback for non-view commands and all appears to
continue to function, plus a WAAnswerHandler decorator is only added when (I
presume) it's required.
Is there a reason for calling #onAnswer on view components? Do view
components sometimes #answer:?
If not I attach an mcz with my changes.
Cheers
Nick
Hi,
When I edit a structure (or perform any command), the command renders itself
in the position defined by the PRContentsWidget. Unfortunately on the site
I'm building the content is often surround by other widgets and it's not
always visually appealing to render the command 'in-place'.
I've experimented with a couple of different approaches when the command is
"aContext command isView not":
1) replacing the application's root component with a decorated component
generated from the command as:
self session presenter show: commandComponent
2) my second attempt modified the nearest ancestor with a local environment
to a more suitable "plain" environment.
Unfortunately both attempts have limitations. In the first all the
environment is lost and I've realised that in the second, environment
changes are visible to all users...
Rethinking my approach another alternative would be to goto another page for
the command and return on command completion.
Has anyone else solved a similar problem? All thoughts gratefully received
Thanks
Nick
At 13:36 26/02/2010, Lukas Renggli wrote:
>I suggest we create a new public repository called 'pieraddons2' where
>we can collect all the different plugins and extensions, and that we
>make the main repository read-only.
Good idea!
>If anybody
>else would like to commit directly to the Magritte and Pier
>repositories, please ask in the list.
I'm using Pier as a core component in a major project. I may
consequently have some patches to propose here and there. However, at
least at this point, I don't feel that it will need to commit
directly to the main repository. The integration, when found useful,
could be done by one of the main developers, after having discussed
the proposition through the list.
Regards,
Reza
Hi,
I'm using a PRTagCloudWidget and I've noticed that I'm seeing "div" appear
as popular tag - which comes from the verbatim sections of my page's
environment. I'd have thought that ideally verbatim sections shouldn't be
included in tag cloud tokenisation???
Assuming I haven't missed some simple mechanism for extracting a pages
contents without the verbatim section, I've been pondering how I'd
implement it. I can see that by creating a visitor, say
PRTagCloudTextWriter, and leaving the implementation
of PRTagCloudTextWriter>>visitVerbatim: blank the resulting text will be
free of any PRVerbatim objects. However I'm unsure how to wire it all
together. Currently PRTagCloudWidget reads a page contents via PRCase
class>>descriptionDocument which uses the PRCase>>document accessor, which
give wiki text output. My initial implementation thoughts would be:
1) add a new accessor to PRCase say cloudText (as a PRTagCloudWidget
extension)
2) PRCase>>cloudText would use PRTagCloudTextWriter to extract plain text
without PRVerbatim content
3) PRTagCloudWidget, then needs a mechanism for tagging PRCase>>cloudText as
the accessor it should use, in preference to PRCase
class>>descriptionDocument. How about introducing PRCase
class>>cloudTextdescriptionDocument (as a PRTagCloudWidget extension),
which
PRTagCloudWidget would find and realise that it should be used in preference
to PRCase class>>descriptionDocument??
Or perhaps I've missed something really simple???
Nick
At 08:59 26/02/2010, you wrote:
>Maybe using FileDirectory wasn't such a good idea in the first place.
>Maybe we should change it to a string to do a relative/absolute lookup
>from the image directory? Or, oh well, we could use the Filesystem
>framework
Thank you for your prompt response!
The current implementation works just fine. It looks like that we
just need to separate the *default base directory*, from another
*application-specific base directory*. I'd *simply* do the followings:
- Add MAExternalFileModel to the Smalltalk start-up list to ensure
that the default value gets automatically updated.
- Add an alternative class instance variable, for those applications
that would need to reference a specific directory (without automated update).
Does this make sense?
Otherwise, the issue appeared since I'm used to copy my image from a
*dev* directory to a *prod* directory, before executing my
distribution generation script (sort of "PRDistribution new
register"). I addressed the issue by simply adding to that script
*MAExternalFileModel initialize*.
Regards,
Reza
Hi,
MAExternalFileModel does not belong to the Smalltalk start-up list,
and the cached *baseDirectory* value is not updated by program.
Consequently, when a Pier image is moved from directory A to B,
PRFiles keep referencing 'A/files' instead of 'B/files'.
Has this been designed this way by purpose?
Regards,
Reza
Hi Lukas,
If I type the following in a page:
{{{""This is a bold text""}}}
I get the following after interpretation:
""This is a bold text""
Which is what I was expecting.
But, if I type the same text in a table cell as follows:
||{{{""This is a bold text""}}}|
I get the following in a table:
This is a bold text}}}
Which I wasn't expecting.
May I ask you please what I'm missing there?
Thank you in advance for your response,
Reza
Hi,
I have a container component that renders a series of subcomponents. The
number of subcomponents is based on the number children within my structure.
My initial implementation cached the components and returned the cache
within #children and iterated over the cache within #renderContentOn:.
A problem arises when I add a new child to my structure. The container
component needs to invalidate it's cache when the structure changes or once
I rendering cycle completes. I tried hooking into #initialRequest: but that
didn't seem to be called each time I visited the page. I guess I could use
Announcements but wonder if there is a simpler solution? Thanks in advance
Nick
At 17:23 23/02/2010, Lukas Renggli wrote:
>I've never used Pier-Slideshow-MMP.13, I think it is broken and should
>maybe removed form the repository?
Well, sooner or later people will need a Slideshow component for
Pier2. Since *Pier-Slideshow-lr.12* is working in Pier2 almost as it
is, I'd vote to use it as a basis for the port to Pier2, except if
somebody decides to take the responsibility to port *Pier-Slideshow-MMP.13*.
I actually had a look at *Pier-Slideshow-MMP.13*, and am not
convinced that its design is 100% percent consistent with that of
*Pier-Slideshow-lr.12*. But, there are interesting ideas that could
be integrated into *Pier-Slideshow-lr.12*. I've started some work in
this direction, but unfortunately won't have time now to finish it.
If somebody is interested in having a look at it and eventually
finish the integration and port work, please tell me to send you my package.
Regards,
Reza
