hi martin, et. al.

On Sep 24, 2006, at 1:25 AM, Martin Aspeli wrote:

o Markup and Textile support requires additional Python modules to be installed. They should probably not be available for selection unless these modules are installed.

that's a matter of specification, i guess. here, like with most decisions (i.e. using portal properties, not using z3-views for the control panel) i simply emulated the status quo in order to keep the scope of the plip limited.

regarding texile and markup support i.e. not only are they available, even if they're not installed -- their tests in PortalTransforms fail for the same reason! but the same is true for all formats that rely on external module such as ReSt etc...

how to deal with this? first of all, we need to treat all transformations/mimetypes equally, i.e. a fix here should also address existing transforms (and their tests).

simply deactivating types that aren't supported locally would be a bad idea IMHO. but how about deactivating those (including python- source, see blow) _by default_ but still presenting them in the control panel together with a message, that this format is principially available but lacks the corresponding python module (and why not supply a link to a download or to the project page? or even bundle those packages with PortalTransforms and offer them as download from the plone instance itself (or bundle them and point to the appropriate directory on the filesystem)

any ideas on this?

o In fact, things like python source etc. should be disabled by default. This would be a fairly simple matter of adding the appropriate property initialisation, however.

yes, indeed. and i agree about the python source; also, there are two mimetypes for restructured text (rest and restructured - what gives?)

o The configlet is called 'Type Settings' which is too generic. It also has some strange language and references AT details like TextField. All easy to fix, of course.

that happened after consulting with hanno at the st.-augustin sprint. the reasoning being, that there will be more settings regarding 'types' in general in the future, and that they will have their place in this panel, as well -- hence the generic terms. the settings for this plip should have already been visually wrapped into their own field-set, but i just checked and realized that i haven't actually done that yet.

in regard to the wording i'm very keen on constructive criticism here -- in fact i spent already way too much time on wording those few snippets... i tried to keep any technical terms (AT-related, especially) out (you are right about the mentioning of TextField -- that one has slipped through). Another aspect is the internal terminology of 'content types' when, in fact, we're actually dealing with mimetypes of text fields. talking about 'content types' might make sense within AT fields but on a more global level, we usually reserve that term for AT content types (i.e. Image, Event, Page etc.). This is why I've chosen the more descriptive term 'Format'.

as mentioned before, i'm keen on input regarding this!

o There doesn't appear to be a way to manage markups per-content- type, which would be useful.

well, that's kind of what the schema-based definition is for, which takes precedence, as you mentioned.

however, i do see the value of being able to make such a decision (as site admin) _without_ having to delve into your schemas -- especially when dealing with standard content types which you shouldn't touch directly, anyway.

i'm perfectly willing to implement this feature, though again it's more a matter of specification: how should we present this choice to the user? (see below)

I still think this is valuable even if that isn't possible, though.

sure, but i've gone through all this effort to tackle the various stumble stones so far, i ain't stopping now ;-) especially, since pretty much all of the 'heavy stuff' has been moved out of the way by now.

o It's unclear to me whether/how this corresponds to the work on Wicked


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.

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.

I think that this could benefit from some code cleanup and fine tuning, but that it's generally quite solid.

that's pretty much the best-case-scenario of a verdict that i was hoping for ;-)

Using utilities to manage the actual available transforms and using a local utility rather than site_properties to store the default and disabled transforms would seem to be more modern patterns.

having had some more z3-exposure since the archipelago sprint i'm perfectly willing to implement this change -- but i would need some more guidance on how to set this up. also, isn't this what annotations are for? i.e. annotations to the site object? in that case we would need to agree on some naming conventions regarding the keys with which we would store this information.

However, this PLIP was never about radically refactoring PortalTransforms, and the changes it introduces are fairly minor. I don't think you could reasonably make transforms be utilities the way PortalTransforms works today, nor do we have any consideration yet of transform support in non-AT objects (unless they explicitly choose to invoke portal_transform, in which case they could also refer to the properties used in this bundle for their available and default MIME types).

at this point i refuse to do any reworking of PortalTransforms -- too big, too important ;-)

If/when a more general refactoring of PortalTransforms happens, refactoring the work done by this PLIP to take advantage of it should be simple.


The one missing feature is the ability to manage available MIME types per-content-type. This would more likely require something like a local utility to hold the settings and a custom UI to manage it.

all i can offer at this point, is to give it some thought. i'm not sure how the ui of this should work, yet. how to determine eligible candidates for the content types list (all registered types that have a TextField w/o a hardcoded default content type?)

perhaps, we could have a checkbox 'define default globally', which, if switched off, would reveal a list of eligible content types alongside their own select field (each value of which defaulting to the previous site-wide default)

i presume, the selection of _allowable_ types would remain globally? i think, offering individual 'allowable types' for each content types would be overkill, no?

Another possible improvement may be to allow a personal selection of preferred markup. Again, not very hard, but also not criminal to delay.

i feel the other points raised so far are more important than this (admittedly neat) feature. i'd consider it only _after_ having properly addressed those other issue and would rather let this slip into 3.5...

in closing, i have to add that i actually find it quite fascinating how many decisions and aspects must be addressed for even such a minor feature. for one, it certainly makes me appreciate all previous enhancements of plone much more ;-)

secondly, i'm absolutely committed to making this plip 100% right, so bring it on!



Framework-Team mailing list

Tom Lazar

Framework-Team mailing list

Reply via email to