PRContentsWidget and PREditCommand
Locked
 
|
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 _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Re: PRContentsWidget and PREditCommand
|
> 2) my second attempt modified the nearest ancestor with a local environment
> to a more suitable "plain" environment. What about having two environments, one for editing (that would default to the default one) and one for viewing? Or is this what you describe above? Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
|
|
That's what I'd like to achieve, but my attempts haven't been successful. If I change the local "viewing" environment for an "editing" environment unfortunately other users will see the change, until the environment is restored. It feels like ideally I'd use a show:onAnswer or call: but for Pier pages, but I'm stuck on the implementation
Any thoughts? Nick _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Re: PRContentsWidget and PREditCommand
|
|
>> > 2) my second attempt modified the nearest ancestor with a local
>> > environment >> > to a more suitable "plain" environment. >> >> What about having two environments, one for editing (that would >> default to the default one) and one for viewing? > > That's what I'd like to achieve, but my attempts haven't been successful. > If I change the local "viewing" environment for an "editing" environment > unfortunately other users will see the change, until the environment is > restored. It feels like ideally I'd use a show:onAnswer or call: but for > Pier pages, but I'm stuck on the implementation > Any thoughts? I thought that you would store two environments in PRStructure and that PRPierFrame (or your custom subclass) would depending on the context (the command) use a different one. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
|
|
Thanks for idea of using overriding the behaviour in PRPierFrame - previously I'd struggled modifying environments in PRContentsWidget.
The solution I've finally arrived at is: 1) I've added a method to my custom kernel #editingEnvironment 2) I've overridden #environment in PRPierFrame so that it now reads:
environment | environment | (self context command isView or: [self context command isQuick]) ifTrue: [
environment := self context structure environment ] ifFalse: [ environment := self kernel editingEnvironment
]. ^ environment So much simpler than my other two attempts - thanks again
Nick _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
|
|
Hi,
I'm getting trouble to connect to a remote image using RealVNC. I get a "Connection time out" error message. The configuration is: - PharoCore1.0rc1 (Latest update: #10505) + Seaside 3 + Pier 2 + RFB-lr.13 from http://source.lukas-renggli.ch/unsorted/, I successfully launch RFBServer thanks to Seaside VNC Controller, and Pier continues serving in spite of that connection failure. However, I tried to connect to a local image using "localhost:0", but I get "Unknown rect encoding". If I ask RealVNC to retry connecting, my image freezes. Its the same after upgrading to *RFB-DamienCassou.28*. I'd greatly appreciate any feedback on this issue. Thank you in advance, Regards, Reza _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
|
|
Load the latest Seaside-Pharo-Tools-Web and the latest RBF server. I
fixed various minor problems, but it basically worked already before. Lukas On 26 February 2010 22:58, Reza RAZAVI <[hidden email]> wrote: > Hi, > > I'm getting trouble to connect to a remote image using RealVNC. I get a > "Connection time out" error message. > > The configuration is: > - PharoCore1.0rc1 (Latest update: #10505) > + Seaside 3 > + Pier 2 > + RFB-lr.13 from http://source.lukas-renggli.ch/unsorted/, > > I successfully launch RFBServer thanks to Seaside VNC Controller, and Pier > continues serving in spite of that connection failure. > > However, I tried to connect to a local image using "localhost:0", but I get > "Unknown rect encoding". If I ask RealVNC to retry connecting, my image > freezes. Its the same after upgrading to *RFB-DamienCassou.28*. > > I'd greatly appreciate any feedback on this issue. > Thank you in advance, > Regards, > Reza > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
|
|
At 10:25 27/02/2010, Lukas Renggli wrote:
>Load the latest Seaside-Pharo-Tools-Web and the latest RBF server. I >fixed various minor problems, but it basically worked already before. Thank you so mush Lukas for having considered so professionally my request! After the above upgrade, I just had once *VNC Free Edition for Windows* from RealVNC rendering correctly my image display via "localhost:0". But no interaction was possible, and my image was again frozen. Now, I'm moving my image to my experimental Linux / Debian / Apache 2.2 / Firewall server, and will give you feedback asap. Regards, Reza _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
|
|
In reply to this post by Nick
At 17:36 26/02/2010, Nick Ager wrote:
>The solution I've finally arrived at is: >1) I've added a method to my custom kernel #editingEnvironment >2) I've overridden #environment in PRPierFrame so that it now reads: > > environment >| environment | >(self context command isView or: [self context command isQuick]) ifTrue: [ >environment := self context structure environment >] ifFalse: [ >environment := self kernel editingEnvironment >]. > >^ environment Hi, I'm testing a specific type of *quick* command (#isQuick returns true). During their execution, triggered by PRContentsWidget >> onAnswerCommand:, they call other components (via #call:). My configuration is Ubuntu, Pharo, Seaside 3, and Pier2. The execution goes on smoothly when triggered via the *commands* toolbar. However, I'm experiencing an issue in the following circomstances: 1) When trying to switch the current template just before the start of the execution, using the above method by Nick. 2) When launching the command via an internal link, and only if I'm not logged in. In both cases the execution stops by the error raised in GRPharoPlatform >> seasideCallbackMarker. It is difficult to characterize the issue since its somehow contextual. But, it seems that #seasideCallbackMarker is sensitive to the components that are present in the current Pier Context. I'd greatly appreciate any feedback on this issue. Regards, Reza _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
|
|
Hi Reza,
I see my name mentioned so feel responsible :). However as I'm sure you are aware I'm no expert. For what they are worth, here are some thoughts: * seasideCallbackMarker produces the helpful error: "You can only #call: and #answer: from within a callback or a Task." So presumably you are using #call outside a callback
* PRContentWidget>>onChangeContext: handles #isQuick commands differently by directly calling the #onAnswerCommand: . Perhaps examining the call stack within onAnswerCommand in the cases where the command causes and error and when it executes successfully might highlight the difference causing the problem.
* I brought lots of trouble on myself when I experimented with some options inside PRContentsWidget and wasn't returning all the child components from PRContentsWidget>>children, but that was probably unique to me.
Hope that helps Nick
On 11 March 2010 15:14, Reza RAZAVI <[hidden email]> wrote: At 17:36 26/02/2010, Nick Ager wrote: _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
|
|
Hi Nick ,
Thank you for your kind response! At 17:46 11/03/2010, Nick Ager wrote: >* seasideCallbackMarker produces the helpful error: "You can only >#call: and #answer: from within a callback or a Task." So presumably >you are using #call outside a callback An important feature of Pier is its flexibility, in this specific case, allowing dynamic modification of templates and components. My concern could be formulated as follows: is there a context-sensitive relationship between the configuration of templates/components in Pier, and partial continuations in Seaside 3? Why it looks working only in some configurations?! Maybe its simply only related to my specific application case. I've to look at it more closely. >Perhaps examining the call stack within onAnswerCommand in the cases >where the command causes and error and when it executes successfully >might highlight the difference causing the problem. Good idea. Will try it asap. Any other thoughts would be very welcome. Regards, Reza _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
|
|
Another quick thought. Given the environment switching code you're using, if the command changes from an #isQuick command to non-viewing command then environment will change. The value of #environment is used during rendering and also indirectly in call to #children. If there's a mismatch between the environment used within a rendering-callback cycle that's going to confuse Seaside when it processes the callbacks.
Nick _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
|
|
At 21:48 11/03/2010, Nick Ager wrote:
>If there's a mismatch between the environment used within a >rendering-callback cycle that's going to confuse Seaside when it >processes the callbacks. That sounds a very good point too; thanks Nick! I've to look at what happens more closely, since now I've some clicks "lost", in the sense that when I push the command's link, its execution is not visible, although launched. I know that the execution is launched, since I tracked this down to GRPharoPlatform >> seasideCallbackMarker (as said before, the execution of this command includes calls to other components). It appears that in theses cases, #seasideCallbackMarker finds and returns a context, that of PRContext >> activationCallback. However, the #call: remains ineffective in the sense that the control is not passed to the new component!? Later, Regards, Reza _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
«
Return to Magritte, Pier and Related Tools
|
1 view|%1 views
| Free forum by Nabble | Edit this page |