From astares at gmx.de Fri Jul 3 16:22:19 2015 From: astares at gmx.de (Torsten Bergmann) Date: Fri Jul 3 16:22:22 2015 Subject: [Seaside] [ANN] CSS3Pie with Seaside Message-ID: PIE makes Internet Explorer 6-9 capable of rendering several of the most useful CSS3 decoration features: http://css3pie.com/ If you want to use it for Seaside then check out: http://www.smalltalkhub.com/#!/~TorstenBergmann/CSS3Pie Pharo Code is MIT, the lib itself is "Apache License Version 2.0 or the General Public License (GPL) Version 2" licensed. Thanks to Paul DeBruicker for the tip. Have fun T. From marianopeck at gmail.com Fri Jul 3 21:41:10 2015 From: marianopeck at gmail.com (Mariano Martinez Peck) Date: Fri Jul 3 21:41:13 2015 Subject: [Seaside] Seaside sessions not being either unregistered or GCed Message-ID: Hi guys, I am having a hard time to see why my seaside sessions are not being GCed nor unregistered. First of all, when I register my app, I set a timeout. I even tried with 1 minute timeout: *app cache expiryPolicy configuration at: #cacheTimeout put: 60* I put a *halt in MySessionSubclass >> #unregistered* (which then calls super). I have seen many seaside things around: WARenderVisitor instanceCount -> 77. WAHtmlCanvas instanceCount -> 1061. JQueryClass instanceCount -> 13492. WACallbackRegistry instanceCount -> 77. MySessionSubclass -> 12. ..... As you can see, I have plenty of memory around callbacks registries, renders, visitors, sessions etc... If I try to see which sessions were expired: *MySessionSubclass allInstances select: [ :each | (each instVarNamed: 'parent') isNil ] -> #() * The 'parent' instVar there is because "super unregistered" does that and I don't know another way to check if a session is expired or not. Finally, the only way I have to get rid of everything is this way: *WAApplication allInstances do: [ :each | each clear ].* But then, that clears all sessions...even the active ones which I don't want. *So.... how can I force the GC of all none expired sessions? And why my sessions are not receiving #unregistered ?* Note also that in my example the instanceCount of MySessionSubclass is bigger than 10, because somewhere I read that Seaside would start cleaning sessions upon 10th. So.... any idea? What am I doing wrong? Thanks in advance, -- Mariano http://marianopeck.wordpress.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20150703/c004b15d/attachment-0001.htm From arning315 at comcast.net Fri Jul 3 22:09:21 2015 From: arning315 at comcast.net (Bob Arning) Date: Fri Jul 3 22:09:24 2015 Subject: [Seaside] Seaside sessions not being either unregistered or GCed In-Reply-To: References: Message-ID: <55970811.4010609@comcast.net> FWIW, my old stand-by is WACache allInstances do: [ :e | e reap]. On 7/3/15 5:41 PM, Mariano Martinez Peck wrote: > Hi guys, > > I am having a hard time to see why my seaside sessions are not being > GCed nor unregistered. > First of all, when I register my app, I set a timeout. I even tried > with 1 minute timeout: > * > * > *app cache expiryPolicy configuration at: #cacheTimeout put: 60* > > I put a *halt in MySessionSubclass >> #unregistered* (which then calls > super). > > I have seen many seaside things around: > > WARenderVisitor instanceCount -> 77. > WAHtmlCanvas instanceCount -> 1061. > JQueryClass instanceCount -> 13492. > WACallbackRegistry instanceCount -> 77. > MySessionSubclass -> 12. > ..... > > As you can see, I have plenty of memory around callbacks registries, > renders, visitors, sessions etc... If I try to see which sessions were > expired: > > *MySessionSubclass allInstances select: [ :each | (each instVarNamed: > 'parent') isNil ] -> #() * > > The 'parent' instVar there is because "super unregistered" does that > and I don't know another way to check if a session is expired or not. > > Finally, the only way I have to get rid of everything is this way: > > *WAApplication allInstances do: [ :each | each clear ].* > > But then, that clears all sessions...even the active ones which I > don't want. *So.... how can I force the GC of all none expired > sessions? And why my sessions are not receiving #unregistered ?* > * > * > Note also that in my example the instanceCount of MySessionSubclass is > bigger than 10, because somewhere I read that Seaside would start > cleaning sessions upon 10th. > > So.... any idea? What am I doing wrong? > > Thanks in advance, > > > > > -- > Mariano > http://marianopeck.wordpress.com > > > _______________________________________________ > seaside mailing list > seaside@lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20150703/4411ba3e/attachment.htm From johan at inceptive.be Sat Jul 4 07:34:50 2015 From: johan at inceptive.be (Johan Brichau) Date: Sat Jul 4 07:34:58 2015 Subject: [Seaside] Seaside sessions not being either unregistered or GCed In-Reply-To: References: Message-ID: <5BCC4668-8AB3-45D2-8A44-8892FF9A6CC5@inceptive.be> Hi Mariano, Is this in Pharo or Gemstone? Johan > On 03 Jul 2015, at 23:41, Mariano Martinez Peck wrote: > > Hi guys, > > I am having a hard time to see why my seaside sessions are not being GCed nor unregistered. > First of all, when I register my app, I set a timeout. I even tried with 1 minute timeout: > > app cache expiryPolicy configuration at: #cacheTimeout put: 60 > > I put a halt in MySessionSubclass >> #unregistered (which then calls super). > > I have seen many seaside things around: > > WARenderVisitor instanceCount -> 77. > WAHtmlCanvas instanceCount -> 1061. > JQueryClass instanceCount -> 13492. > WACallbackRegistry instanceCount -> 77. > MySessionSubclass -> 12. > ..... > > As you can see, I have plenty of memory around callbacks registries, renders, visitors, sessions etc... If I try to see which sessions were expired: > > MySessionSubclass allInstances select: [ :each | (each instVarNamed: 'parent') isNil ] -> #() > > The 'parent' instVar there is because "super unregistered" does that and I don't know another way to check if a session is expired or not. > > Finally, the only way I have to get rid of everything is this way: > > WAApplication allInstances do: [ :each | each clear ]. > > But then, that clears all sessions...even the active ones which I don't want. So.... how can I force the GC of all none expired sessions? And why my sessions are not receiving #unregistered ? > > Note also that in my example the instanceCount of MySessionSubclass is bigger than 10, because somewhere I read that Seaside would start cleaning sessions upon 10th. > > So.... any idea? What am I doing wrong? > > Thanks in advance, > > > > > -- > Mariano > http://marianopeck.wordpress.com > _______________________________________________ > seaside mailing list > seaside@lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20150704/4758beae/attachment.htm From marianopeck at gmail.com Sat Jul 4 13:13:08 2015 From: marianopeck at gmail.com (Mariano Martinez Peck) Date: Sat Jul 4 13:13:10 2015 Subject: [Seaside] Seaside sessions not being either unregistered or GCed In-Reply-To: <55970811.4010609@comcast.net> References: <55970811.4010609@comcast.net> Message-ID: On Fri, Jul 3, 2015 at 7:09 PM, Bob Arning wrote: > FWIW, my old stand-by is > > WACache allInstances do: [ :e | e reap]. > > Thanks Bob, I just tried that and indeed, after doing that and a GC, it removed almost all garbage I have around and indeed, it called all the #unregistered of my sessions. So.... OK, with such code I can at least force the GC of those (which is similar to the one I was doing: *WAApplication allInstances do: [ :each | each clear ].)* , but... I still wonder, why my sessions are not "reap" automatically? Why they do not get the #unregistered automatically? From what I understand, they should, right? > On 7/3/15 5:41 PM, Mariano Martinez Peck wrote: > > Hi guys, > > I am having a hard time to see why my seaside sessions are not being > GCed nor unregistered. > First of all, when I register my app, I set a timeout. I even tried with 1 > minute timeout: > > *app cache expiryPolicy configuration at: #cacheTimeout put: 60* > > I put a *halt in MySessionSubclass >> #unregistered* (which then calls > super). > > I have seen many seaside things around: > > WARenderVisitor instanceCount -> 77. > WAHtmlCanvas instanceCount -> 1061. > JQueryClass instanceCount -> 13492. > WACallbackRegistry instanceCount -> 77. > MySessionSubclass -> 12. > ..... > > As you can see, I have plenty of memory around callbacks registries, > renders, visitors, sessions etc... If I try to see which sessions were > expired: > > *MySessionSubclass allInstances select: [ :each | (each instVarNamed: > 'parent') isNil ] -> #() * > > The 'parent' instVar there is because "super unregistered" does that and > I don't know another way to check if a session is expired or not. > > Finally, the only way I have to get rid of everything is this way: > > *WAApplication allInstances do: [ :each | each clear ].* > > But then, that clears all sessions...even the active ones which I don't > want. *So.... how can I force the GC of all none expired sessions? And > why my sessions are not receiving #unregistered ?* > > Note also that in my example the instanceCount of MySessionSubclass is > bigger than 10, because somewhere I read that Seaside would start cleaning > sessions upon 10th. > > So.... any idea? What am I doing wrong? > > Thanks in advance, > > > > > -- > Mariano > http://marianopeck.wordpress.com > > > _______________________________________________ > seaside mailing listseaside@lists.squeakfoundation.orghttp://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > > _______________________________________________ > seaside mailing list > seaside@lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > -- Mariano http://marianopeck.wordpress.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20150704/80e8ff6f/attachment-0001.htm From marianopeck at gmail.com Sat Jul 4 13:16:55 2015 From: marianopeck at gmail.com (Mariano Martinez Peck) Date: Sat Jul 4 13:16:57 2015 Subject: [Seaside] Seaside sessions not being either unregistered or GCed In-Reply-To: <5BCC4668-8AB3-45D2-8A44-8892FF9A6CC5@inceptive.be> References: <5BCC4668-8AB3-45D2-8A44-8892FF9A6CC5@inceptive.be> Message-ID: On Sat, Jul 4, 2015 at 4:34 AM, Johan Brichau wrote: > Hi Mariano, > > Is this in Pharo or Gemstone? > Hi Johan, This particular problem is on Pharo (sessions not getting #unregisted but when forced, most garbage goes away). On GemStone I have a different one... sessions DO get #unregistered (thanks to seaside maintenance vm), BUT I still have lots of garbage around...(on Pharo they go away when sessions are manually unregistered). For GemStone I opened another thread in gemstone list. Any idea? Thanks! > > Johan > > On 03 Jul 2015, at 23:41, Mariano Martinez Peck > wrote: > > Hi guys, > > I am having a hard time to see why my seaside sessions are not being GCed > nor unregistered. > First of all, when I register my app, I set a timeout. I even tried with 1 > minute timeout: > > *app cache expiryPolicy configuration at: #cacheTimeout put: 60* > > I put a *halt in MySessionSubclass >> #unregistered* (which then calls > super). > > I have seen many seaside things around: > > WARenderVisitor instanceCount -> 77. > WAHtmlCanvas instanceCount -> 1061. > JQueryClass instanceCount -> 13492. > WACallbackRegistry instanceCount -> 77. > MySessionSubclass -> 12. > ..... > > As you can see, I have plenty of memory around callbacks registries, > renders, visitors, sessions etc... If I try to see which sessions were > expired: > > *MySessionSubclass allInstances select: [ :each | (each instVarNamed: > 'parent') isNil ] -> #() * > > The 'parent' instVar there is because "super unregistered" does that and I > don't know another way to check if a session is expired or not. > > Finally, the only way I have to get rid of everything is this way: > > *WAApplication allInstances do: [ :each | each clear ].* > > But then, that clears all sessions...even the active ones which I don't > want. *So.... how can I force the GC of all none expired sessions? And > why my sessions are not receiving #unregistered ?* > > Note also that in my example the instanceCount of MySessionSubclass is > bigger than 10, because somewhere I read that Seaside would start cleaning > sessions upon 10th. > > So.... any idea? What am I doing wrong? > > Thanks in advance, > > > > > -- > Mariano > http://marianopeck.wordpress.com > _______________________________________________ > seaside mailing list > seaside@lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > > _______________________________________________ > seaside mailing list > seaside@lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > -- Mariano http://marianopeck.wordpress.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20150704/42408b6b/attachment.htm From arning315 at comcast.net Sat Jul 4 13:51:59 2015 From: arning315 at comcast.net (Bob Arning) Date: Sat Jul 4 13:52:01 2015 Subject: [Seaside] Seaside sessions not being either unregistered or GCed In-Reply-To: References: <55970811.4010609@comcast.net> Message-ID: <5597E4FF.5060201@comcast.net> look for senders of #reap. There are different "strategies" that do this under different circumstances. On 7/4/15 9:13 AM, Mariano Martinez Peck wrote: > > > On Fri, Jul 3, 2015 at 7:09 PM, Bob Arning > wrote: > > FWIW, my old stand-by is > > WACache allInstances do: [ :e | e reap]. > > > > Thanks Bob, > > I just tried that and indeed, after doing that and a GC, it removed > almost all garbage I have around and indeed, it called all the > #unregistered of my sessions. > So.... OK, with such code I can at least force the GC of those (which > is similar to the one I was doing: *WAApplication allInstances do: [ > :each | each clear ].)* , but... I still wonder, why my sessions are > not "reap" automatically? Why they do not get the #unregistered > automatically? From what I understand, they should, right? > > > On 7/3/15 5:41 PM, Mariano Martinez Peck wrote: >> Hi guys, >> >> I am having a hard time to see why my seaside sessions are not >> being GCed nor unregistered. >> First of all, when I register my app, I set a timeout. I even >> tried with 1 minute timeout: >> * >> * >> *app cache expiryPolicy configuration at: #cacheTimeout put: 60* >> >> I put a *halt in MySessionSubclass >> #unregistered* (which then >> calls super). >> >> I have seen many seaside things around: >> >> WARenderVisitor instanceCount -> 77. >> WAHtmlCanvas instanceCount -> 1061. >> JQueryClass instanceCount -> 13492. >> WACallbackRegistry instanceCount -> 77. >> MySessionSubclass -> 12. >> ..... >> >> As you can see, I have plenty of memory around callbacks >> registries, renders, visitors, sessions etc... If I try to see >> which sessions were expired: >> >> *MySessionSubclass allInstances select: [ :each | (each >> instVarNamed: 'parent') isNil ] -> #() * >> >> The 'parent' instVar there is because "super unregistered" does >> that and I don't know another way to check if a session is >> expired or not. >> >> Finally, the only way I have to get rid of everything is this way: >> >> *WAApplication allInstances do: [ :each | each clear ].* >> >> But then, that clears all sessions...even the active ones which I >> don't want. *So.... how can I force the GC of all none expired >> sessions? And why my sessions are not receiving #unregistered ?* >> * >> * >> Note also that in my example the instanceCount of >> MySessionSubclass is bigger than 10, because somewhere I read >> that Seaside would start cleaning sessions upon 10th. >> >> So.... any idea? What am I doing wrong? >> >> Thanks in advance, >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >> _______________________________________________ >> seaside mailing list >> seaside@lists.squeakfoundation.org >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > _______________________________________________ > seaside mailing list > seaside@lists.squeakfoundation.org > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > > > -- > Mariano > http://marianopeck.wordpress.com > > > _______________________________________________ > seaside mailing list > seaside@lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20150704/f6b5035f/attachment.htm From marianopeck at gmail.com Sat Jul 4 14:12:16 2015 From: marianopeck at gmail.com (Mariano Martinez Peck) Date: Sat Jul 4 14:12:17 2015 Subject: [Seaside] Seaside sessions not being either unregistered or GCed In-Reply-To: <5597E4FF.5060201@comcast.net> References: <55970811.4010609@comcast.net> <5597E4FF.5060201@comcast.net> Message-ID: On Sat, Jul 4, 2015 at 10:51 AM, Bob Arning wrote: > look for senders of #reap. There are different "strategies" that do this > under different circumstances. > > Indeed, thanks! It seems I am using the default one (since I do not specify a different one) and even I confirm this: (WACache allInstances collect: [ :each | each reapingStrategy class ]) asSet -> a Set(WAAccessIntervalReapingStrategy) And that class ends up using "WAAccessIntervalReapingStrategyConfiguration instance" which defines: describeOn: config (config integer: #cacheReapInterval) comment: 'The number of cache stores that are allowed before expired objects are reaped from the cache.'; default: 10 And still, at the very beginning of this email I showed how my sessions were not unregistered even if I had more than 10 instances around (I had 13 if I remember correctly). mmmmm getting this code: WACache allInstances collect: [ :each | each reapingStrategy instVarNamed: 'count' ] -> #(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 7 2 5 0 0) tells me that maybe I am misunderstanding the #cacheReapInterval. So maybe it is not 10 sessions... but that each cache (assume one per session and one per app) would be cleared only after something was stored there at least 10 times??? mmmmmm mmmm more confused than before... > On 7/4/15 9:13 AM, Mariano Martinez Peck wrote: > > > > On Fri, Jul 3, 2015 at 7:09 PM, Bob Arning wrote: > >> FWIW, my old stand-by is >> >> WACache allInstances do: [ :e | e reap]. >> >> > > Thanks Bob, > > I just tried that and indeed, after doing that and a GC, it removed > almost all garbage I have around and indeed, it called all the > #unregistered of my sessions. > So.... OK, with such code I can at least force the GC of those (which is > similar to the one I was doing: *WAApplication allInstances do: [ :each | > each clear ].)* , but... I still wonder, why my sessions are not "reap" > automatically? Why they do not get the #unregistered automatically? From > what I understand, they should, right? > > > > >> On 7/3/15 5:41 PM, Mariano Martinez Peck wrote: >> >> Hi guys, >> >> I am having a hard time to see why my seaside sessions are not being >> GCed nor unregistered. >> First of all, when I register my app, I set a timeout. I even tried with >> 1 minute timeout: >> >> *app cache expiryPolicy configuration at: #cacheTimeout put: 60* >> >> I put a *halt in MySessionSubclass >> #unregistered* (which then calls >> super). >> >> I have seen many seaside things around: >> >> WARenderVisitor instanceCount -> 77. >> WAHtmlCanvas instanceCount -> 1061. >> JQueryClass instanceCount -> 13492. >> WACallbackRegistry instanceCount -> 77. >> MySessionSubclass -> 12. >> ..... >> >> As you can see, I have plenty of memory around callbacks registries, >> renders, visitors, sessions etc... If I try to see which sessions were >> expired: >> >> *MySessionSubclass allInstances select: [ :each | (each instVarNamed: >> 'parent') isNil ] -> #() * >> >> The 'parent' instVar there is because "super unregistered" does that >> and I don't know another way to check if a session is expired or not. >> >> Finally, the only way I have to get rid of everything is this way: >> >> *WAApplication allInstances do: [ :each | each clear ].* >> >> But then, that clears all sessions...even the active ones which I don't >> want. *So.... how can I force the GC of all none expired sessions? And >> why my sessions are not receiving #unregistered ?* >> >> Note also that in my example the instanceCount of MySessionSubclass is >> bigger than 10, because somewhere I read that Seaside would start cleaning >> sessions upon 10th. >> >> So.... any idea? What am I doing wrong? >> >> Thanks in advance, >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >> _______________________________________________ >> seaside mailing listseaside@lists.squeakfoundation.orghttp://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> >> >> >> _______________________________________________ >> seaside mailing list >> seaside@lists.squeakfoundation.org >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > > _______________________________________________ > seaside mailing listseaside@lists.squeakfoundation.orghttp://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > > _______________________________________________ > seaside mailing list > seaside@lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > -- Mariano http://marianopeck.wordpress.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20150704/702bd58a/attachment-0001.htm From arning315 at comcast.net Sat Jul 4 15:08:12 2015 From: arning315 at comcast.net (Bob Arning) Date: Sat Jul 4 15:08:15 2015 Subject: [Seaside] Seaside sessions not being either unregistered or GCed In-Reply-To: References: <55970811.4010609@comcast.net> <5597E4FF.5060201@comcast.net> Message-ID: <5597F6DC.4020109@comcast.net> Yes, it is per cache. What you may be overlooking is this: the cache will be reaped every 10 (whatever) accesses or stores. That doesn't mean there is anything actually expired at that time, but the reap happens (doing nothing) and the strategy's count is reset to zero. If something expires after this reap, then it will take another 10 accesses (or whatever) before the newly-expired goes away. On 7/4/15 10:12 AM, Mariano Martinez Peck wrote: > tells me that maybe I am misunderstanding the #cacheReapInterval. So > maybe it is not 10 sessions... but that each cache (assume one per > session and one per app) would be cleared only after something was > stored there at least 10 times??? mmmmmm > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20150704/e8cc1bc9/attachment.htm From marianopeck at gmail.com Sat Jul 4 15:29:53 2015 From: marianopeck at gmail.com (Mariano Martinez Peck) Date: Sat Jul 4 15:29:56 2015 Subject: [Seaside] Seaside sessions not being either unregistered or GCed In-Reply-To: <5597F6DC.4020109@comcast.net> References: <55970811.4010609@comcast.net> <5597E4FF.5060201@comcast.net> <5597F6DC.4020109@comcast.net> Message-ID: On Sat, Jul 4, 2015 at 12:08 PM, Bob Arning wrote: > Yes, it is per cache. What you may be overlooking is this: the cache > will be reaped every 10 (whatever) accesses or stores. That doesn't mean > there is anything actually expired at that time, but the reap happens > (doing nothing) and the strategy's count is reset to zero. If something > expires after this reap, then it will take another 10 accesses (or > whatever) before the newly-expired goes away. > > Thanks Bob for the explanation. It makes sense now. So....the last piece on the puzzle that I don't understand now is how can I hook when my session is expired. I mean... MySessionSubclass >> #unregisgtered will be called when reaped, not when expired. So...how can I hook when my session is expired (when it gives the timeout to the user saying session was expired)? Not sure if I need that, but jut wondering ;) Thanks! > On 7/4/15 10:12 AM, Mariano Martinez Peck wrote: > > tells me that maybe I am misunderstanding the #cacheReapInterval. So maybe > it is not 10 sessions... but that each cache (assume one per session and > one per app) would be cleared only after something was stored there at > least 10 times??? mmmmmm > > > > _______________________________________________ > seaside mailing list > seaside@lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > -- Mariano http://marianopeck.wordpress.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20150704/67bc020d/attachment.htm From philippe.marschall at gmail.com Tue Jul 7 06:51:50 2015 From: philippe.marschall at gmail.com (Philippe Marschall) Date: Tue Jul 7 06:51:54 2015 Subject: [Seaside] Seaside sessions not being either unregistered or GCed In-Reply-To: References: <55970811.4010609@comcast.net> <5597E4FF.5060201@comcast.net> <5597F6DC.4020109@comcast.net> Message-ID: On Sat, Jul 4, 2015 at 5:29 PM, Mariano Martinez Peck wrote: > > > On Sat, Jul 4, 2015 at 12:08 PM, Bob Arning wrote: >> >> Yes, it is per cache. What you may be overlooking is this: the cache will >> be reaped every 10 (whatever) accesses or stores. That doesn't mean there is >> anything actually expired at that time, but the reap happens (doing nothing) >> and the strategy's count is reset to zero. If something expires after this >> reap, then it will take another 10 accesses (or whatever) before the >> newly-expired goes away. >> > > Thanks Bob for the explanation. It makes sense now. > > So....the last piece on the puzzle that I don't understand now is how can I > hook when my session is expired. I mean... MySessionSubclass >> > #unregisgtered will be called when reaped, not when expired. So...how can I > hook when my session is expired (when it gives the timeout to the user > saying session was expired)? Not sure if I need that, but jut wondering ;) If I understand you correctly, either: WAHandlerTrackingStrategy >> noHandlerFoundForKey:in:context: -> WApplication >> #handleExpired: -> WAResponseGenerator >> #expiredRegistryKey. This is the preferred way, the only issue is that you don't have access to the session. Or the removalAction on the cache. I would advise against doing it here. Keep in mind the session being #unregisgtered here may not the be session of the currently active request because we do bulk reaping. Cheers Philippe From astares at gmx.de Thu Jul 9 07:09:05 2015 From: astares at gmx.de (Torsten Bergmann) Date: Thu Jul 9 07:09:07 2015 Subject: [Seaside] [ANN] AnimateCSS Message-ID: If you need animate.css in your Seaside application you can use http://www.smalltalkhub.com/#!/~TorstenBergmann/AnimateCSS which is a simple packaged seaside lib for https://daneden.github.io/animate.css Bye T. From astares at gmx.de Thu Jul 9 07:10:35 2015 From: astares at gmx.de (Torsten Bergmann) Date: Thu Jul 9 07:10:38 2015 Subject: [Seaside] Hopscotch Message-ID: If you need Hopscotch in your Seaside app then you can use prepackaged library: http://www.smalltalkhub.com/#!/~TorstenBergmann/Hopscotch Hopscotch is a JS framework to make it easy for developers to add product tours to their pages. See https://github.com/linkedin/hopscotch From johan at inceptive.be Sun Jul 12 13:05:40 2015 From: johan at inceptive.be (Johan Brichau) Date: Sun Jul 12 13:05:49 2015 Subject: [Seaside] greaseString on ScaledDecimal In-Reply-To: <557FE9A8.7080003@gemtalksystems.com> References: <55604AFB.9070600@drgeo.eu> <13AE36C4-E45E-4EE4-9E17-AFCCAFC4FCBE@inceptive.be> <556C9F58.2070806@gemtalksystems.com> <557F15B8.7090506@gemtalksystems.com> <7E1B4433-5466-4129-8A96-71F704E4FC0D@inceptive.be> <557F1DBB.6070709@gemtalksystems.com> <557FE9A8.7080003@gemtalksystems.com> Message-ID: <8BBB7F3F-BD00-47B3-B75F-E0011126737D@inceptive.be> Hi Dale, fyi: I just did the ?swap? you mentioned. I propose to keep the code for Gemstone in the master branch and just keep working as before (i.e. all platforms that were tested will remain tested on SeasideSt/Grease). The only difference for now is that GsDevKit will have to synchronize its fork when Grease moves forward. Johan > On 16 Jun 2015, at 11:17, Dale Henrichs wrote: > > Johan, > > I think a better solution would be to merge the changes for SeasideSt/Grease into GsDevKit/Grease ... then move the GsDevKit/Grease project to SeasideSt/Grease, then fork SeasideSt/Grease on GsDevKit .... > > This would avoid any conflicts for the GsDevKit/Grease users and then make the SeasideSt/Grease project the master project ... > > We did a similar move when we moved projecs from glassdb to GsDevKit ... > > Presumably there aren't a lot of SeasideSt/Grease users at the moment? > > Dale > > On 6/15/15 11:47 AM, Dale Henrichs wrote: >> There is probably a way to merge the commits between the two repos and let the SeasideSt/Grease project take precedence ... >> >> Dale >> >> On 06/15/2015 11:17 AM, Johan Brichau wrote: >>> >>>> On 15 Jun 2015, at 20:13, Dale Henrichs > wrote: >>>> >>>> Are there differences between the two in terms of packaging/structure? Or is mainly the comit stream that you are thinking of? >>> >>> The commit stream and the Metacello load conflicts for everyone. >>> There are no package differences (at least there should not be any) as the repositories for Grease are all the same. However, manually keeping track of changes to both the Smalltalkhub repo and the GsDevKit one, is not an option in the long run either. >>> >>> Johan >>> >>> >>> _______________________________________________ >>> seaside mailing list >>> seaside@lists.squeakfoundation.org >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> > > _______________________________________________ > seaside mailing list > seaside@lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20150712/1c0052ef/attachment-0001.htm From philippe.marschall at gmail.com Sun Jul 12 14:26:50 2015 From: philippe.marschall at gmail.com (Philippe Marschall) Date: Sun Jul 12 14:26:53 2015 Subject: [Seaside] greaseString on ScaledDecimal In-Reply-To: <557F15B8.7090506@gemtalksystems.com> References: <55604AFB.9070600@drgeo.eu> <13AE36C4-E45E-4EE4-9E17-AFCCAFC4FCBE@inceptive.be> <556C9F58.2070806@gemtalksystems.com> <557F15B8.7090506@gemtalksystems.com> Message-ID: On Mon, Jun 15, 2015 at 8:13 PM, Dale Henrichs wrote: > > > On 06/02/2015 12:00 AM, Johan Brichau wrote: > > Hey Dale, > > Creating a fork will be the way to go. I think it?s clearer to follow the > same pattern everywhere. > I intend this to be applicable for Seaside 3.2 and beyond. > > Makes sense ... > > > My intention is to get Seaside 3.2 for Gemstone working by ESUG. For that, I > will start from the Seaside31 repo on GsDevKit and merge in the changes from > Seaside3.2 > > Let me know if there's anything you need help with .. I'd like to help where > I can, but I don't want to get in your way ... at a minimum, I will make > sure that this works in GemStone3.3 when it's ready enough for that ... Just to give you an advance notice, I merged the following: https://github.com/SeasideSt/Seaside/issues/262 https://github.com/SeasideSt/Seaside/issues/820 #820 should simplify several things in GemStone/S, #262 will probably need changes. In theory WACache should specify the whole protocol and WADictionaryCache is an implementation that doesn't do any reaping. Likely GemStone/S would profit from something more sophisticated. Stuff will likely be broken for the whole week. Cheers Philippe From dale.henrichs at gemtalksystems.com Mon Jul 13 16:59:20 2015 From: dale.henrichs at gemtalksystems.com (Dale Henrichs) Date: Mon Jul 13 16:59:24 2015 Subject: [Seaside] greaseString on ScaledDecimal In-Reply-To: <8BBB7F3F-BD00-47B3-B75F-E0011126737D@inceptive.be> References: <55604AFB.9070600@drgeo.eu> <13AE36C4-E45E-4EE4-9E17-AFCCAFC4FCBE@inceptive.be> <556C9F58.2070806@gemtalksystems.com> <557F15B8.7090506@gemtalksystems.com> <7E1B4433-5466-4129-8A96-71F704E4FC0D@inceptive.be> <557F1DBB.6070709@gemtalksystems.com> <557FE9A8.7080003@gemtalksystems.com> <8BBB7F3F-BD00-47B3-B75F-E0011126737D@inceptive.be> Message-ID: <55A3EE68.7000609@gemtalksystems.com> I saw that ... excellent! I will slowly but surely move the GsDevKit references to the SeasideSt/Grease repo ... On 07/12/2015 06:05 AM, Johan Brichau wrote: > Hi Dale, > > fyi: I just did the ?swap? you mentioned. > > I propose to keep the code for Gemstone in the master branch and just > keep working as before (i.e. all platforms that were tested will > remain tested on SeasideSt/Grease). > The only difference for now is that GsDevKit will have to synchronize > its fork when Grease moves forward. > > Johan > >> On 16 Jun 2015, at 11:17, Dale Henrichs >> > > wrote: >> >> Johan, >> >> I think a better solution would be to merge the changes for >> SeasideSt/Grease into GsDevKit/Grease ... then move the >> GsDevKit/Grease project to SeasideSt/Grease, then fork >> SeasideSt/Grease on GsDevKit .... >> >> This would avoid any conflicts for the GsDevKit/Grease users and then >> make the SeasideSt/Grease project the master project ... >> >> We did a similar move when we moved projecs from glassdb to GsDevKit ... >> >> Presumably there aren't a lot of SeasideSt/Grease users at the moment? >> >> Dale >> >> On 6/15/15 11:47 AM, Dale Henrichs wrote: >>> There is probably a way to merge the commits between the two repos >>> and let the SeasideSt/Grease project take precedence ... >>> >>> Dale >>> >>> On 06/15/2015 11:17 AM, Johan Brichau wrote: >>>> >>>>> On 15 Jun 2015, at 20:13, Dale Henrichs >>>>> >>>> > wrote: >>>>> >>>>> Are there differences between the two in terms of >>>>> packaging/structure? Or is mainly the comit stream that you are >>>>> thinking of? >>>> >>>> The commit stream and the Metacello load conflicts for everyone. >>>> There are no package differences (at least there should not be any) >>>> as the repositories for Grease are all the same. However, manually >>>> keeping track of changes to both the Smalltalkhub repo and the >>>> GsDevKit one, is not an option in the long run either. >>>> >>>> Johan >>>> >>>> >>>> _______________________________________________ >>>> seaside mailing list >>>> seaside@lists.squeakfoundation.org >>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >>> >> >> _______________________________________________ >> seaside mailing list >> seaside@lists.squeakfoundation.org >> >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > > _______________________________________________ > seaside mailing list > seaside@lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20150713/448a3458/attachment.htm From dale.henrichs at gemtalksystems.com Mon Jul 13 17:07:24 2015 From: dale.henrichs at gemtalksystems.com (Dale Henrichs) Date: Mon Jul 13 17:07:29 2015 Subject: [Seaside] greaseString on ScaledDecimal In-Reply-To: References: <55604AFB.9070600@drgeo.eu> <13AE36C4-E45E-4EE4-9E17-AFCCAFC4FCBE@inceptive.be> <556C9F58.2070806@gemtalksystems.com> <557F15B8.7090506@gemtalksystems.com> Message-ID: <55A3F04C.3000205@gemtalksystems.com> On 07/12/2015 07:26 AM, Philippe Marschall wrote: > On Mon, Jun 15, 2015 at 8:13 PM, Dale Henrichs > wrote: >> >> On 06/02/2015 12:00 AM, Johan Brichau wrote: >> >> Hey Dale, >> >> Creating a fork will be the way to go. I think it?s clearer to follow the >> same pattern everywhere. >> I intend this to be applicable for Seaside 3.2 and beyond. >> >> Makes sense ... >> >> >> My intention is to get Seaside 3.2 for Gemstone working by ESUG. For that, I >> will start from the Seaside31 repo on GsDevKit and merge in the changes from >> Seaside3.2 >> >> Let me know if there's anything you need help with .. I'd like to help where >> I can, but I don't want to get in your way ... at a minimum, I will make >> sure that this works in GemStone3.3 when it's ready enough for that ... > Just to give you an advance notice, I merged the following: > > https://github.com/SeasideSt/Seaside/issues/262 > https://github.com/SeasideSt/Seaside/issues/820 > > #820 should simplify several things in GemStone/S, #262 will probably > need changes. In theory WACache should specify the whole protocol and > WADictionaryCache is an implementation that doesn't do any reaping. > Likely GemStone/S would profit from something more sophisticated. > Stuff will likely be broken for the whole week. > Cool ... I've started watching the SeasideSt/Seaside repo, but just in case I miss the ultimate checkin, let me know ... I've got some things in the hopper for Seaside and GemStone/S 3.3[1] . The current work is being done in 3.2, but I think 3.3 will be more appropriate and I can piggy back the adaptation of your work for GemStone/S with the integration of my new work ... Dale [1] https://github.com/GsDevKit/Seaside31/tree/no_tranlogging From philippe.marschall at gmail.com Mon Jul 13 17:19:23 2015 From: philippe.marschall at gmail.com (Philippe Marschall) Date: Mon Jul 13 17:19:26 2015 Subject: [Seaside] greaseString on ScaledDecimal In-Reply-To: <55A3F04C.3000205@gemtalksystems.com> References: <55604AFB.9070600@drgeo.eu> <13AE36C4-E45E-4EE4-9E17-AFCCAFC4FCBE@inceptive.be> <556C9F58.2070806@gemtalksystems.com> <557F15B8.7090506@gemtalksystems.com> <55A3F04C.3000205@gemtalksystems.com> Message-ID: On Mon, Jul 13, 2015 at 7:07 PM, Dale Henrichs wrote: > > On 07/12/2015 07:26 AM, Philippe Marschall wrote: >>> Let me know if there's anything you need help with .. I'd like to help >>> where >>> I can, but I don't want to get in your way ... at a minimum, I will make >>> sure that this works in GemStone3.3 when it's ready enough for that ... >> >> Just to give you an advance notice, I merged the following: >> >> https://github.com/SeasideSt/Seaside/issues/262 >> https://github.com/SeasideSt/Seaside/issues/820 >> >> #820 should simplify several things in GemStone/S, #262 will probably >> need changes. In theory WACache should specify the whole protocol and >> WADictionaryCache is an implementation that doesn't do any reaping. >> Likely GemStone/S would profit from something more sophisticated. >> Stuff will likely be broken for the whole week. >> > Cool ... I've started watching the SeasideSt/Seaside repo, but just in case > I miss the ultimate checkin, let me know ... > > I've got some things in the hopper for Seaside and GemStone/S 3.3[1] . The > current work is being done in 3.2, but I think 3.3 will be more appropriate > and I can piggy back the adaptation of your work for GemStone/S with the > integration of my new work ... So I just committed WABulkReapingCache. It's intended a session cache for GemStone/S. It's a wrapper around an RcDictionary. It doesn't do any on access reaping, it only reaps in #reap which is supposed to be called by a background process. I still need to figure out how to plug it in and remove the mutex. Cheers Philippe From iwan at reahl.org Wed Jul 15 10:23:02 2015 From: iwan at reahl.org (Iwan Vosloo) Date: Wed Jul 15 10:23:14 2015 Subject: [Seaside] Ajax that uses server-side rendering Message-ID: <55A63486.3090001@reahl.org> Hi there. I am relatively new to Seaside and am uncertain about the best way to solve some of the requirements we need to cover for a client. We do have solutions for these, but they are tightly coupled to in-house infrastructure and I think we can lean a lot from seeing how you guys would have done it. All of this is happening on Pharo 3.0, Seaside 3.1 and Magritte 3. Some of the stuff is built using components and some using Magritte. We prefer the latter. Here is a relatively simple one: We need to let a user choose a "type of ID document" in a dropdown. Underneath this dropdown, a text input should appear via ajax (on change of the dropdown), but it appears only for certain options of the dropdown. This should happen via ajax, but we have one wish... we do not want to use Pharo's javascript library wrappers to code the logic of HOW the DOM should be changed in the browser. We'd rather fetch newly generated HTML from the server via a "jQuery load", and replace a small chunk of the form with this HTML. This way we let the original server-side seaside/magritte code render that (changed) HTML snippet. (Some of our screens are fairly complex, and we'd prefer to keep the logic for what such a screen look like written once, and using Seaside/Magritte.) Regards - Iwan PS: Is the seaside list the correct place to have this discussion? (as opposed to the magritte list) -- Reahl, the Python only web framework: http://www.reahl.org From pdebruic at gmail.com Wed Jul 15 16:00:05 2015 From: pdebruic at gmail.com (Paul DeBruicker) Date: Wed Jul 15 16:00:15 2015 Subject: [Seaside] Re: Ajax that uses server-side rendering In-Reply-To: <55A63486.3090001@reahl.org> References: <55A63486.3090001@reahl.org> Message-ID: <1436976005596-4837691.post@n4.nabble.com> Does html select ... onChange: (html jQuery id: 'textInputDiv') load html:[:h | self renderTextInputForSelectedOn: h] html div id:'textInputDiv' do what you want? Iwan Vosloo wrote > Hi there. > > I am relatively new to Seaside and am uncertain about the best way to > solve some of the requirements we need to cover for a client. We do have > solutions for these, but they are tightly coupled to in-house > infrastructure and I think we can lean a lot from seeing how you guys > would have done it. > > All of this is happening on Pharo 3.0, Seaside 3.1 and Magritte 3. Some > of the stuff is built using components and some using Magritte. We > prefer the latter. > > Here is a relatively simple one: > > We need to let a user choose a "type of ID document" in a dropdown. > Underneath this dropdown, a text input should appear via ajax (on change > of the dropdown), but it appears only for certain options of the dropdown. > > This should happen via ajax, but we have one wish... we do not want to > use Pharo's javascript library wrappers to code the logic of HOW the DOM > should be changed in the browser. We'd rather fetch newly generated HTML > from the server via a "jQuery load", and replace a small chunk of the > form with this HTML. This way we let the original server-side > seaside/magritte code render that (changed) HTML snippet. (Some of our > screens are fairly complex, and we'd prefer to keep the logic for what > such a screen look like written once, and using Seaside/Magritte.) > > Regards > - Iwan > > PS: Is the seaside list the correct place to have this discussion? (as > opposed to the magritte list) > > > -- > Reahl, the Python only web framework: http://www.reahl.org > > _______________________________________________ > seaside mailing list > seaside@.squeakfoundation > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside -- View this message in context: http://forum.world.st/Ajax-that-uses-server-side-rendering-tp4837612p4837691.html Sent from the Seaside General mailing list archive at Nabble.com. From iwan at reahl.org Thu Jul 16 06:24:16 2015 From: iwan at reahl.org (Iwan Vosloo) Date: Thu Jul 16 06:24:22 2015 Subject: [Seaside] Re: Ajax that uses server-side rendering In-Reply-To: <1436976005596-4837691.post@n4.nabble.com> References: <55A63486.3090001@reahl.org> <1436976005596-4837691.post@n4.nabble.com> Message-ID: <55A74E10.1020005@reahl.org> On 15/07/2015 18:00, Paul DeBruicker wrote: > Does > > html select > ... > onChange: (html jQuery id: 'textInputDiv') load html:[:h | self > renderTextInputForSelectedOn: h] > > > html div id:'textInputDiv' > > > do what you want? That's the general idea, but we'd like to do that using magritte. Given an object (say a IdentificationDocument), with two descriptions - one for the type of document and another for the expiry date we'd like to control the visibility of the expiry date using magritte and rerender the MAContainerComponent of this object with the jQuery load. Thanks -i > Iwan Vosloo wrote >> We need to let a user choose a "type of ID document" in a dropdown. >> Underneath this dropdown, a text input should appear via ajax (on change >> of the dropdown), but it appears only for certain options of the dropdown. >> >> This should happen via ajax, but we have one wish... we do not want to >> use Pharo's javascript library wrappers to code the logic of HOW the DOM >> should be changed in the browser. We'd rather fetch newly generated HTML >> from the server via a "jQuery load", and replace a small chunk of the >> form with this HTML. This way we let the original server-side >> seaside/magritte code render that (changed) HTML snippet. (Some of our >> screens are fairly complex, and we'd prefer to keep the logic for what >> such a screen look like written once, and using Seaside/Magritte.) >> nfo/seaside -- Reahl, the Python only web framework: http://www.reahl.org From stephan at stack.nl Thu Jul 16 07:10:45 2015 From: stephan at stack.nl (Stephan Eggermont) Date: Thu Jul 16 07:11:00 2015 Subject: [Seaside] Re: Ajax that uses server-side rendering In-Reply-To: <55A74E10.1020005@reahl.org> References: <55A63486.3090001@reahl.org> <1436976005596-4837691.post@n4.nabble.com> <55A74E10.1020005@reahl.org> Message-ID: On 16-07-15 08:24, Iwan Vosloo wrote: > That's the general idea, but we'd like to do that using magritte. Given > an object (say a IdentificationDocument), with two descriptions - one > for the type of document and another for the expiry date we'd like to > control the visibility of the expiry date using magritte and rerender > the MAContainerComponent of this object with the jQuery load. Then you might want to take a look at QCMagritte Stephan From stormbyte at gmail.com Thu Jul 16 16:28:34 2015 From: stormbyte at gmail.com (David) Date: Thu Jul 16 16:28:53 2015 Subject: [Seaside] addSyle: inside updateRoot not being able to set URL Message-ID: <20150716182834.1f42ac38@Zero.StormByte.org> Hi all, I implemented updateUrl, updateRoot and initialRequest so I can take care of the URLs in my project. Specifically, as I am working with rewrites, I hide my "app name" configured in seaside. As an example, a "normal" link would be: mydomain.com/my_app_name/?_s=XX&_k=YY. By implementing updateRoot, initialRequest, updateUrl and rewrites in nginx's config, I am successful in completelly remove my_app_name from all links in all the site except one place. Inside updateRoot: I put custom CSS via aHtmlRoot addStyle: ( "My CSS code" ), and it works, but the link is generated with "my_app_name" in it. Any way to handle that URL generation so I can hide it there also? Thanks From iwan at reahl.org Thu Jul 16 16:37:01 2015 From: iwan at reahl.org (Iwan Vosloo) Date: Thu Jul 16 16:37:12 2015 Subject: [Seaside] Re: Ajax that uses server-side rendering In-Reply-To: References: <55A63486.3090001@reahl.org> <1436976005596-4837691.post@n4.nabble.com> <55A74E10.1020005@reahl.org> Message-ID: <55A7DDAD.4010108@reahl.org> On 16/07/2015 09:10, Stephan Eggermont wrote: > On 16-07-15 08:24, Iwan Vosloo wrote: >> That's the general idea, but we'd like to do that using magritte. Given >> an object (say a IdentificationDocument), with two descriptions - one >> for the type of document and another for the expiry date we'd like to >> control the visibility of the expiry date using magritte and rerender >> the MAContainerComponent of this object with the jQuery load. > > Then you might want to take a look at QCMagritte > > Stephan I was afraid someone might say that... I do not have anything against it, we are just trying to get all the code in an existing system to be implemented consistently and QCMagritte would introduce a new way of doing things. So, I am a bit reluctant to go there if all options with straight Magritte have not been exhausted. Would QCMagritte be the only way of achieving this, or just the better way (vs Magritte)? -Iwan -- Reahl, the Python only web framework: http://www.reahl.org From stephan at stack.nl Thu Jul 16 19:12:20 2015 From: stephan at stack.nl (Stephan Eggermont) Date: Thu Jul 16 19:12:54 2015 Subject: [Seaside] Re: Ajax that uses server-side rendering In-Reply-To: <55A7DDAD.4010108@reahl.org> References: <55A63486.3090001@reahl.org> <1436976005596-4837691.post@n4.nabble.com> <55A74E10.1020005@reahl.org> <55A7DDAD.4010108@reahl.org> Message-ID: On 16-07-15 18:37, Iwan Vosloo wrote: > On 16/07/2015 09:10, Stephan Eggermont wrote: >> On 16-07-15 08:24, Iwan Vosloo wrote: >>> That's the general idea, but we'd like to do that using magritte. Given >>> an object (say a IdentificationDocument), with two descriptions - one >>> for the type of document and another for the expiry date we'd like to >>> control the visibility of the expiry date using magritte and rerender >>> the MAContainerComponent of this object with the jQuery load. >> >> Then you might want to take a look at QCMagritte >> >> Stephan > > I was afraid someone might say that... I do not have anything against > it, we are just trying to get all the code in an existing system to be > implemented consistently and QCMagritte would introduce a new way of > doing things. So, I am a bit reluctant to go there if all options with > straight Magritte have not been exhausted. > > Would QCMagritte be the only way of achieving this, or just the better > way (vs Magritte)? QCMagritte is Magritte. You'll find one way of achieving what you described in it. QCMagritte helps reducing duplication in the descriptions and the builders. Stephan From philippe.marschall at gmail.com Fri Jul 17 08:59:16 2015 From: philippe.marschall at gmail.com (Philippe Marschall) Date: Fri Jul 17 08:59:19 2015 Subject: [Seaside] addSyle: inside updateRoot not being able to set URL In-Reply-To: <20150716182834.1f42ac38@Zero.StormByte.org> References: <20150716182834.1f42ac38@Zero.StormByte.org> Message-ID: On Thu, Jul 16, 2015 at 6:28 PM, David wrote: > Hi all, > > I implemented updateUrl, updateRoot and initialRequest so I can take > care of the URLs in my project. Specifically, as I am working with > rewrites, I hide my "app name" configured in seaside. > > As an example, a "normal" link would be: > mydomain.com/my_app_name/?_s=XX&_k=YY. By implementing updateRoot, > initialRequest, updateUrl and rewrites in nginx's config, I am > successful in completelly remove my_app_name from all links in all the > site except one place. The following approaches would probably be simpler - set the #requestHandler: on your server adaptor to you application instead of the default dispatcher - set #defaultName: on the default dispatcher to 'my_app_name' This way you don't have to implement #updateRoot #initialRequest and #updateUrl Cheers Philippe From stormbyte at gmail.com Fri Jul 17 10:05:32 2015 From: stormbyte at gmail.com (David) Date: Fri Jul 17 10:05:50 2015 Subject: [Seaside] Re: addSyle: inside updateRoot not being able to set URL References: <20150716182834.1f42ac38@Zero.StormByte.org> Message-ID: <20150717120532.14a6c7d9@Zero.StormByte.org> El Fri, 17 Jul 2015 10:59:16 +0200 Philippe Marschall escribi?: > On Thu, Jul 16, 2015 at 6:28 PM, David wrote: > > Hi all, > > > > I implemented updateUrl, updateRoot and initialRequest so I can take > > care of the URLs in my project. Specifically, as I am working with > > rewrites, I hide my "app name" configured in seaside. > > > > As an example, a "normal" link would be: > > mydomain.com/my_app_name/?_s=XX&_k=YY. By implementing updateRoot, > > initialRequest, updateUrl and rewrites in nginx's config, I am > > successful in completelly remove my_app_name from all links in all > > the site except one place. > > The following approaches would probably be simpler > - set the #requestHandler: on your server adaptor to you application > instead of the default dispatcher > - set #defaultName: on the default dispatcher to 'my_app_name' > > This way you don't have to implement #updateRoot #initialRequest and > #updateUrl > > Cheers > Philippe Thanks for your response. The implementation of the initialRequest + updateUrl and updateRoot is not only for that, it is also to maintain a SEO friendly links across pages. From etolnay at gmail.com Tue Jul 21 00:31:33 2015 From: etolnay at gmail.com (Ezequiel Tolnay) Date: Tue Jul 21 00:31:56 2015 Subject: [Seaside] Problems setting up a GLASS/Jade Message-ID: Hi all, This is the first time I'm asking something to the community after 20 years in IT! And I really hate coming with the stupid newbie question... I'm banging my head on the wall trying to get a basic GLASS/Jade set-up up and running. All the tutorials are outdated and whilst some tools seem to continue to work (I couldn't manage to install a GLASS extent on my linux server, but I could on my mac), the instructions to get all the required libraries/supporting classes fails at some point. Other people has had the same problem and asked for a solution but in the last year or so there have been no satisfactory answers. The cleanest and simplest guidelines I've found so far, which fail, are the following: 1. Set-up Gemstone/S 64 on mac (done, although this is a temporary measure, I'll need to install on linux in production) - https://www.youtube.com/watch?v=6Oz4RLcEWXs 2. Set-up a GLASS extent and upgrade Metacello, Margerite, and Seaside to use with Jade (fails): - https://www.youtube.com/watch?v=dnRB5rBbkiI - https://programminggems.wordpress.com/2013/10/01/jade/ - - > run - ConfigurationOfMagritte3 project stableVersion load. - % - --transcript--'Loading 3.0.1 of ConfigurationOfMagritte3...' - ERROR 2010 , a MessageNotUnderstood occurred (error 2010), a MetacelloVersionConstructor does not understand #'baseline:with:' (MessageNotUnderstood) The problem seems silly, just one missing message on MetacelloVersionConstructor. I've gone through with the Boquitas tutorial in Pharo and I'm very keen on beginning to develop a solution in seaside that can actually be used in production. Is GLASS dead? How is seaside normally used in a demanding production environment? GNU smalltalk and a database? Thank you and apologies for the newbie annoyance! Cheers, Ziggy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20150721/732be91a/attachment-0001.htm From dale.henrichs at gemtalksystems.com Tue Jul 21 02:09:09 2015 From: dale.henrichs at gemtalksystems.com (Dale Henrichs) Date: Tue Jul 21 02:09:15 2015 Subject: [Seaside] Problems setting up a GLASS/Jade In-Reply-To: References: Message-ID: <55ADA9C5.2080005@gemtalksystems.com> Ziggy, Well, you are not asking a "stupid newbie question" .. I've been in the process of improving the documentation and setup environment for using GLASS, but it is a large task and I'm only partway through ... I've created a project up on github[1] where I am hoping to consolidate all of the documentation. If you take a look at the project README[2], the installServer script is described, that downloads, installs and starts a stone ... in one script ... included in the project is a set of scripts[3] for starting/stopping stones and a number of common operations. The scripts work on both the Mac and Linux ... The GsDevKitHome development environment is based on tODE[4] and all of the documentation is written assuming that you are using tODE, but if you know what you are doing you can use GemTools or Jade. By using the installServer script or the createTodeStone (once you've done an initial install) scripts to create stones, you will be guaranteed to get a GsDevKit/GLASS installation using the latest code base. Once you've created a stone, follow the GsDevKitHome Seaside3.1 project installation instructions[5]. Normally, I would say feel free to ask me more questions and I could help you with any issues that you might run into, but I have a family health issue to take care of and I will not be generally available for at least a couple of weeks. I will be checking email when I can. If you join the GLASS/GSDevKit mailing list[6], there should be folks in the community who can answer many of your questions. Dale [1] https://github.com/GsDevKit/gsDevKitHome [2] https://github.com/GsDevKit/gsDevKitHome#open-source-development-kit-for-gemstones-64-bit- [3] https://github.com/GsDevKit/gsDevKitHome/blob/master/bin/README.md#gsdevkit-scripts [4] https://github.com/dalehenrich/tode#tode-the-object-centric-development-environment- [5] https://github.com/GsDevKit/gsDevKitHome/tree/master/projects/seaside31#seaside31- [6] http://lists.gemtalksystems.com/mailman/listinfo/glass On 7/20/15 5:31 PM, Ezequiel Tolnay wrote: > Hi all, > > This is the first time I'm asking something to the community after 20 > years in IT! And I really hate coming with the stupid newbie question... > > I'm banging my head on the wall trying to get a basic GLASS/Jade > set-up up and running. All the tutorials are outdated and whilst some > tools seem to continue to work (I couldn't manage to install a GLASS > extent on my linux server, but I could on my mac), the instructions to > get all the required libraries/supporting classes fails at some point. > Other people has had the same problem and asked for a solution but in > the last year or so there have been no satisfactory answers. > > The cleanest and simplest guidelines I've found so far, which fail, > are the following: > > 1. Set-up Gemstone/S 64 on mac (done, although this is a temporary > measure, I'll need to install on linux in production) > * https://www.youtube.com/watch?v=6Oz4RLcEWXs > 2. Set-up a GLASS extent and upgrade Metacello, Margerite, and > Seaside to use with Jade (fails): > * https://www.youtube.com/watch?v=dnRB5rBbkiI > * https://programminggems.wordpress.com/2013/10/01/jade/ > o > > o > run > o ConfigurationOfMagritte3 project stableVersion load. > o % > o --transcript--'Loading 3.0.1 of ConfigurationOfMagritte3...' > o ERROR 2010 , a MessageNotUnderstood occurred (error 2010), > a MetacelloVersionConstructor does not understand > #'baseline:with:' (MessageNotUnderstood) > > The problem seems silly, just one missing message on > MetacelloVersionConstructor. > > I've gone through with the Boquitas tutorial in Pharo and I'm very > keen on beginning to develop a solution in seaside that can actually > be used in production. Is GLASS dead? How is seaside normally used in > a demanding production environment? GNU smalltalk and a database? > > Thank you and apologies for the newbie annoyance! > > Cheers, > > Ziggy > > > _______________________________________________ > seaside mailing list > seaside@lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20150720/b7dfa2f9/attachment.htm