[Framework-Team] Re: PLIPs for 3.1

[Tom Lazar]

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 feature. You can do class="kssattr-foo-bar" or you can do  
> kssattr:foo="bar". Note that this will break validators and is  
> incompatible with the XHTML transitional doctype we use, so we may  
> need to switch back to the class syntax. That's a trivial  
> implementation detail, though.

ah, ok. i didn't realize that the colon-based notation had been  
offered as an alternative spelling.

FWIW: +1 for switching back to class syntax, as long as the 'pseudo- 
namespace' pattern breaks validation. but that's not the topic here.

>> it seems a bit redundant, since we  also have tal:content="context/ 
>> Title". then again, it is of course,  nice to be able to 're-wire'  
>> fields straight in a template. but  perhaps, in a grok/RoR spirit  
>> we could come up with some kind of  default mechanism that maps the  
>> kss fieldname with the context.
>
> I don't think so. KSS needs to know what attribute to look for in  
> the form, and which form to use, and where to output the "saved"  
> value after inline editing completes. That needs to be retained in  
> the rendered page so that the client-side KSS runtime can grab a  
> hold of it. tal:content is run at template rendering time and will  
> not be available to KSS.

the difference between template rendering time and JS runtime should  
be sufficiently legitimize the existence of these two different  
attributes. thanks for explaining, consider my point moot.
>
>> the rather clumsy class attribute is generated at runtime via KSS,  
>> i  assume, so there's probably no need to make that a bit more  
>> 'human  friendly'.
>
> Not sure what you mean here.

never mind ;)

>>> //plone.org/products/plone/roadmap/203 - Manage portlet   
>>> assignments with GenericSetup
>>>
>>> This is about making it easier to set up portlet assignments in  
>>> GS  profiles. I have a design for this, but no code yet - I plan  
>>> to work  on it over Christmas.
>> +1 on the design. this is pretty much exactly what i would like to  
>> be  able to do ;-)
>
> Cool.
>
>>> 5. http://plone.org/products/plone/roadmap/204 - Manage content   
>>> rules using GenericSetup
>>>
>>> This is quite similar to 203. Again, no code, but I know how to  
>>> do  it and hope to get it done for January.
>> can't really comment on whether the suggested syntax is entirely   
>> logical and complete as i'm not familiar with content rules but i  
>> must  say that it looks very clean and straightforward. so +1, too.
>
> The plan is to try and make the content rule and portlet syntaxes be  
> as similar as possible (they have commonalities in internal design  
> for obvious reasons), and to replicate the way <property /> GS  
> syntax works right now as closely as is feasible.

+1

cheers,

tom