[Framework-Team] Re: PLIPs for 3.1

[Martin Aspeli]

Hi Tom,


> 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).

Right. That was my point. There's room for both, but the default should 
be the "simple" one.

> all other objections/use cases would then be satisfied with the  
> referenced content portlet. nice ;)
> 
> and +1 for including that portlet, as well.

It'd have no integration risk, so if it's ready, it can ship (I have 
most of the code already, just need to untangle it from a more general 
package). If not, it'll go in the Cheese Shop.

>> [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...

It exists explicitly for the use cases where you need to override the 
dependencies that plone.recipe.plone pins.

>> 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.

It's always been there.

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

Right. There may be things we can do to make this pass validation, but 
that's a different discussion.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book