Re: [Framework-Team] Re: PLIPs for 3.1
On Dec 13, 2007, at 1:19 PM, Andreas Zeidler wrote: On Dec 2, 2007, at 6:19 PM, Martin Aspeli wrote: 1. http://plone.org/products/plone/roadmap/184 - Ship additional portlets +1 as this is purely add-on functionality and contains no risks other than maybe confusing users if done in a non-intuitive way. having that said i think the "use document as portlet" approach makes sense, since it would save us from a lot of extra code or duplication. an easy way to turn a "page" or even an arbitrary content item into a portlet and thereby (optionally) hide it from the navigation and folder listing would be great to have, although the latter, i.e. the generic assignment, might require too many changes for 3.1. having finally worked my way through that (very interesting) thread, i'd like to slightly revise my reply in saying that i'm +1 for including the "simple" solution, and -1 on the "referenced content portlet". that's because i think this should — as mentioned before — be approached in a more generic way and hopefully make it into 4.0. introducing such a portlet now just to completely obsolete it again for 4.0 would be confusing and therefore doesn't really make sense to me. however, if martin has code ready for this, or nearly ready, it could of course be turned into a possibly very helpful add-on for the time being. cheers, andi -- zeidler it consulting - http://zitc.de/ - [EMAIL PROTECTED] friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/ plone 3.0.4 released! -- http://plone.org/products/plone PGP.sig Description: This is a digitally signed message part ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIPs for 3.1
Wichert Akkerman wrote: [..] If you draw this up you basically get a matrix of views with a content-type axis and a tile-type axes. Something like: | main content | portlet | search result | folderlisting ---+---+---+-+ Topic | topic_view.pt | topic_portlet.pt | topic_list.pt | topic_list.pt Page | page_view.pt | page_portlet.pt | page_summary.pt | page_list.pt Link | redirect.pt | link_portlet.pt | link_list.pt| link_list.pt you could register them like this: and you could use them like this: .. is that something along the lines you had in mind? are you planning on turning that into a plip? 3.1 material? certainly, the Zope CA seems to lend itself for expressing such scenarios (i.e. adapting a content object to a certain teaser type/ teaser interface, which then gets picked up by certain viewlet/portlet managers etc.) I think this is too much of a change for 3.x. However it is a direction that I think is worth investigating for 4.0. I'm not sure if I will have time to work on it though. I'm very much in favor of this approach but I agree that this is not for the Plone 3 series. Furthermore, I'm not sure that the underlying infrastructure should be dealt with in Plone. There could be interest to support this at the CMF level even (by enhancing the types tool maybe? providing a registry for tile types? just thinking out loud ...) Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIPs for 3.1
Previously Tom Lazar wrote: > On Dec 9, 2007, at 1:45 PM, Wichert Akkerman wrote: > >Previously Martin Aspeli wrote: > >>... there's another kind of portlet which we can provide (ship with > >>or > >>not, up to you guys) - a "referenced content portlet". Here, you > >>search > >>(using an UberSelectionWidget) for a Page that's then rendered as > >>content. We can provide multiple renderers depending on what was > >>selected (plone.portlets has some design provisions for this exact > >>use > >>case), so that there's a portlet-specific view for a Document that's > >>different to one for an Event, say. > > > >The collection portlet is just that. Once you go down that road I > >would > >prefer a more general approach where we introduce the concept of > >context-based rendering, or tile-based rendering as some people call > >it. > >Basically the idea is that you want to render a particular object in > >different kinds of places/sizes: portlets, collage slots, main page > >body, reference, etc. This is something that I requested more and more > >often and it makes sense to try and come up with a proper > >infrastructure > >for handling it. > > that sounds interesting and also would cover some use cases that > clients of mine have floating around. i like the term 'tile based > rendering'. is there some (semi-formal) concept behind that term? with > me it conjures up the idea of being a whole lot more flexible in how > site managers (i.e. not developers!) can structure and re-use content. > something like 'big' websites such as ny times, spiegel.de etc. use, > where e.g. an article can have two, three different kind of teasers > that are rendered in different sizes in different contexts etc. I'm only aware of the term being used in 3D rendering context: the idea is to break up a scene into tiles, determine some qualities of those (what part is visible, lightning, etc.) and then render the tiles. There are simularities: our pages consist of many different elements (portlets, content objects, search results, breadcrumbs, etc.) that are rendered in different types of UI elements (portlets, viewlets, folder/search result list items, main view). At the moment we have no structured way to approach this, which means that we are reinventing wheels in several places. For example we have view templates for collections in CMFPlone (the main topic view), in the collection portlet, in Collage, in the folder_listing template, in the search result template and probably a bunch of others. Instead I envision a system where we work with a set of tile-types and register views per content type per tile type. That would allow you to do things like 'give me a rendering of object X for a portlet-style tile' or 'objects of type Y should use this template when rendered in a search result'. If you draw this up you basically get a matrix of views with a content-type axis and a tile-type axes. Something like: | main content | portlet | search result | folderlisting ---+---+---+-+ Topic | topic_view.pt | topic_portlet.pt | topic_list.pt | topic_list.pt Page | page_view.pt | page_portlet.pt | page_summary.pt | page_list.pt Link | redirect.pt | link_portlet.pt | link_list.pt| link_list.pt you could register them like this: and you could use them like this: .. > is that something along the lines you had in mind? are you planning on > turning that into a plip? 3.1 material? certainly, the Zope CA seems > to lend itself for expressing such scenarios (i.e. adapting a content > object to a certain teaser type/ teaser interface, which then gets > picked up by certain viewlet/portlet managers etc.) I think this is too much of a change for 3.x. However it is a direction that I think is worth investigating for 4.0. I'm not sure if I will have time to work on it though. > finally, i think we should tread carefully here, though, as there have > already been numerous and vociferous complaints regarding how > complicated the porlet infrastructure has become. any design should > not increase the complexity for the existing use cases. I suspect this will simplify a lot of things by providing a consistent method of managing how things should be rendered. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIPs for 3.1
On Dec 9, 2007, at 1:45 PM, Wichert Akkerman wrote: Previously Martin Aspeli wrote: ... there's another kind of portlet which we can provide (ship with or not, up to you guys) - a "referenced content portlet". Here, you search (using an UberSelectionWidget) for a Page that's then rendered as content. We can provide multiple renderers depending on what was selected (plone.portlets has some design provisions for this exact use case), so that there's a portlet-specific view for a Document that's different to one for an Event, say. The collection portlet is just that. Once you go down that road I would prefer a more general approach where we introduce the concept of context-based rendering, or tile-based rendering as some people call it. Basically the idea is that you want to render a particular object in different kinds of places/sizes: portlets, collage slots, main page body, reference, etc. This is something that I requested more and more often and it makes sense to try and come up with a proper infrastructure for handling it. that sounds interesting and also would cover some use cases that clients of mine have floating around. i like the term 'tile based rendering'. is there some (semi-formal) concept behind that term? with me it conjures up the idea of being a whole lot more flexible in how site managers (i.e. not developers!) can structure and re-use content. something like 'big' websites such as ny times, spiegel.de etc. use, where e.g. an article can have two, three different kind of teasers that are rendered in different sizes in different contexts etc. is that something along the lines you had in mind? are you planning on turning that into a plip? 3.1 material? certainly, the Zope CA seems to lend itself for expressing such scenarios (i.e. adapting a content object to a certain teaser type/ teaser interface, which then gets picked up by certain viewlet/portlet managers etc.) finally, i think we should tread carefully here, though, as there have already been numerous and vociferous complaints regarding how complicated the porlet infrastructure has become. any design should not increase the complexity for the existing use cases. just my $0.02, cheers, tom Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIPs for 3.1
Previously Tom Lazar wrote: > On 08.12.2007, at 16:58, Martin Aspeli wrote: > > >We already have an RSS portlet in 3.0. Jon's talking about making it > >more powerful. > > ah, i hadn't realized that there was one already, my bad ;) We do have one, it just does not work for anonymous users. I fixed that in svn but there was no new plone.app.portlets release for 3.0.4. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIPs for 3.1
Previously Martin Aspeli wrote: > ... there's another kind of portlet which we can provide (ship with or > not, up to you guys) - a "referenced content portlet". Here, you search > (using an UberSelectionWidget) for a Page that's then rendered as > content. We can provide multiple renderers depending on what was > selected (plone.portlets has some design provisions for this exact use > case), so that there's a portlet-specific view for a Document that's > different to one for an Event, say. The collection portlet is just that. Once you go down that road I would prefer a more general approach where we introduce the concept of context-based rendering, or tile-based rendering as some people call it. Basically the idea is that you want to render a particular object in different kinds of places/sizes: portlets, collage slots, main page body, reference, etc. This is something that I requested more and more often and it makes sense to try and come up with a proper infrastructure for handling it. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIPs for 3.1
On 08.12.2007, at 19:38, Reinout van Rees wrote: Martin Aspeli wrote: i'm also not sure how to treat static portlets conceptually. i.e. as pages (that just 'happen to be displayed in a column') or as non- content. this raises further questions, i.e. how to treat their content when searching a site? The way plone.portlet.static works (i.e. what I'd advocate for 3.1) is that they have nothing to do with content at all. They are just portlets that when edited give you a Kupu area to enter text. That text is rendered inside the portlet column. (/me isn't framework, so just a quick chip-in) The static text portlet is great for adding buttons and what have you to the sidebar. See http://vanrees.org : linked-in button, hacker's diet. So: no content, just "stuff". yes, i agree. the usecase i had in mind can be satisfied with content reference portlets in which case their content doesn't need to be indexed, either, since their targets already are. cheers, tom Reinout -- Reinout van Rees - Programmer at http://zestsoftware.nl/ http://vanrees.org/weblog/ reinout @ vanrees.org "Information overload isn't the problem. If it was, you'd walk into a library and die." (David Allen) ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIPs for 3.1
On 08.12.2007, at 16:58, Martin Aspeli wrote: We already have an RSS portlet in 3.0. Jon's talking about making it more powerful. ah, i hadn't realized that there was one already, my bad ;) i'm also not sure how to treat static portlets conceptually. i.e. as pages (that just 'happen to be displayed in a column') or as non- content. this raises further questions, i.e. how to treat their content when searching a site? [snip] However any suggestions here from my fellow board members? ... there's another kind of portlet which we can provide (ship with or not, up to you guys) - a "referenced content portlet". Here, you search (using an UberSelectionWidget) for a Page that's then rendered as content. We can provide multiple renderers depending on what was selected (plone.portlets has some design provisions for this exact use case), so that there's a portlet-specific view for a Document that's different to one for an Event, say. I'd argue there are use cases for both this and the more simple "static text" portlet. In my experience (and intuitively) the simple portlet is more useful and conceptually easier to understand. Thus, I think the "reference" portlet may be a little more appropriate as a third party add-on. i think that the 'referenced content portlet' that you suggest makes the problem disappear. for most usecases the static portlet in its current form (i.e. non-content, non-searchable) is a simple solution that 'just works' (all is missing is the rich text editor which is being addressed in plip 200, anyway). all other objections/use cases would then be satisfied with the referenced content portlet. nice ;) and +1 for including that portlet, as well. I will create proper bundles for these if they're accepted in principle - that's the point of this round of review, no? yes, i kind of got ahead of myself here. at any rate, i definitely didn't mean to criticize the lack of a bundle! If you want to check it out, I'm using the 3.0 branch of ploneout and just doing an svn switch in src/plone.app.form. of course... i'll keep that in mind... Alternatively, you can create a standard Plone 3 buildout using plone.recipe.plone for Plone 3, set up plone.app.form as a develop egg, and override it like so: [buildout] ... develop = src/plone.app.form [plone] recipe=plone.recipe.plone eggs = plone.app.form (note lack of hardcoded version spec on last line) ah, i hadn't tried adding an eggs directive to the plone section... this actually works in so far, that it now properly picks up the branch of plone.app.form, however, it now generates a config error when trying to include the test_XXX views. but since that's not really the point of the exercise right now, i'll leave it at that for now. 2. http://plone.org/products/plone/roadmap/200 - Kupu formlib widget We need a Kupu/WYSIWYG widget for formlib-base forms. I'd like to thise this in portlets as well as formlib-based content types. The implementation here is largely complete. +1 on the idea, especially including portlets. it would be nice to be able to configure what features/buttons are included when rendering kupu as often it's really overkill and increases pageweight. Hiding them with CSS is the easiest but doesn't help pageweight of course. IMHO, it works OK just with the standard/site-wide configuration. I'll try to see what options we have for making widget specific settings, but it may be more trouble than it's worth. +1 on the 'may be more trouble than it's worth'. certainly not a showstopper, more of a 'nice to have'. http://plone.org/products/plone/roadmap/201 - Improved UberSelectionWidget This is about AJAX-enabling the UberSelectionWidget. Andreas and Florian and I have started this work already - it just needs a bit more JavaScript love. Again, I'd like to use this widget in a few more portlets, content rules and formlib-based types. +1 this, too, sounds very cool and desirable. i'm especially keen on the 'quicksilver like' functionality. i'm probably hoping for too much, though, when imagining myself typing 'fbr' to match 'foobar', since i assume that would require a completely new kind of index, no? The widget just uses an underlying Source. The SearchableTextSource uses a SearchableText catalog query. Other sources uses e.g. the PAS search interfaces. This PLIP is about the widget itself, which is independent of the vocabulary/source or the storage. i figured as much, didn't stop me from dreaming out loud, though ;) 3. http://plone.org/products/plone/roadmap/202 - KSS inline editing and validation for formlib forms +1 on the design goal. i really missed this feature on a recent project ;) in the demo template, where is the kssattr namespace defined, which is used in i.e. kssattr:fieldname="title". is that something new from this plip or a general convention? It's a KSS featur
Re: [Framework-Team] Re: PLIPs for 3.1
Previously Andreas Zeidler wrote: > On Dec 4, 2007, at 2:07 PM, Raphael Ritz wrote: > >Andreas Zeidler wrote: > >>On Dec 4, 2007, at 12:35 PM, Tom Lazar wrote: > >>>i'll take a look at the plips and check out their bundles > >>>(including wiggy's #195) during the weekend and will report by > >>>sunday evenening. > >> > >>fair enough, but let's make deciding on the acceptance of PLIPs a > >>higher priority for the time being, shall we? i mean, reading and > >>thinking about them a bit should take as long as doing a review or > >>even playing with a bundle, and imho people want to know asap if > >>their PLIPs have a chance of making in into 3.1. > > > >I hope I can set aside some time tomorrow. > > btw, i didn't mean to say things have to happen in a certain time > frame or something. of course we all have our priorities and that's > perfectly okay. i merely suggested we should try to decide on PLIP > acceptance as quickly as we _can_... > > >After all, Martin submitted not just one thing but a whole list ;-) > > yeah, just what one would expect... :) I have another couple in the pipeline as well :) Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIPs for 3.1
On Dec 4, 2007, at 2:07 PM, Raphael Ritz wrote: Andreas Zeidler wrote: On Dec 4, 2007, at 12:35 PM, Tom Lazar wrote: i'll take a look at the plips and check out their bundles (including wiggy's #195) during the weekend and will report by sunday evenening. fair enough, but let's make deciding on the acceptance of PLIPs a higher priority for the time being, shall we? i mean, reading and thinking about them a bit should take as long as doing a review or even playing with a bundle, and imho people want to know asap if their PLIPs have a chance of making in into 3.1. I hope I can set aside some time tomorrow. btw, i didn't mean to say things have to happen in a certain time frame or something. of course we all have our priorities and that's perfectly okay. i merely suggested we should try to decide on PLIP acceptance as quickly as we _can_... After all, Martin submitted not just one thing but a whole list ;-) yeah, just what one would expect... :) andi -- zeidler it consulting - http://zitc.de/ - [EMAIL PROTECTED] friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/ plone 3.0.3 released! -- http://plone.org/products/plone PGP.sig Description: This is a digitally signed message part ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIPs for 3.1
Andreas Zeidler wrote: On Dec 4, 2007, at 12:35 PM, Tom Lazar wrote: i'll take a look at the plips and check out their bundles (including wiggy's #195) during the weekend and will report by sunday evenening. fair enough, but let's make deciding on the acceptance of PLIPs a higher priority for the time being, shall we? i mean, reading and thinking about them a bit should take as long as doing a review or even playing with a bundle, and imho people want to know asap if their PLIPs have a chance of making in into 3.1. I hope I can set aside some time tomorrow. After all, Martin submitted not just one thing but a whole list ;-) Raphael cheers, andi -- zeidler it consulting - http://zitc.de/ - [EMAIL PROTECTED] friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/ plone 3.0.3 released! -- http://plone.org/products/plone ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIPs for 3.1
On Dec 4, 2007, at 12:35 PM, Tom Lazar wrote: i'll take a look at the plips and check out their bundles (including wiggy's #195) during the weekend and will report by sunday evenening. fair enough, but let's make deciding on the acceptance of PLIPs a higher priority for the time being, shall we? i mean, reading and thinking about them a bit should take as long as doing a review or even playing with a bundle, and imho people want to know asap if their PLIPs have a chance of making in into 3.1. cheers, andi -- zeidler it consulting - http://zitc.de/ - [EMAIL PROTECTED] friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/ plone 3.0.3 released! -- http://plone.org/products/plone PGP.sig Description: This is a digitally signed message part ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIPs for 3.1
i'll take a look at the plips and check out their bundles (including wiggy's #195) during the weekend and will report by sunday evenening. cheers, tom On Dec 3, 2007, at 11:20 AM, Andreas Zeidler wrote: On Dec 2, 2007, at 6:19 PM, Martin Aspeli wrote: Hi team, hi martin, I'm submitting the following PLIPs for Plone 3.1. thanks for submitting these — unfortunately i won't have time to read them today, but i'll catch up and comment some time later this week. having that said, could we, i.e. the team, try to keep casting votes relatively soon after new submissions to avoid blocking things and/or creating a backlog for ourselves? in this particular case i'd suggest the end of the week if that's okay with everyone? cheers, andi -- zeidler it consulting - http://zitc.de/ - [EMAIL PROTECTED] friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/ plone 3.0.3 released! -- http://plone.org/products/plone ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIPs for 3.1
On Dec 3, 2007 11:20 AM, Andreas Zeidler <[EMAIL PROTECTED]> wrote: > in this particular case i'd suggest > the end of the week if that's okay with everyone? I won't make that, this week is already too full. -- Martijn Pieters ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
