From dorneles at x3ng.com.br Thu Aug 14 03:33:12 2008 From: dorneles at x3ng.com.br (=?UTF-8?B?RG9ybmVsZXMgVHJlbcOpYQ==?=) Date: Wed, 13 Aug 2008 22:33:12 -0300 Subject: [Kss-devel] Using a context for selectors Message-ID: Hello, with jQuery, you can use a context for the selectors: jq('selector', context) ...where context can be DOM Element, Document or jQuery. Is there a way to do that with KSS? I was thinking in something along these lines: core.replaceInnerHTML('selector', 'content', context="frames['frame-name'].document") My usecase is: you click in a checkbox and it replaces the content of a kupu field with another text. The main problem is that kupu fields use an iframe, and thus normal KSS selectors can't match the iframe content... :-/ Is that possible or am I missing something here? -- Dorneles Trem?a X3ng Web Technology http://nosleepforyou.blogspot.com From hedley at upfrontsystems.co.za Fri Aug 15 11:34:09 2008 From: hedley at upfrontsystems.co.za (Hedley Roos) Date: Fri, 15 Aug 2008 11:34:09 +0200 Subject: [Kss-devel] Using a context for selectors In-Reply-To: References: Message-ID: <48A54D91.3030804@upfrontsystems.co.za> Dorneles Trem?a wrote: > Hello, > > with jQuery, you can use a context for the selectors: > > jq('selector', context) > > ...where context can be DOM Element, Document or jQuery. > > Is there a way to do that with KSS? > > I was thinking in something along these lines: > > core.replaceInnerHTML('selector', 'content', > context="frames['frame-name'].document") > I don't think that is possible. > My usecase is: you click in a checkbox and it replaces the content > of a kupu field with another text. The main problem is that kupu > fields use an iframe, and thus normal KSS selectors can't match > the iframe content... :-/ > Interesting use case, and certainly very useful. You would probably have to write your own selector. I haven't done that yet, but I guess if you look at the kss source it won't be too difficult. Good luck! Hedley From gotcha at bubblenet.be Tue Aug 19 16:45:20 2008 From: gotcha at bubblenet.be (Godefroid Chapelle) Date: Tue, 19 Aug 2008 16:45:20 +0200 Subject: [Kss-devel] Using a context for selectors In-Reply-To: <48A54D91.3030804@upfrontsystems.co.za> References: <48A54D91.3030804@upfrontsystems.co.za> Message-ID: <48AADC80.2090209@bubblenet.be> Hedley Roos wrote: > Dorneles Trem?a wrote: >> Hello, >> >> with jQuery, you can use a context for the selectors: >> >> jq('selector', context) >> >> ...where context can be DOM Element, Document or jQuery. >> >> Is there a way to do that with KSS? >> >> I was thinking in something along these lines: >> >> core.replaceInnerHTML('selector', 'content', >> context="frames['frame-name'].document") >> > > I don't think that is possible. Right, it is not. > >> My usecase is: you click in a checkbox and it replaces the content >> of a kupu field with another text. The main problem is that kupu >> fields use an iframe, and thus normal KSS selectors can't match >> the iframe content... :-/ >> > > Interesting use case, and certainly very useful. You would probably have > to write your own selector. I haven't done that yet, > but I guess if you look at the kss source it won't be too difficult. You'd need to hack : as selectors have not been foreseen to be compound values, you'd need to multiplex your two values. However, you could create your own client action that does know of iframes... > > Good luck! > Hedley -- Godefroid Chapelle (aka __gotcha) http://bubblenet.be From gotcha at bubblenet.be Mon Aug 25 10:30:16 2008 From: gotcha at bubblenet.be (Godefroid Chapelle) Date: Mon, 25 Aug 2008 10:30:16 +0200 Subject: [Kss-devel] Introducing Grok / KSS : feedback after 1 week In-Reply-To: References: <5e1183fa0808221004m5d8e7ffdne1d6148ed1d77102@mail.gmail.com> Message-ID: <48B26D98.7020403@bubblenet.be> Balazs Ree wrote: > Hi Sebastien, > >> Sebastien Douche wrote: >>> Hi there, >>> A small post after familiarized Grok (+ KSS) in my company, with >>> Godefroid (__gotcha) as Guest Star. >>> >>> + Using Grok is easy. >>> >>> + Using KSS is very easy. > > Thank You. We are happy to see that our work brings value to others. > > >>> - Lack of KSS support for Zope 3 application (not Plone). >> Could you elaborate? Perhaps Godefroid can also describe what he thinks >> the plan should be. I am afraid Sebastien used a very wide statement for small problems. There are two issues concerned by his statement : 1) Some people claim that kss.core is not Python 2.5 compatible (I did not try myself). Even if this is true, I think it is not a big deal at all until we get an official statement from the community that Z3 is supported over 2.5. Anyway, I suppose it will be very easy to fix. 2) KSS could play a better game in skin/layer setup. Currently, KSS views are defined in the default layer. This implies that someone that does not want to use the default layer has to register all KSS views again in his own layer/skin. (This is also a small issue.) We could fix this by putting all KSS views in its own layer : this would allow to integrate KSS layer separately from the default layer. However, this would imply that a custom skin would be obligatory for any application using KSS. This would then imply that the given layer should be registered for Plone (possible since plone.browserlayer in 3.1). I am not sure which constraint is worse : being forced to use default layer or being forced to create a custom skin. PS: I am not sure if this discussion needs to happen on grok or kss list. Grokkers, feel free to send us to our own list ;-) -- Godefroid Chapelle (aka __gotcha) http://bubblenet.be From ree at ree.hu Mon Aug 25 10:58:04 2008 From: ree at ree.hu (Balazs Ree) Date: Mon, 25 Aug 2008 10:58:04 +0200 Subject: [Kss-devel] Introducing Grok / KSS : feedback after 1 week References: <5e1183fa0808221004m5d8e7ffdne1d6148ed1d77102@mail.gmail.com> <48B26D98.7020403@bubblenet.be> Message-ID: On Mon, 25 Aug 2008 10:30:16 +0200, Godefroid Chapelle wrote: > Balazs Ree wrote: >> Hi Sebastien, >> >>> Sebastien Douche wrote: >>>> Hi there, >>>> A small post after familiarized Grok (+ KSS) in my company, with >>>> Godefroid (__gotcha) as Guest Star. >>>> >>>> + Using Grok is easy. >>>> >>>> + Using KSS is very easy. >> >> Thank You. We are happy to see that our work brings value to others. >> >> >>>> - Lack of KSS support for Zope 3 application (not Plone). >>> Could you elaborate? Perhaps Godefroid can also describe what he >>> thinks the plan should be. > > I am afraid Sebastien used a very wide statement for small problems. > > There are two issues concerned by his statement : > > 1) Some people claim that kss.core is not Python 2.5 compatible (I did > not try myself). Even if this is true, I think it is not a big deal at > all until we get an official statement from the community that Z3 is > supported over 2.5. Anyway, I suppose it will be very easy to fix. I agree. We should also consider that we plan to make kss.base take off, which, being a python-only library, probably supports Python 2.5 already. > 2) KSS could play a better game in skin/layer setup. Currently, KSS > views are defined in the default layer. This implies that someone that > does not want to use the default layer has to register all KSS views > again in his own layer/skin. (This is also a small issue.) > > We could fix this by putting all KSS views in its own layer : this would > allow to integrate KSS layer separately from the default layer. > > However, this would imply that a custom skin would be obligatory for any > application using KSS. > > This would then imply that the given layer should be registered for > Plone (possible since plone.browserlayer in 3.1). > > I am not sure which constraint is worse : being forced to use default > layer or being forced to create a custom skin. Thank you. I am not very experienced in layers in practice, so maybe what I write below is wrong, but this is my first idea for approaching this problem. Again, I think we should consider solving this in kss.base / kss.zope. The javascript resources are defined slightly differently in kss.zope then they are in kss.core. There is still a zcml directive that defines the contatenated javascript resource, but it will no longer need the list of all javascript files as input, since this information will come from the kss plugin registry (existing on plain python level). Which means it's easy to use this directive from zcml, which was not the case with kss.core. So, we could add a layer attribute to this directive. Then, kss.zope can keep on defining the resource for the default layer. However anyone that wants to have a custom layer, could simply define the kss javascript resource for the desired layer, from zcml. This could work in Zope. Grok then, can decide, what approach it takes to provide the Grok Way of handling the same resource for custom layers. Best wishes, -- Balazs Ree From hedleyroos at gmail.com Thu Aug 28 16:40:29 2008 From: hedleyroos at gmail.com (Hedley Roos) Date: Thu, 28 Aug 2008 16:40:29 +0200 Subject: [Kss-devel] macroContent thoughts Message-ID: <776caf8b0808280740g240604a3u4c91ff80349fb316@mail.gmail.com> Hi all I've avoided plonekssview.macroContent for a while now since I had my own pattern from the PloneAzax days. I use kss very heavily in all my apps, so I've bumped into a few use cases which I don't think macroContent can handle. 1. It cannot render a macro in a viewlet. I have code that can do this. The real pain is getting at that viewlet incode though - the kss bit is easy. 2. It assumes context is aq_inner(self.context). I think self.header_macros.__of__(macroobj.aq_parent) basically boils down to that. Sometimes you want to specify a different context. 3. It does not allow setting variables in scope for the eventual template. It seems everything must be fetched from the request. This means I cannot re-use some templates. Apologies if I'm wrong in places. Like I said I have solutions to all the cases. I'd love to contribute. Hedley