Re: [Zope-dev] Request typing (to get the xmlrpc layer discussion finished)
On Monday 17 December 2007, Jim Fulton wrote: WRT this use case, I strongly suspect it would be simpler and easier to support defining multiple configurations in ZCML and a mechanism to specify different configurations for different sites within an instance. In fact, I think Stephan Richter added this a while ago. Yes, see z3c.baseregistry. Base registries effectively allow skinning of all components registered with the component registries. This includes adapters and utilities. I sometimes call base registries a way to do site-based component skinning. :-) However, see my other responses (when written ;-) on why skins are still useful. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Request typing (to get the xmlrpc layer discussion finished)
On Monday 17 December 2007, Jim Fulton wrote: As a usecase take a forum application which should be installed more than once in an instance but needs different layouts and also different subset of functionality. I don't have this use case. I wonder how many people do. I certainly do have this use case all the time. :-) We often have to write a publically facing and an admin UI. The admin UI should not be available publically. With skins this can be solved very elegantly. In a bigger project, we have a true hosted services environment, where customers want very customized UIs, both in look and feel. In those cases skinning is very important to us, since we can choose which layer we have to use as bases for the custom skin. We tend to think up complex use cases and then make the zope framework more complicated to deal with them. Sometimes these are legitimate use cases, but they are rarely common cases and their solutions should generally not be inflicted on the masses. I think that using default browser layer is the way for people not to worry about skins. However, I have found that this is a really bad long-term solution. The biggest problem is that I do not have any control over the default browser layer. I install a package to use its API, but often get a lot of views for the default browser layer as well. Without careful review, there is now way for me to tell whether this opens a security hole. It is thus much safer, to start a new skin from scratch, and carefully add registrations. We developed some minimal base skins (see z3c.layer), which do the most basic setup and which we reviewed somewhat for security. And even if the the security is okay, I would not want to expose all the views. I want control, but often, registering everything from scratch is very tedious. Layers -- and thus skins -- act as collection s of view registrations. I think that z3c.form* demonstrates this very nicely. If I only use the IFormLayer, I only get the widgets, and only by inheriting from IDivFormLayer or ITableFormLayer, I also get form layout components. As Jim pointed out in another E-mail, base component registries (such as z3c.baseregistry) can solve this problem, but only partially. Base registries can only be applied on the site-level. So sure, I can customize the look and feel (and much more) for every site. But for skinning I often want multiple UIs for the *same* site. This problem cannot be solved with base registries today without writing additional software. And this use case is extremely important to us! Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Request typing (to get the xmlrpc layer discussion finished)
On Monday 17 December 2007, Christian Zagrodnick wrote: a couple of weeks ago there was some discussion about the skin/layer support for XML-RPC which I implemented without asking (shame on me). As some time has passed now everybody could have some fresh thoughts about it. Since the original implementation and discussion, I had a lot more time to discuss this proposal with Roger (who was heavily in favor of it), think about it, and work on other HTTP-based protocols. Thus, I am now in favor of a solution. It is good that you laid out the implementation details as well. Let me first summarise: * Skin and layers should be seen as typing the request. Well, that's what they actually do. * There are no general objections against having layers for XML-RPC. I think there were pretty strong objections to layers for XML-RPC and all other non-browser HTTP requests. * There are objections against using ++skin++ for XML-RPC, ++api++ would be fine. I think I was against anything typing non-browser related. Therefore we propose to: * Create in zope.publisher.interfaces: class IRequestType(zope.interface.interfaces.IInterface): pass This is good. * Rename IXMLRPCSkinType to IXMLRPCAPIType(IRequestType) and create a traverser ++api++ for IXMLRPCApiType. This would not fulfill the use case that Fred brought up in his response to the proposal. I really like his points and his historical considerations. I think, it would be ideal to have one way to specify the request type, maybe through ++type++. If, for legacy reasons, ++skin++ is easier to use, then that's fine with me too. Let's widen our considerations to JSON and REST as well. What do others think? * Use IRequestType as new base of IBrowserSkinType (instead of IInterface). Okay. * Do *not* provide any traverser for IRequestType since the traversers should be close to the “channel†so it is easy to understand what is happening. If the traverser name is too far fetched we end in confusion like with skin for xmlrpc. Right, this is very important. The same rule should apply for IBrowserRequest; see the other discussion thread of this mail. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Request typing (to get the xmlrpc layer discussion finished)
On Dec 17, 2007, at 8:22 AM, Christian Zagrodnick wrote: Hi, a couple of weeks ago there was some discussion about the skin/layer support for XML-RPC which I implemented without asking (shame on me). As some time has passed now everybody could have some fresh thoughts about it. Let me first summarise: * Skin and layers should be seen as typing the request. * There are no general objections against having layers for XML-RPC. I have a general objection for reasons of complexity. Why do we need this? In fact, I find skins in general to introduce more complexity than they're worth. (My $.02. This is not a veto.) Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Request typing (to get the xmlrpc layer discussion finished)
Am 17.12.2007 um 15:40 schrieb Jim Fulton: On Dec 17, 2007, at 8:22 AM, Christian Zagrodnick wrote: Hi, a couple of weeks ago there was some discussion about the skin/ layer support for XML-RPC which I implemented without asking (shame on me). As some time has passed now everybody could have some fresh thoughts about it. Let me first summarise: * Skin and layers should be seen as typing the request. * There are no general objections against having layers for XML-RPC. I have a general objection for reasons of complexity. Why do we need this? About the specifics with skins for other protocols than http I can not say much. In fact, I find skins in general to introduce more complexity than they're worth. This baffles me somewhat. At the moment I see skins/layers as the only mechanism to let developers using an application to customize it, possibly more than once in the same instance. I find them not optimal, because they only allow customizing on the outer most level. But overrides is a failure as I understand it. I understand, that there is a trend to distinguish between libraries (with less zcml) and applications (with zcml to configure reused libraries). But on the level of applications I know of no other mechanism than layers. So what should be used or invented instead? As a usecase take a forum application which should be installed more than once in an instance but needs different layouts and also different subset of functionality. With regards, __Janko -- Janko Hauser email: [EMAIL PROTECTED] mobile: +49 1721 641552 PGP.sig Description: Signierter Teil der Nachricht ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Request typing (to get the xmlrpc layer discussion finished)
On Dec 17, 2007, at 10:07 AM, Janko Hauser wrote: ... This baffles me somewhat. At the moment I see skins/layers as the only mechanism to let developers using an application to customize it, possibly more than once in the same instance. I find them not optimal, because they only allow customizing on the outer most level. But overrides is a failure as I understand it. How are overrides a failure? Skins, after all do nothing but override views. ... So what should be used or invented instead? I use overrides. As a usecase take a forum application which should be installed more than once in an instance but needs different layouts and also different subset of functionality. I don't have this use case. I wonder how many people do. We tend to think up complex use cases and then make the zope framework more complicated to deal with them. Sometimes these are legitimate use cases, but they are rarely common cases and their solutions should generally not be inflicted on the masses. WRT this use case, I strongly suspect it would be simpler and easier to support defining multiple configurations in ZCML and a mechanism to specify different configurations for different sites within an instance. In fact, I think Stephan Richter added this a while ago. Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Request typing (to get the xmlrpc layer discussion finished)
On Dec 17, 2007 8:22 AM, Christian Zagrodnick [EMAIL PROTECTED] wrote: There are different kinds of request (BrowserRequest, XMLRPCRequest, FTPRequest, …) which depend on the channel or server zope is accessed through. We have this use case: The server is accessed through a number of different channels, each associated with some URL re-writing. This includes in most cases a ++skin++name path element, often with additional path elements. The skin used is associated with the channel. We have a couple of different cases where there are XML-RPC methdods that should be associated with the channel as well. Using anything other than ++skin++ seems like silliness in this case: we need something that can associate the request with a channel, regardless of the type of the request (XML-RPC, browser, etc.). We don't care that ++skin++ is the name of the request-typing path element, but we do want a single path element that can mark the request regardless of the request type. Preferably without re-architecting our applications. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Request typing (to get the xmlrpc layer discussion finished)
Am 17.12.2007 um 16:16 schrieb Jim Fulton: On Dec 17, 2007, at 10:07 AM, Janko Hauser wrote: ... This baffles me somewhat. At the moment I see skins/layers as the only mechanism to let developers using an application to customize it, possibly more than once in the same instance. I find them not optimal, because they only allow customizing on the outer most level. But overrides is a failure as I understand it. How are overrides a failure? Perhaps I do not understand them good enough, but application developers can not use them, as there can be different applications by other developers overriding the same. Integrators could use them to overwrite everything, but only once. Skins, after all do nothing but override views. Yes, but by defining a scope, which can be made location aware, during traversal. ... So what should be used or invented instead? I use overrides. As a usecase take a forum application which should be installed more than once in an instance but needs different layouts and also different subset of functionality. I don't have this use case. I wonder how many people do. I think every multisite setup has this problem. We tend to think up complex use cases and then make the zope framework more complicated to deal with them. Sometimes these are legitimate use cases, but they are rarely common cases and their solutions should generally not be inflicted on the masses. WRT this use case, I strongly suspect it would be simpler and easier to support defining multiple configurations in ZCML and a mechanism to specify different configurations for different sites within an instance. In fact, I think Stephan Richter added this a while ago. Oh that would be a new information for me, so I would be very interested, where this is implemented. Thanks in advance __Janko -- Janko Hauser email: [EMAIL PROTECTED] mobile: +49 1721 641552 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Request typing (to get the xmlrpc layer discussion finished)
On Dec 17, 2007 10:32 AM, Janko Hauser [EMAIL PROTECTED] wrote: Oh that would be a new information for me, so I would be very interested, where this is implemented. z3c.baseregistry -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Request typing (to get the xmlrpc layer discussion finished)
Am 17.12.2007 um 16:34 schrieb Fred Drake: On Dec 17, 2007 10:32 AM, Janko Hauser [EMAIL PROTECTED] wrote: Oh that would be a new information for me, so I would be very interested, where this is implemented. z3c.baseregistry Uhu, thanks, this looks like it will open up many possibilities. And I'm sorry to have highjacked the original question. So back to Christians original question. With regards, __Janko -- Janko Hauser email: [EMAIL PROTECTED] mobile: +49 1721 641552 PGP.sig Description: Signierter Teil der Nachricht ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
