Configurable current request context variable
Locked
12
12
 
|
Hi,
I would like to use a current request context variable that inherits from DynamicVariable in Pharo and not from WADynamicVariable (I don't want to use the exception mechanism). Hence, I'd like to propose that the current request context variable be made configurable through the configuration mechanism. WACurrentRequestContext could dispatch to the concrete variable to ensure backwards compatibility, e.g. WACurrentRequestContext>>value ^ self concreteVariable value (WACurrentRequestContext would no longer inherit from WADynamicVariable and have a default variable, e.g. WAConcreteCurrentRequestContext. Sorry for the bad name :) ). If no one objects, I can implement the change (I'll probably need contributor access). I'm looking forward to comments. Cheers, Max _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: Configurable current request context variable
|
|
On Sat, May 6, 2017 at 5:34 PM, Max Leske <[hidden email]> wrote:
> Hi, > > I would like to use a current request context variable that inherits from DynamicVariable in Pharo and not from WADynamicVariable (I don't want to use the exception mechanism). Can you provide a bit more context? How is it implemented in Pharo? To with Pharo versions does this apply? Cheers Philippe _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
> On 6 May 2017, at 20:04, Philippe Marschall <[hidden email]> wrote: > > On Sat, May 6, 2017 at 5:34 PM, Max Leske <[hidden email]> wrote: >> Hi, >> >> I would like to use a current request context variable that inherits from DynamicVariable in Pharo and not from WADynamicVariable (I don't want to use the exception mechanism). > > Can you provide a bit more context? How is it implemented in Pharo? To > with Pharo versions does this apply? Sure. DynamicVariables are stored in the environment of the process. They are singletons and the sole instance is used as the lookup key into the process environment dictionary. The access semantics are nearly identical to WADynamicVariable, so they can easily be exchanged. There are two advantages over WADynamicVariable: 1. Access time is constant and no handler context is required 2. The process environment can easily be copied, making it possible to transfer availability of a request context to a different process, e.g. for debugging (I've done that for our own apps in Seaside 2.8) DynamicVariable has been in Pharo at least since version 1.1.1. and I have been using it in production as a replacement for WACurrentSession from Seaside 2.8 for about two years now. Cheers, Max > > Cheers > Philippe > _______________________________________________ > seaside-dev mailing list > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: Configurable current request context variable
|
|
On Sun, May 7, 2017 at 8:26 AM, Max Leske <[hidden email]> wrote:
> >> On 6 May 2017, at 20:04, Philippe Marschall <[hidden email]> wrote: >> >> On Sat, May 6, 2017 at 5:34 PM, Max Leske <[hidden email]> wrote: >>> Hi, >>> >>> I would like to use a current request context variable that inherits from DynamicVariable in Pharo and not from WADynamicVariable (I don't want to use the exception mechanism). >> >> Can you provide a bit more context? How is it implemented in Pharo? To >> with Pharo versions does this apply? > > Sure. DynamicVariables are stored in the environment of the process. They are singletons and the sole instance is used as the lookup key into the process environment dictionary. The access semantics are nearly identical to WADynamicVariable, so they can easily be exchanged. There are two advantages over WADynamicVariable: > > 1. Access time is constant and no handler context is required > 2. The process environment can easily be copied, making it possible to transfer availability of a request context to a different process, e.g. for debugging (I've done that for our own apps in Seaside 2.8) > > DynamicVariable has been in Pharo at least since version 1.1.1. and I have been using it in production as a replacement for WACurrentSession from Seaside 2.8 for about two years now. I see the need but have reservations about the implementation. We have other dynamic variables which would benefit from this as well. WADynamicVariable is supposed to be our portable dynamic variable abstraction. Do you know what the situation is in the other dialects (GS, VASt, VW) regarding dynamic variables? Do they have a DynamicVariable class as well? In theory we could say that the dialect has to provide a GRDynamicVariable, we could provide a GRExceptionBasedDynamicVariable. Dialects that have a DynamicVariable class could provide GRDynamicVariable as a subclass of DynamicVariable. Dialects that do not have a DynamicVariable class could provide GRDynamicVariable as a subclass of GRExceptionBasedDynamicVariable. Cheers Philippe _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
> On 7 May 2017, at 23:09, Philippe Marschall <[hidden email]> wrote: > > On Sun, May 7, 2017 at 8:26 AM, Max Leske <[hidden email]> wrote: >> >>> On 6 May 2017, at 20:04, Philippe Marschall <[hidden email]> wrote: >>> >>> On Sat, May 6, 2017 at 5:34 PM, Max Leske <[hidden email]> wrote: >>>> Hi, >>>> >>>> I would like to use a current request context variable that inherits from DynamicVariable in Pharo and not from WADynamicVariable (I don't want to use the exception mechanism). >>> >>> Can you provide a bit more context? How is it implemented in Pharo? To >>> with Pharo versions does this apply? >> >> Sure. DynamicVariables are stored in the environment of the process. They are singletons and the sole instance is used as the lookup key into the process environment dictionary. The access semantics are nearly identical to WADynamicVariable, so they can easily be exchanged. There are two advantages over WADynamicVariable: >> >> 1. Access time is constant and no handler context is required >> 2. The process environment can easily be copied, making it possible to transfer availability of a request context to a different process, e.g. for debugging (I've done that for our own apps in Seaside 2.8) >> >> DynamicVariable has been in Pharo at least since version 1.1.1. and I have been using it in production as a replacement for WACurrentSession from Seaside 2.8 for about two years now. > > I see the need but have reservations about the implementation. We have > other dynamic variables which would benefit from this as well. > WADynamicVariable is supposed to be our portable dynamic variable > abstraction. > Do you know what the situation is in the other dialects (GS, VASt, VW) > regarding dynamic variables? Do they have a DynamicVariable class as > well? I have no clue, no (I've never worked with either VA nor VW). I'll try to find out this morning. > In theory we could say that the dialect has to provide a > GRDynamicVariable, we could provide a GRExceptionBasedDynamicVariable. > Dialects that have a DynamicVariable class could provide > GRDynamicVariable as a subclass of DynamicVariable. Dialects that do > not have a DynamicVariable class could provide GRDynamicVariable as a > subclass of GRExceptionBasedDynamicVariable. Yes, that sounds like a good idea. I don't have a clear picture of how your suggestion would be implemented with Grease. So if you could help me out there, I'd appreciated it. Cheers, Max > > Cheers > Philippe > _______________________________________________ > seaside-dev mailing list > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
VW does not have dynamic variables AFAICT, but they do have a process environment, so it would be straight forward to implement them in the same way as in Pharo. I'm still waiting for my VA evaluation download...
_______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: Configurable current request context variable
|
|
In reply to this post by Max Leske
On Mon, May 8, 2017 at 8:57 AM, Max Leske <[hidden email]> wrote:
> >> On 7 May 2017, at 23:09, Philippe Marschall <[hidden email]> wrote: >> In theory we could say that the dialect has to provide a >> GRDynamicVariable, we could provide a GRExceptionBasedDynamicVariable. >> Dialects that have a DynamicVariable class could provide >> GRDynamicVariable as a subclass of DynamicVariable. Dialects that do >> not have a DynamicVariable class could provide GRDynamicVariable as a >> subclass of GRExceptionBasedDynamicVariable. > > Yes, that sounds like a good idea. I don't have a clear picture of how your suggestion would be implemented with Grease. So if you could help me out there, I'd appreciated it. It would be sort of a kludge In Pharo we would have DynamicVariable (Pharo) ^ I GRDynamicVariable (Grease-Pharo-Core) ^ I WADynamicVariable (Seaside-Core) In a dialect without dynamic variables we would have Notification (Dialect) ^ I GRExceptionBasedDynamicVariable (Grease-Core) ^ I GRDynamicVariable (Grease-Dialect-Core) ^ I WADynamicVariable (Seaside-Core) Cheers Philippe _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
Good news: VA doesn't have dynamic variables either but their process also has an environment (called #attributes). If there's no other platform to look out for, we could simply replicate the DynamicVariable behaviour for each platform without depending on DynamicVariable. There would only be
GRDynamicVariable ^ | WAPharoDynamicVariable / WAVWDynamicVariable / WAVADynamicVariable They would only differ in the name of the environment and possibly lookup semantics and GRDynamicVariable could hold all of the logic (it would mostly be a copy of DynamicVariable). Of course, we could also offer the choice between the exception based and process based variants. What do you think? Cheers, Max > On 10 May 2017, at 16:44, Philippe Marschall <[hidden email]> wrote: > > On Mon, May 8, 2017 at 8:57 AM, Max Leske <[hidden email]> wrote: >> >>> On 7 May 2017, at 23:09, Philippe Marschall <[hidden email]> wrote: >>> In theory we could say that the dialect has to provide a >>> GRDynamicVariable, we could provide a GRExceptionBasedDynamicVariable. >>> Dialects that have a DynamicVariable class could provide >>> GRDynamicVariable as a subclass of DynamicVariable. Dialects that do >>> not have a DynamicVariable class could provide GRDynamicVariable as a >>> subclass of GRExceptionBasedDynamicVariable. >> >> Yes, that sounds like a good idea. I don't have a clear picture of how your suggestion would be implemented with Grease. So if you could help me out there, I'd appreciated it. > > It would be sort of a kludge > > In Pharo we would have > > DynamicVariable (Pharo) > ^ > I > GRDynamicVariable (Grease-Pharo-Core) > ^ > I > WADynamicVariable (Seaside-Core) > > In a dialect without dynamic variables we would have > > Notification (Dialect) > ^ > I > GRExceptionBasedDynamicVariable (Grease-Core) > ^ > I > GRDynamicVariable (Grease-Dialect-Core) > ^ > I > WADynamicVariable (Seaside-Core) > > > Cheers > Philippe > _______________________________________________ > seaside-dev mailing list > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: Configurable current request context variable
|
|
What are the benefits of an exception based dynamic variable versus a
process variable? It seems to me that the process variable is "cleaner" since it doesn't require any exception handler. I'm currently doing Seaside in Cincom Smalltalk and I confirm the Process object has an `environment` variable that holds a dictionary (and can fallback lookup to a global ProcessEnvironment singleton). What I don't understand is how would the subclassing work. If WADynamicVariable is suposed to subclass GRDynamicVariable how would the platform specific classes play here? Regards! Esteban A. Maringolo 2017-05-10 14:16 GMT-03:00 Max Leske <[hidden email]>: > Good news: VA doesn't have dynamic variables either but their process also has an environment (called #attributes). If there's no other platform to look out for, we could simply replicate the DynamicVariable behaviour for each platform without depending on DynamicVariable. There would only be > > GRDynamicVariable > ^ > | > WAPharoDynamicVariable / WAVWDynamicVariable / WAVADynamicVariable > > They would only differ in the name of the environment and possibly lookup semantics and GRDynamicVariable could hold all of the logic (it would mostly be a copy of DynamicVariable). > > Of course, we could also offer the choice between the exception based and process based variants. > > What do you think? > > Cheers, > Max > > > >> On 10 May 2017, at 16:44, Philippe Marschall <[hidden email]> wrote: >> >> On Mon, May 8, 2017 at 8:57 AM, Max Leske <[hidden email]> wrote: >>> >>>> On 7 May 2017, at 23:09, Philippe Marschall <[hidden email]> wrote: >>>> In theory we could say that the dialect has to provide a >>>> GRDynamicVariable, we could provide a GRExceptionBasedDynamicVariable. >>>> Dialects that have a DynamicVariable class could provide >>>> GRDynamicVariable as a subclass of DynamicVariable. Dialects that do >>>> not have a DynamicVariable class could provide GRDynamicVariable as a >>>> subclass of GRExceptionBasedDynamicVariable. >>> >>> Yes, that sounds like a good idea. I don't have a clear picture of how your suggestion would be implemented with Grease. So if you could help me out there, I'd appreciated it. >> >> It would be sort of a kludge >> >> In Pharo we would have >> >> DynamicVariable (Pharo) >> ^ >> I >> GRDynamicVariable (Grease-Pharo-Core) >> ^ >> I >> WADynamicVariable (Seaside-Core) >> >> In a dialect without dynamic variables we would have >> >> Notification (Dialect) >> ^ >> I >> GRExceptionBasedDynamicVariable (Grease-Core) >> ^ >> I >> GRDynamicVariable (Grease-Dialect-Core) >> ^ >> I >> WADynamicVariable (Seaside-Core) >> >> >> Cheers >> Philippe >> _______________________________________________ >> seaside-dev mailing list >> [hidden email] >> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev > > _______________________________________________ > seaside-dev mailing list > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
> On 10 May 2017, at 19:55, Esteban A. Maringolo <[hidden email]> wrote: > > What are the benefits of an exception based dynamic variable versus a > process variable? > > It seems to me that the process variable is "cleaner" since it doesn't > require any exception handler. Exactly. My main concern, however, is performance. Lookup in the process environment takes constant time, while the lookup time of the exception mechanism depends on the depth of the stack and usually requires traversal of multiple handler contexts. In newer VM’s there’s a primitive to help with that but it’s still slower. > > I'm currently doing Seaside in Cincom Smalltalk and I confirm the > Process object has an `environment` variable that holds a dictionary > (and can fallback lookup to a global ProcessEnvironment singleton). Thanks. > > What I don't understand is how would the subclassing work. > If WADynamicVariable is suposed to subclass GRDynamicVariable how > would the platform specific classes play here? Good point. One way would be to bind the global #WADynamicVariable to a concrete class (e.g. like it has been done in Squeak and Pharo with Transcript or Processor). I don’t like that solution very much. Another could be to have the same class WADynamicVariable defined in multiple packages, i.e., once per platform, where WADynamicVariable implements the platform specific behaviour and inherits from GRDynamicVariable. This solution is better for users but probably a maintenance nightmare. Another option could be to make WADynamicVariable store a platform specific strategy that is determined dynamically upon load / first use. I don’t have much experience yet with Seaside and Grease, so I’m hoping that the core maintainers will make the decision for me :) Whatever is implemented, it should probably stay in line with existing platform agnostic solutions used by Grease. Cheers, Max > > Regards! > > Esteban A. Maringolo > > > 2017-05-10 14:16 GMT-03:00 Max Leske <[hidden email]>: >> Good news: VA doesn't have dynamic variables either but their process also has an environment (called #attributes). If there's no other platform to look out for, we could simply replicate the DynamicVariable behaviour for each platform without depending on DynamicVariable. There would only be >> >> GRDynamicVariable >> ^ >> | >> WAPharoDynamicVariable / WAVWDynamicVariable / WAVADynamicVariable >> >> They would only differ in the name of the environment and possibly lookup semantics and GRDynamicVariable could hold all of the logic (it would mostly be a copy of DynamicVariable). >> >> Of course, we could also offer the choice between the exception based and process based variants. >> >> What do you think? >> >> Cheers, >> Max >> >> >> >>> On 10 May 2017, at 16:44, Philippe Marschall <[hidden email]> wrote: >>> >>> On Mon, May 8, 2017 at 8:57 AM, Max Leske <[hidden email]> wrote: >>>> >>>>> On 7 May 2017, at 23:09, Philippe Marschall <[hidden email]> wrote: >>>>> In theory we could say that the dialect has to provide a >>>>> GRDynamicVariable, we could provide a GRExceptionBasedDynamicVariable. >>>>> Dialects that have a DynamicVariable class could provide >>>>> GRDynamicVariable as a subclass of DynamicVariable. Dialects that do >>>>> not have a DynamicVariable class could provide GRDynamicVariable as a >>>>> subclass of GRExceptionBasedDynamicVariable. >>>> >>>> Yes, that sounds like a good idea. I don't have a clear picture of how your suggestion would be implemented with Grease. So if you could help me out there, I'd appreciated it. >>> >>> It would be sort of a kludge >>> >>> In Pharo we would have >>> >>> DynamicVariable (Pharo) >>> ^ >>> I >>> GRDynamicVariable (Grease-Pharo-Core) >>> ^ >>> I >>> WADynamicVariable (Seaside-Core) >>> >>> In a dialect without dynamic variables we would have >>> >>> Notification (Dialect) >>> ^ >>> I >>> GRExceptionBasedDynamicVariable (Grease-Core) >>> ^ >>> I >>> GRDynamicVariable (Grease-Dialect-Core) >>> ^ >>> I >>> WADynamicVariable (Seaside-Core) >>> >>> >>> Cheers >>> Philippe >>> _______________________________________________ >>> seaside-dev mailing list >>> [hidden email] >>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev >> >> _______________________________________________ >> seaside-dev mailing list >> [hidden email] >> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev > _______________________________________________ > seaside-dev mailing list > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: Configurable current request context variable
|
|
In reply to this post by Esteban A. Maringolo
On Wed, May 10, 2017 at 7:55 PM, Esteban A. Maringolo
<[hidden email]> wrote: > .. > What I don't understand is how would the subclassing work. > If WADynamicVariable is suposed to subclass GRDynamicVariable how > would the platform specific classes play here? The idea is that the class GRDynamicVariable is provided by the Pharo-Dialect-Core package (where "Dialect" is Pharo/VW/VaST/GemStone). Cheers Philippe _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: Configurable current request context variable
|
|
On Sun, May 14, 2017 at 9:04 PM, Philippe Marschall
<[hidden email]> wrote: > On Wed, May 10, 2017 at 7:55 PM, Esteban A. Maringolo > <[hidden email]> wrote: >> .. >> What I don't understand is how would the subclassing work. >> If WADynamicVariable is suposed to subclass GRDynamicVariable how >> would the platform specific classes play here? > > The idea is that the class GRDynamicVariable is provided by the > Pharo-Dialect-Core package (where "Dialect" is > Pharo/VW/VaST/GemStone). I meant Grease-Dialect-Core. Cheers Philippe _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: Configurable current request context variable
|
|
In reply to this post by Max Leske
On Wed, May 10, 2017 at 7:16 PM, Max Leske <[hidden email]> wrote:
> Good news: VA doesn't have dynamic variables either but their process also has an environment (called #attributes). If there's no other platform to look out for, we could simply replicate the DynamicVariable behaviour for each platform without depending on DynamicVariable. There would only be > > GRDynamicVariable > ^ > | > WAPharoDynamicVariable / WAVWDynamicVariable / WAVADynamicVariable Nope. See my answer to Esteban. The idea is that the dialect specific implementation of Grease, Grease-Pharo-Core/Grease-VW-Core/Grease-VaST-Core/Grease-GemStone-Core would provide a class named GRDynamicVariable. The implementation would be either process environment based, or dynamic variable based, or notification based, whatever works best on this dialect. That way users can simply subclass GRDynamicVariable and automatically get the best possible behaviour on the dialect they are running on without having to change their code. Cheers Philippe _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
Hi Philippe,
I’ve created an implementation, trying to do what you suggest; these are the changes: - removed WADynamicVariable - added GRDynamicVariable to Grease-Core - subclasses of WADynamicVariable now inherit from GRDynamicVariable - test cases for WADynamicVariable moved to Grease-Tests-Core (not sure about this. The tests should be the same for all platforms but Grease-Core does not contain GRDynamicVariable…) I don’t have write permissions on STHub, so I’m attaching the patches below. I can also make the change for Squeak but I’m not sure how I would go about committing the change for VW / VASt. Let me know what you think. Cheers, Max > On 14 May 2017, at 21:09, Philippe Marschall <[hidden email]> wrote: > > On Wed, May 10, 2017 at 7:16 PM, Max Leske <[hidden email]> wrote: >> Good news: VA doesn't have dynamic variables either but their process also has an environment (called #attributes). If there's no other platform to look out for, we could simply replicate the DynamicVariable behaviour for each platform without depending on DynamicVariable. There would only be >> >> GRDynamicVariable >> ^ >> | >> WAPharoDynamicVariable / WAVWDynamicVariable / WAVADynamicVariable > > Nope. See my answer to Esteban. The idea is that the dialect specific > implementation of Grease, > Grease-Pharo-Core/Grease-VW-Core/Grease-VaST-Core/Grease-GemStone-Core > would provide a class named GRDynamicVariable. The implementation > would be either process environment based, or dynamic variable based, > or notification based, whatever works best on this dialect. That way > users can simply subclass GRDynamicVariable and automatically get the > best possible behaviour on the dialect they are running on without > having to change their code. > > Cheers > Philippe > _______________________________________________ > seaside-dev mailing list > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: Configurable current request context variable
|
|
2017-05-16 17:20 GMT-03:00 Max Leske <[hidden email]>:
> Hi Philippe, > > I’ve created an implementation, trying to do what you suggest; these are the changes: > > - removed WADynamicVariable > - added GRDynamicVariable to Grease-Core > - subclasses of WADynamicVariable now inherit from GRDynamicVariable > - test cases for WADynamicVariable moved to Grease-Tests-Core (not sure about this. The tests should be the same for all platforms but Grease-Core does not contain GRDynamicVariable…) Great! Thank you Max. Is Grease-*Dialect*-Core (e.g. Grease-Pharo-Core) a prerequisite of Grease-Core? > I don’t have write permissions on STHub, so I’m attaching the patches below. As expected, the file didn't make it to the attachments of the mail :) > I can also make the change for Squeak but I’m not sure how I would go about committing the change for VW / VASt. Let me know what you think. Esteban A. Maringolo _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
On 16 May 2017, at 22:24, Esteban A. Maringolo <[hidden email]> wrote: Sorry, this should have been Grease-Pharo30-Core. - subclasses of WADynamicVariable now inherit from GRDynamicVariable No, the other way around, according to the configuration. I don’t have write permissions on STHub, so I’m attaching the patches below. Especially because I forgot to attach them… :p Here’s the link to a zip archive with the patch: https://www.dropbox.com/s/pgd6k12mwh92s06/GRDynamicVariable_patch.zip?dl=0. Cheers, Max I can also make the change for Squeak but I’m not sure how I would go about committing the change for VW / VASt. Let me know what you think. _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
In reply to this post by Esteban A. Maringolo
Just remembered something I forgot to fix. New archive: https://www.dropbox.com/s/44smqfnx4cvplt3/GRDynamicVariable_patch2.zip?dl=0. Max
_______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: Configurable current request context variable
|
|
Hey Max,
Perhaps you can make a pull request on the git repo? thx for the work Johan
_______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
Yes, of course. I wasn't aware that there was a github repository. I'll do that tonight. Cheers, Max
_______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: Configurable current request context variable
|
|
Great! thanks
Johan
_______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
«
Return to Seaside Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |