[Framework-Team] [PLIP 149 Markup] - Review notes

Tom Lazar lists at tomster.org
Sun Sep 24 12:22:43 UTC 2006


On Sep 24, 2006, at 2:03 PM, Martin Aspeli wrote:

> I would deactivate them by default *anyway*, but also grey out the  
> selection in the control panel with a link to download the module  
> if people want it.
>
> If you use a view, doing those kinds of checks is very simple.


> Whit says it should be orthogonal.

yes, i read his email, too - however, i don't understand the meaning  
of the word 'orthogonal' in this case :-(

>>> o Looking at http://dev.plone.org/archetypes/changeset/6957, it's  
>>> not clear to me why we need to set the field's allowable content  
>>> types from the site property that holds the default values as  
>>> managed by the configlet.
>> that's because every other piece of code dealing with this  
>> information expects it to reside there (i.e. as a property of the  
>> schema). this plip is not so much about changing the lookup of  
>> this value but about enabling the user to set a default for it via  
>> a control panel. besides, this value is only relevant upon  
>> creation of an instance, so on a conceptual level, subsequent  
>> changes of the site-wide default wouldn't affect exsting instances  
>> anyway.
>
> Then I don't understand still.
rightly so.. this point still needs clarification -- i'm not sure  
what's going on myself, atm after you've raised this point...
>
>  - If it's stored there, how does it change when the user makes a  
> change of selection? Does that edit the variable on the field, in  
> the module as well?

my preliminary opinion is that the failing tests produced by removing  
the code that sets the property show, that some parts still _do_ rely  
on the schema for allowable content types -- which is bad! because,  
as you rightly point out, these values are never updated after a  
content type is instantiated. and apparently we're breaking  
something, if we remove that value...

at any rate, this will be the next issue i'll look into, as there  
seems to be a real bug lurking here...

i'll report on that, as soon as i had time to look at it properly...

>>> o The template for the configlet does things like allowable_types  
>>> python:modules 
>>> ['Products.Archetypes.mimetype_utils'].getAllowableContentTypes 
>>> (here); It really could benefit from using a view!
>> hanno (who showed me the above syntax btw ;-) said, i should wait  
>> until he (or somebody) comes up with a more generic z3-solution  
>> for control panels. i think it would a) exceed the scope of this  
>> plip to do so now and b) i wouldn't want to add just one lonely z3- 
>> based control panel w/o addressing the control panel issue as a  
>> whole.
>
> Put it in a view anyway.

okay. especially, since it's a) more fun to write ;-) and b) will  
make the handling of not-installed formats (as mentioned above) much  
easier.

> Also, surely any solution we do arrive at will be based on views,  
> so whilst it may mean adding something more to your view, the code  
> you write there will almost certainly be re-usable.

true... i mean it's one of the main points of using views in the  
first place, duh! ;-)

>  I'd say stick with properties for now unless people radically  
> disagree.

that was my stance from the start ;-)

so, in summary, my next steps will be:

  * look into and fix the issue with allowable_content_types in the  
schema
  * rewrite the control panel as a view
  * present non-installed formats 'greyed out' with links to their  
download

cheers,

tom

--
Tom Lazar
http://tomster.org






More information about the Framework-Team mailing list