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
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
o It's unclear to me whether/how this corresponds to the work on
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
(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
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
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
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
Framework-Team mailing list