Re: [Zope3-dev] RFC: Content Providers and Viewlets
On Tuesday 18 October 2005 03:26, Dominik Huber wrote: ... the current viewlet implementation lacks of this pattern, because it use different adaptions for content providers and viewlets. Looking from this composite subview perspective, the view and manager parameters of viewlets brings some redundant informations. In my understanding this signature was choosen to gain a bigger presentation flexibility. Maybe we could use a pattern like the lookup of named templates (formlib) to decouple presentation of subviews, but using similar signature for content providers and viewlets. It is redundant in the sense that you can get to some objects, like the view and request in two different ways, but it is not redundant from the discriminator point of view. You can always choose not to store the adapted objects. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Content Providers and Viewlets
Hi Stephan, I just looked at the examples. I like the current implementation much more, because a viewlet is adapted to its original context (- complex example) and content providers (or viewlet managers) can render itself. Those changes are providing a better encapsulation and a more ca-like comprehension. Cool - Thank you very much! IMO it is very important to provide a standardized way to handle complex, formbased views properly (- prefix like nested widgets) and to sketch the difference between widgets and viewlets out. Regards, Dominik begin:vcard fn:Dominik Huber n:Huber;Dominik email;internet:[EMAIL PROTECTED] tel;work:++41 56 534 77 30 x-mozilla-html:FALSE version:2.1 end:vcard ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Content Providers and Viewlets
On Oct 17, 2005, at 11:23 AM, Dominik Huber wrote: ... IMO it is very important to provide a standardized way to handle complex, formbased views properly (- prefix like nested widgets) Agreed. FWIW, this is another part of the subview package. I tried to spell this out very explicitly. If contentproviders agreed on the subview interfaces, or something like them, then we would have a lower level agreement for all of the page component technologies out there. and to sketch the difference between widgets and viewlets out. The zope.widget package in the branch is currently in disrepair, but the intent is for widgets to be subviews. The subview package actually grew out of the widget work. This won't be ready for 3.2. I personally don't think that I want default widget look-up to require (context, request, view), as opposed to the current (context, request), so I'd be in favor of widget interfaces extending the subview interfaces, not the contentprovider interface. If for some reason someone wanted a widget system with lookups based on contentprovider then that could be an additional layer, still using all of the (context, request)-based code. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Content Providers and Viewlets
On Saturday 15 October 2005 15:48, Gary Poster wrote: viewlets look like a clever pattern. I can see that they can be applied to many use cases; I'll have to think about them to see how much I like the application compared to others we have used, but I have a generally favorable impression so far. contentproviders are a subset of the viewlet pattern, obviously. But when do you think one might build contentproviders and not viewlets? Do you have concrete use cases (or even current uses) for this division? While developing viewlets, we noticed that it was hard for us to keep the concerns apart. Content providers are a direct mapping to Java's content providers and provide a clean API to page templates, specifically. Viewlets are one way of using content providers to make the UI flexible. Viewlets fulfill a bunch of use cases Roger and I (as for SchoolTool) have. After a discussion with Benji this weekend, I am almost certain that viewlets will *not* be the base for the portlet code, since they make some assumptions about containment, which are very useful, but undesirable for portlets. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Content Providers and Viewlets
On Saturday 15 October 2005 15:48, Gary Poster wrote: The rough README is here: http://svn.zope.org/Zope3/branches/ f12gsprint-widget/src/zope/subview/README.txt?view=auto . The whole package is rough; I had to put work on this aside, but it it is currently slated to be my next project, since we need some of the capabilities. Some random comments: - I am glad our URL-scheme for subviews/portlets is pretty much identical. However, this shows me again, that subview's purpose is far above that of content providers and viewlets. - You solve your render-bug problem using a container. If we could make this more of a conceptual container that simply collects all views to be used in a site, then I think this could work very well with content providers and viewlets. This is indeed a hard issue. Right now I see no way how you could flexibly provide additional subviews simply by registration, i.e. solve the viewlet/viewlet manager use case. I really want to talk to you over a higher-bandwidth medium about this. If we could agree on everything but the persistent bits for the 3.2 inclusion then I'd be thrilled. That will mean a number of things have to align though, including our perspectives. :-) I think this can only happen, if we can get Roger, Benji, you and me at the same location for a couple of days. Our ues cases are somewhat different, but all equally important, especially the update bug of yours. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Content Providers and Viewlets
On Oct 17, 2005, at 12:08 PM, Stephan Richter wrote: On Saturday 15 October 2005 15:48, Gary Poster wrote: I also really wish we could agree on a subview-addressing story (for AJAX) and a drag-and-drop story. We have experience with our drag and drop story, and are proposing a new AJAX story for subviews. The subview package only sets up some small foundations so that these can work. This is the reason we have not fully explored implementing portlets yet. I think those type of features are only interesting in very dynamic, CMS-like applications. For example, currently I do not need any of this for SchoolTool. Understood; as mentioned, the subview package offers an underlying agreement, which is important for interoperability. It shouldn't require SchoolTool to do much of anything except perhaps the subview container interface... I'll think about that some more. The persistence use cases are real and important, and I'd like to agree on them, but - we're still having internal discussions about the right way to do it, - it's intended to be an optional part of the subview capabilities, and - it doesn't appear to be pertinent to the viewlet or contentprovider approaches. I really think that sub-views need to be adapters and their state should be stored using a well-defined API. More than that I cannot say, because I have not thought about it. :-) Jim agrees with your assertion, to my knowledge. I am on the fence. Benji disgrees, last I checked. I have certain goals, which I hope to talk through with Jim and also offer up here on the list when I get to it. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Content Providers and Viewlets
On Oct 15, 2005, at 9:52 PM, Roger Ineichen wrote: [...] The content provider package offers just the API for collecting additional content. This pattern can be used directly in python or in page templates. There is no reason that we have to use a viewlet implementation for this. The content provider package offers also a TALES directive called providers. This is only the way can use content provider directly in TAL. Since a viewlet depends only on the page template implementation, there is no reason to merge this two packages together. The viewlet package provides only a standard implementation where we use in relation to the page template concept. Since I use another template language (expermimental), I see no need for the viewlet package. This was my main reason for spliting the content provider and viewlet part in two packages. Let's say the content provider package offers the concept and the viewlet package offers a implementation which depends on page templates. OK, that makes sense. The contentprovider package offers up two bits, then: the pattern of looking up by (context, request, view), and the TALES directive. It sounds like your division of contentprovider and viewlet was directly to support your use of another template language--which is not going to need the TALES directive? But that sounds fine. The most important part of my reply, though, is that I hope we can agree to share an even lower-level interface than contentproviders. If we do, it will address my remaining concerns (expressed below). I will take a look at your Readme next week ... OK, cool. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Content Providers and Viewlets
On Sunday 16 October 2005 09:01, Gary Poster wrote: Let's say the content provider package offers the concept and the viewlet package offers a implementation which depends on page templates. OK, that makes sense. The contentprovider package offers up two bits, then: the pattern of looking up by (context, request, view), and the TALES directive. It sounds like your division of contentprovider and viewlet was directly to support your use of another template language--which is not going to need the TALES directive? The viewlet manager is just a content provider, it thus integrates nicely with TAL and TALES. BTW, I am going to respond to your longer mail later. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Content Providers and Viewlets
On Oct 15, 2005, at 8:24 AM, Stephan Richter wrote: ... What are we looking for? - Comments on the Python API. - Comments on the ZCML API. - Comments on the ZPT API. - Use cases that you might think are not covered by the design and implementation. - Whatever you like to say about it... Hi Stephan (and Roger :-). I have read the contentprovider README and skimmed the viewlet README so far. viewlets look like a clever pattern. I can see that they can be applied to many use cases; I'll have to think about them to see how much I like the application compared to others we have used, but I have a generally favorable impression so far. contentproviders are a subset of the viewlet pattern, obviously. But when do you think one might build contentproviders and not viewlets? Do you have concrete use cases (or even current uses) for this division? The most important part of my reply, though, is that I hope we can agree to share an even lower-level interface than contentproviders. If we do, it will address my remaining concerns (expressed below). I have been working on a subview package off in another branch. It addresses a class of bugs caused by subviews that affect non- contained subviews; sets the stage for AJAX components and for independently-configurable drag and drop between subviews; and wants to contemplate subview persistence as an optional addition. Of these, my biggest concern is the first. When building our portlet system, we discovered a class of rendering bugs that occur when a change to a subview affects other subviews (usually non-nested): the underlying data changes as expected but it is not drawn to screen because the data change was out of order for the rendering. The two stage approach, calculating all state and then rendering all, is the solution we came up with for mitigating what we called 'update bugs'. We have significant experience with the two stage approach, and it is our best answer so far. You do not do this, or have another solution I can see that addresses the same problems. We would want this. I also really wish we could agree on a subview-addressing story (for AJAX) and a drag-and-drop story. We have experience with our drag and drop story, and are proposing a new AJAX story for subviews. The subview package only sets up some small foundations so that these can work. The persistence use cases are real and important, and I'd like to agree on them, but - we're still having internal discussions about the right way to do it, - it's intended to be an optional part of the subview capabilities, and - it doesn't appear to be pertinent to the viewlet or contentprovider approaches. The rough README is here: http://svn.zope.org/Zope3/branches/ f12gsprint-widget/src/zope/subview/README.txt?view=auto . The whole package is rough; I had to put work on this aside, but it it is currently slated to be my next project, since we need some of the capabilities. If we could agree on everything but the persistent bits for the 3.2 inclusion then I'd be thrilled. That will mean a number of things have to align though, including our perspectives. :-) Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
