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
On Monday 17 October 2005 13:27, Stéphane Brunet wrote: > * If I decide to create a brand new skin, based heavily on content > provider and viewlets, which sounds easier to do than the present way to > do it, how should I provide the "glue" between the components which are > not "content provider-capable" yet ? Obviously you cannot affect existing views. The only hook you have here is to override the main template and insert content provider hooks there. This is what I am doing for SchoolTool. > * By creating the content provider, I could gather information from > various kinds of object and provide a composite view of them. Is that > right ? Yes, though the original context is still the object you are viewing. So you have to do the object digging yourself, which is usually not that hard. In the complex example of viewlets you can see how viewlets themselves can be adapted by an alternative context. 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
Gary Poster wrote: ... 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. I thought the anology would be between widget -> viewlet and not widget -> content provider. I read your subview readme. IMO the composition pattern of subviews you proposed is very interesting too. Comparing the lookup signatures... subview -> (context, request) content provider -> (context, request, view) viewlet -> (context, request, view, manager) ... 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. 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
Stephan Richter wrote: On Monday 17 October 2005 12:21, Gary Poster wrote: Similarly to your comments, I'm worried about viewlets getting in Zope 3.2 without addressing the update problem, myself. Maybe you can simply put an XXX or a warning and be happy with it: not my call. :-) No, I will not distribute it unless we are in agreement. I will probably merge the work into the trunk though, because I want SchoolTool to use it. ;-) Regards, Stephan Hi, I have just read the examples of Content provider and Viewlets and find them _really_ great, and even easier to understand than the present implementation of views with METAL macros, while providing unlimited possibilities. I have a two small questions however : * If I decide to create a brand new skin, based heavily on content provider and viewlets, which sounds easier to do than the present way to do it, how should I provide the "glue" between the components which are not "content provider-capable" yet ? * By creating the content provider, I could gather information from various kinds of object and provide a composite view of them. Is that right ? Thanks in advance, Stéphane ___ 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 Monday 17 October 2005 12:21, Gary Poster wrote: > > 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. > > Sounds great to me in theory. ;-) Well, at least some of us have to meet. I could probably come to F12g for a couple of days. > Similarly to your comments, I'm worried about viewlets getting in > Zope 3.2 without addressing the update problem, myself. Maybe you > can simply put an XXX or a warning and be happy with it: not my > call. :-) No, I will not distribute it unless we are in agreement. I will probably merge the work into the trunk though, because I want SchoolTool to use it. ;-) 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:17 PM, Stephan Richter wrote: Thanks for your thoughts and review. ... 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. Sounds great to me in theory. ;-) Similarly to your comments, I'm worried about viewlets getting in Zope 3.2 without addressing the update problem, myself. Maybe you can simply put an XXX or a warning and be happy with it: not my call. :-) 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 Monday 17 October 2005 12:07, Gary Poster wrote: > On Oct 17, 2005, at 12:02 PM, Stephan Richter wrote: > > Right, this is a serious problem. I would really like to see some more > > detailed documentation about this approach. But I am pretty sure > > this is a > > problem orthogonal to the content provider code and can be solved in a > > different package that then just has to work well with the others. > > I thought that was what I was proposing. Do I misunderstand your > point, then? Great! :-) Then we are on the same page. 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 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 11:59 AM, Stephan Richter wrote: On Saturday 15 October 2005 15:48, Gary Poster wrote: 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. Note that I think that AJAX, drag-and-drop and all of this stuff is much, much higher level than even viewlets, let alone content providers. Both, content providers and viewlets, APIs have nothing to say about the interaction with the view or other content providers/viewlets. This type of contract was purposefully deferred to higher level APIs. For example, in SchoolTool we have no need for those type of things. Right, which is why the contract in subview is all about the parts of the decisions necessary for interoperability, rather than actual AJAX or drag and drop implementation. SchoolTool and other similar projects should have to do nothing or virtually nothing to "get along". The subview package includes no JS, for instance; some might live in zope.app.subview as an example of one way to use the agreements. You also include "all of this stuff": not sure what you are including there. If you mean prefixes and a two-stage update/render pattern, I flat out disagree with you. From another reply, I don't think you do. If you mean a persistence mechanism, then this is an opt-out part of the pattern that nonetheless is important to define at a low level: if a subview is not persistent or otherwise stateful then it dirties any containing subviews so that it is no longer persistent, even if the container thinks it is. 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: > 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. > 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. :-) 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:02 PM, Stephan Richter wrote: Right, this is a serious problem. I would really like to see some more detailed documentation about this approach. But I am pretty sure this is a problem orthogonal to the content provider code and can be solved in a different package that then just has to work well with the others. I thought that was what I was proposing. Do I misunderstand your point, then? 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: > 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. Right, this is a serious problem. I would really like to see some more detailed documentation about this approach. But I am pretty sure this is a problem orthogonal to the content provider code and can be solved in a different package that then just has to work well with the others. 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 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. Note that I think that AJAX, drag-and-drop and all of this stuff is much, much higher level than even viewlets, let alone content providers. Both, content providers and viewlets, APIs have nothing to say about the interaction with the view or other content providers/viewlets. This type of contract was purposefully deferred to higher level APIs. For example, in SchoolTool we have no need for those type of things. 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: > 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 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
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
Hi Gary > -Original Message- > From: Gary Poster [mailto:[EMAIL PROTECTED] > Sent: Sunday, October 16, 2005 4:09 PM > To: [EMAIL PROTECTED] > Cc: zope3-dev@zope.org; [EMAIL PROTECTED] > Subject: Re: [Zope3-dev] RFC: Content Providers and Viewlets > > > On Oct 16, 2005, at 9:42 AM, Stephan Richter wrote: > > > 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. > > Absolutely; I understand the necessity of the TAL/TALES stuff > for the > viewlet package. I was questioning the TALES directive being placed > in the contentprovider package, since the only use case Roger > mentioned for the contentprovider package (as separate from > viewlet) > didn't need it. That suggests it perhaps could be pushed up into > viewlet, since there appears to be no coherent story for use of the > contentprovider package in TALES without the code in viewlet. So > just move the TALES into viewlet with the rest of it, and leave only > the interfaces for the multiadapter lookup in contentprovider. > > If my objections on this point merely lead to a compelling bit of > elaboration in contentprovider's README as to when and why one might > use contentprovider without viewlet (i.e., "this package is useful > when you aren't using ZPTs but want the basic pattern used by the > viewlet package, or when [...some other story that explains why the > TALES code is there...]") then I will regard my time providing > feedback on this part of the proposal as well-spent. Another question is, does a future portlet implementation depend on the viewlet package or not. I don't this know right now. But if we not depend on the viewlet package, we will use the TALES expression as well. Then the TALES expression should be located in the content provider package, I guess. But I think we can find a definitive answer to the location of the TALES directive if we figured out how the dependencies are at all. Regards Roger Ineichen > > BTW, I am going to respond to your longer mail later. > > Excellent, thanks. > > 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 16, 2005, at 9:42 AM, Stephan Richter wrote: 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. Absolutely; I understand the necessity of the TAL/TALES stuff for the viewlet package. I was questioning the TALES directive being placed in the contentprovider package, since the only use case Roger mentioned for the contentprovider package (as separate from viewlet) didn't need it. That suggests it perhaps could be pushed up into viewlet, since there appears to be no coherent story for use of the contentprovider package in TALES without the code in viewlet. So just move the TALES into viewlet with the rest of it, and leave only the interfaces for the multiadapter lookup in contentprovider. If my objections on this point merely lead to a compelling bit of elaboration in contentprovider's README as to when and why one might use contentprovider without viewlet (i.e., "this package is useful when you aren't using ZPTs but want the basic pattern used by the viewlet package, or when [...some other story that explains why the TALES code is there...]") then I will regard my time providing feedback on this part of the proposal as well-spent. BTW, I am going to respond to your longer mail later. Excellent, thanks. 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 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
Hi Gary > Behalf Of Gary Poster > Sent: Saturday, October 15, 2005 9:49 PM > To: [EMAIL PROTECTED] > Cc: zope3-dev@zope.org > Subject: Re: [Zope3-dev] RFC: Content Providers and Viewlets > > [...] > > 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 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. > 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 ... Regards Roger Ineichen [...] > > Gary > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: > http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch > > ___ 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
