[Zope3-Users] Re: View or content provider
Daniel Nouri wrote: I'm sure that your concepts work nicely for you there. But maybe they are not the most practical way to define my kind of page composition use case, which needs to be highly customizable at runtime (vs. zcml time). Component registrations can be done at runtime easily in a local component registry. Also, there is nowhere in the viewlet manager API a requirement that says that the viewlets have to be looked up using adapters. In fact, for a list of articles, I would not use adaptation in the same way the default implementation does it. Well, the way I define viewlet is that it's a content provider that's looked up by another content provider (the viewlet manager) using the adapter registry. That's why, after all, it's a *view*let. Portlets are also content providers, they're simply looked up differently, which distincts them from viewlets. As to plone.portlets, I think they are heavily overengineered. Last time I looked at its API, it was heavily bloated. This might be a result of being a Plone package though, I do not know, but I would certainly implement them much slimmer. Maybe the reason is that viewlets are not the best starting point for Plone's use case? I think they are. I would just implement the API very differently. I just wish the Plone developers would have asked us for comments when using Zope 3 technologies. Martin Aspeli and I were in close context when he implemented plone.portlet. While I too was a bit overwhelmed of the amounts of machinery it ended up using, I also acknowledge the various complicated use cases that it's trying to solve. In the end, most of the machinery is there to support TTW configurability. I find this part is generally underestimated, both in effort and in LOC (probably because we have so little of it on Zope3 these days). plone.portlet seems to enjoy some success, though. Geir Baekholt told me, for example, that their new version of LinguaPlone is using portlets to render content that's commont to all translations of a document (e.g. figures). -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: View or content provider
On 23 Jul 2007, at 17:51 , Daniel Nouri wrote: As to plone.portlets, I think they are heavily overengineered. Last time I looked at its API, it was heavily bloated. This might be a result of being a Plone package though, I do not know, but I would certainly implement them much slimmer. Maybe the reason is that viewlets are not the best starting point for Plone's use case? I think they are. I would just implement the API very differently. I just wish the Plone developers would have asked us for comments when using Zope 3 technologies. Martin Aspeli and I were in close context when he implemented plone.portlet. While I too was a bit overwhelmed of the amounts of machinery it ended up using, I also acknowledge the various complicated use cases that it's trying to solve. I wonder if that machinery would have been considerably less heavy if we would have sticked to CMF expressions and the like for registrations (compare CMF's actions tool). I keep being amazed by how much flexibility I can achieve by simply combining Python expressions with views, e.g. include this element if context/@@plone/isRTL. (I know you're not a big fan of the @@plone view, but it's just an example. :) Python expressions can certainly be very powerful, but they have their limits. Just like adaption does (the isRTL use case is hard to do with adaption, I suppose). In the end, most of the machinery is there to support TTW configurability. I find this part is generally underestimated, both in effort and in LOC (probably because we have so little of it on Zope3 these days). What do you mean by this part is generally underestimated. Do you think it's understandable that it's grown so complex, Yes, at least for the use cases that Martin brought up. Note that I tried to warn him several times not to over-engineer, but I think it's normal that at the beginning you always end up doing that. It's never too late to simplify by introducing shortcuts... plone.portlet seems to enjoy some success, though. Geir Baekholt told me, for example, that their new version of LinguaPlone is using portlets to render content that's commont to all translations of a document (e.g. figures). Well, any modern Plone Product will have to adopt the new portlets sooner or later. (There is a backwards compatibility mode, but still.) That's why I'm making such a fuss out of it. ;) Who says that the backwards compat mode has to away. Or that there can't be another shortcut that handles all the simple cases? ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: View or content provider
Hi Stephan! Stephan Richter wrote: On Tuesday 17 July 2007 14:28, Daniel Nouri wrote: plone.portlets introduces some two dozen (!) interfaces/concepts on top of viewlets in order to implement the flexibility that it needs. E.g. it introduces an 'available' method/property that controls visibility, which viewlets by themselves lack. I imagine I could do this with less overhead without viewlets (see my other mail), or IOW: viewlets don't seem inherently flexible to me. Then you do not understand them. They are inherently flexible because content providers are multi-adapters of context, request, and view and viewlets are multi-adapters of context, request, view, and viewlet manager. Using adapted objects as discriminators has opened totally new ways of developing UI patterns in Zope 3. We have heavily learned from using those patterns and I think the new z3c.form* framework benefitted a lot from it. You make it sound like the more objects you adapt, the more flexible you are. Which is true to a certain extent, but at the same time, the more objects you adapt from, the harder are the registrations to read and understand and the more tedious they are to write (compared to e.g. CMF expressions). Also, adaptation only works to a certain extent as a way to determine if a viewlet should be displayed or not. So even with four interfaces to adapt from, I cannot register by permission or by a rule like are there any news items available. I'm not saying that these use cases can't be solved easily, it's just that the registry for viewlets doesn't have a way to express them with adaptation alone. BTW, what I've seen from z3c.form* looked quite impressive! I'm sure that your concepts work nicely for you there. But maybe they are not the most practical way to define my kind of page composition use case, which needs to be highly customizable at runtime (vs. zcml time). As to portlets. When talking about portlets, the Web community refers usually to features described in JSR 168. Viewlets have absolutely no ambition to come even close to this. In fact, we specifically designed viewlets to do much less with the intend to later implement portlets on top of them. To you viewlets might look extremely simple, in idea and implementation. But this did not come over night and we said: Oh cool, let's use a triplet-adapter to do content providers. Roger and I did an independent implementation of viewlets, then fiercly discussed for nearly a week (people attending the Tuebingen sprint can attest to this) the design goals and implementation. The simple design of both, content provider and viewlets, is thus a result of a deep understanding of UI development problem, not something that was thrown together quickly. You know, often less is more! I'm all for less is more! As to plone.portlets, I think they are heavily overengineered. Last time I looked at its API, it was heavily bloated. This might be a result of being a Plone package though, I do not know, but I would certainly implement them much slimmer. Maybe the reason is that viewlets are not the best starting point for Plone's use case? In any event, I'm glad that viewlets exist, and I hope I'll soon have a chance to use them in a way that they were designed to be used. Currently, in Plone 3, they are a source of frustration to me. (And no, it's not because Plone developers are inherently stupid :-P) Regards, Daniel ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: View or content provider
Hermann Himmelbauer wrote: Am Dienstag, 17. Juli 2007 14:08 schrieb Stephan Richter: On Monday 16 July 2007 19:32, Daniel Nouri wrote: I do not recommend using views for content that is only used inside a template. Because context/@@viewname is also traversable as a real view and will probably show up in google. How would it show up in Google? Google bots don't try arbitrary URLs, they follow links. Using ordinary views for parts of a HTML page works perfectly for me. It works at the cost of security. How do you know that noone will figure out those views? And how do you know that they are properly secured, if you never test them standalone? This might not be too problematic for a single project, but would you like to install a package and suddenly get all those views that you do not know whether they are properly secured and may reveal sensitive information? I can tell you that some of my clients do care about this! I agree with this: Security through obscurity is always a bad idea. In cases where content is not yet ready for the public, it may be o.k. to hide information by unknown URLs, but not on a long-term scale. You can bet that someone will in some way find out the URL. For instance, I once published a site by sending a code snippet with the URL to the Plone mailing list and Google collected it from the archive (fortunately, no big deal in my case). You got the wrong idea. My intention was not to say: No one knows how to access those views, so they're secure. But rather: I wouldn't worry about search engines picking up those (public) snippets of HTML. The problem here is that e.g. Google would index parts of pages that should only be seen in the context of a bigger, complete page. Regards, Daniel ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: View or content provider
On Tuesday 17 July 2007 14:18, Daniel Nouri wrote: Content providers and viewlets are not publically traversable. Being traversable does not make them insecure but it offers one more point of access and a potential security hole if not reviewed correctly. Do you test the security for all those little views? You're right. There's potential security holes there. However, my feeling is that views are well understood and that securing them is trivial. Uh hu, if you say so. I bet you, you do not even know about half the URLs that are available on any given context. Just use APIDOC to discover them. Actually, I can think of why securing them individually is actually quite useful. Imagine I register a utility that's a list of view or adapter names (for my site's left column). A rendering view would go over that list, see if the views apply by trying to look them up on request and context and then check security. Lastly, it would render the remaining items. Well, that tests if the security is too tight not too loose. To each his own. However, I'm not afraid to roll my own based on CA primitives, and others shouldn't be either. No you should not, but you should be aware of certain things, including security. If you do not want to listen to our experiences you do not have to. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: View or content provider
Hi Roger! Roger Ineichen wrote: If you like a explicit pattern, then calling views in ZPT is fine. On the other hand, if you use a viewlet manager, the manager can implement conditions and show based on rules e.g. session state or login status more or less viewlets. I think best reason to use viewlet is, if you need a very flexible conditional concept. plone.portlets introduces some two dozen (!) interfaces/concepts on top of viewlets in order to implement the flexibility that it needs. E.g. it introduces an 'available' method/property that controls visibility, which viewlets by themselves lack. I imagine I could do this with less overhead without viewlets (see my other mail), or IOW: viewlets don't seem inherently flexible to me. Regards, Daniel ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: View or content provider
On Tuesday 17 July 2007 14:28, Daniel Nouri wrote: plone.portlets introduces some two dozen (!) interfaces/concepts on top of viewlets in order to implement the flexibility that it needs. E.g. it introduces an 'available' method/property that controls visibility, which viewlets by themselves lack. I imagine I could do this with less overhead without viewlets (see my other mail), or IOW: viewlets don't seem inherently flexible to me. Then you do not understand them. They are inherently flexible because content providers are multi-adapters of context, request, and view and viewlets are multi-adapters of context, request, view, and viewlet manager. Using adapted objects as discriminators has opened totally new ways of developing UI patterns in Zope 3. We have heavily learned from using those patterns and I think the new z3c.form* framework benefitted a lot from it. As to portlets. When talking about portlets, the Web community refers usually to features described in JSR 168. Viewlets have absolutely no ambition to come even close to this. In fact, we specifically designed viewlets to do much less with the intend to later implement portlets on top of them. To you viewlets might look extremely simple, in idea and implementation. But this did not come over night and we said: Oh cool, let's use a triplet-adapter to do content providers. Roger and I did an independent implementation of viewlets, then fiercly discussed for nearly a week (people attending the Tuebingen sprint can attest to this) the design goals and implementation. The simple design of both, content provider and viewlets, is thus a result of a deep understanding of UI development problem, not something that was thrown together quickly. You know, often less is more! As to plone.portlets, I think they are heavily overengineered. Last time I looked at its API, it was heavily bloated. This might be a result of being a Plone package though, I do not know, but I would certainly implement them much slimmer. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
