Re: [Framework-Team] [PLIP 149 Markup] - Review notes
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 +1 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
Re: [Framework-Team] [PLIP 149 Markup] - Review notes
On Sep 24, 2006, at 1:41 PM, Tom Lazar wrote: On Sep 24, 2006, at 1:25 AM, Martin Aspeli wrote: 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. duh! i didn't read your comment properly the first time. indeed, i think you're right: i can't think of a good reason why to store the 'allowable content types' in the schema any longer, since one of the main goals of this plip is to remove the dependency on this field in the first place ;-) i.e. *theoretically* all relevant pieces of code already consult the site-wide list instead of the property. however, after i've removed this bit, i get failing tests, see sample output below. right now i haven't got time to look at that more closely, so will just leave that bit in for now. cheers, tom Error in test testRendering (Products.Archetypes.tests.test_cmfessentials.TestPermissions) Traceback (most recent call last): File /opt/zope/Zope210-branch/lib/python/Testing/ZopeTestCase/ profiler.py, line 98, in __call__ testMethod() File test_cmfessentials.py, line 73, in testRendering File /Data/opt/zope/instances/plip149/zope/Products/Archetypes/ TemplateMixin.py, line 68, in __call__ File /Data/opt/zope/instances/plip149/zope/Products/ CMFFormController/FSControllerPageTemplate.py, line 96, in __call__ File /Data/opt/zope/instances/plip149/zope/Products/ CMFFormController/BaseControllerPageTemplate.py, line 42, in _call File /opt/zope/Zope210-branch/lib/python/Shared/DC/Scripts/ Bindings.py, line 313, in __call__ return self._bindAndExec(args, kw, None) File /opt/zope/Zope210-branch/lib/python/Shared/DC/Scripts/ Bindings.py, line 350, in _bindAndExec return self._exec(bound_data, args, kw) File /Data/opt/zope/instances/plip149/zope/Products/CMFCore/ FSPageTemplate.py, line 195, in _exec File /Data/opt/zope/instances/plip149/zope/Products/CMFCore/ FSPageTemplate.py, line 134, in pt_render File /opt/zope/Zope210-branch/lib/python/Products/PageTemplates/ PageTemplate.py, line 89, in pt_render return super(PageTemplate, self).pt_render(c, source=source) File /opt/zope/Zope210-branch/lib/python/zope/pagetemplate/ pagetemplate.py, line 117, in pt_render strictinsert=0, sourceAnnotations=sourceAnnotations)() File /opt/zope/Zope210-branch/lib/python/zope/tal/ talinterpreter.py, line 271, in __call__ self.interpret(self.program) File /opt/zope/Zope210-branch/lib/python/zope/tal/ talinterpreter.py, line 346, in interpret handlers[opcode](self, args) File /opt/zope/Zope210-branch/lib/python/zope/tal/ talinterpreter.py, line 861, in do_defineMacro self.interpret(macro) File /opt/zope/Zope210-branch/lib/python/zope/tal/ talinterpreter.py, line 346, in interpret handlers[opcode](self, args) File /opt/zope/Zope210-branch/lib/python/zope/tal/ talinterpreter.py, line 536, in do_optTag_tal self.do_optTag(stuff) File /opt/zope/Zope210-branch/lib/python/zope/tal/ talinterpreter.py, line 521, in do_optTag return self.no_tag(start, program) File /opt/zope/Zope210-branch/lib/python/zope/tal/ talinterpreter.py, line 516, in no_tag self.interpret(program) File /opt/zope/Zope210-branch/lib/python/zope/tal/ talinterpreter.py, line 346, in interpret handlers[opcode](self, args) File /opt/zope/Zope210-branch/lib/python/zope/tal/ talinterpreter.py, line 891, in do_useMacro self.interpret(macro) File /opt/zope/Zope210-branch/lib/python/zope/tal/ talinterpreter.py, line 346, in interpret handlers[opcode](self, args) File /opt/zope/Zope210-branch/lib/python/zope/tal/ talinterpreter.py, line 536, in do_optTag_tal self.do_optTag(stuff) File /opt/zope/Zope210-branch/lib/python/zope/tal/ talinterpreter.py, line 521, in do_optTag return self.no_tag(start, program) File /opt/zope/Zope210-branch/lib/python/zope/tal/ talinterpreter.py, line 516, in no_tag self.interpret(program) File /opt/zope/Zope210-branch/lib/python/zope/tal/ talinterpreter.py, line 346, in interpret handlers[opcode](self, args) File /opt/zope/Zope210-branch/lib/python/zope/tal/ talinterpreter.py, line 961, in do_defineSlot self.interpret(block) File /opt/zope/Zope210-branch/lib/python/zope/tal/ talinterpreter.py, line 346, in interpret handlers[opcode](self, args) File
Re: [Framework-Team] [PLIP 149 Markup] - Review notes
Hi Tom, 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) 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. 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. Types is still too generic, IMHO. We can evaluate that later though in light of what the control panel for 3.0 ends up looking like. 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! That's cool - we can revise later. 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. Yes, I suppose, but there's no UI to let people manage it per-type and to let types be aware of newly installed markups this way. 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. Exactly. 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) My feeling is that it can wait, the use case that's there now is the main one. 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. Good. o It's unclear to me whether/how this corresponds to the work on Wicked +1 Whit says it should be orthogonal. 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
[Framework-Team] [PLIP 149 Markup] - Review notes
Hi guys, Below is the review for PLIP 149 - Improved Markup Support http://plone.org/products/plone/roadmap/149 What is it? --- - A way of registering additional transformations to support different text transforms more easily, without requiring the content type (i.e. the AT TextField and RichWidget) to be aware of that markup type up-front. - A control panel to support this Who did it? --- Tom Lazar ([EMAIL PROTECTED]) did the majority of this work. How do I check it out? -- I ran the bundle on Zope 2.10 svn: svn co svn.plone.org/svn/plone/review/plip-149-markup-support/ After installing this, you will be able to select additional markups in the MIME-type selection drop-down when editing a Page or other content object. You will also see a new configlet in the control panel for selecting the default markup type and selecting the additional types that are available. There are branches of CMFPlone (for the configlet), PortalTransforms (for the new transforms), Archetypes (to support non-hardcoded lists of available input MIME types) and ATContentTypes (to let ATCT's types elect to use the dynamic transforms). Implementation -- o A method listAvailableTextInputs() on the portal_transform tool returns all transforms that can transform from text/ to HTML. o A method getAllowedContentTypes() on Field in AT is used by the widget macro to determine which content types may be selected. If the field has set allowed_content_types explicitly, this always wins. However, if it's not set (as it is now not on the ATCT branch), the method getAllowedContentTypes() in Products.Archetypes.utils is called instead. This queries the allowable types (as per listAvailableTextInputs()) and then removes any blacklisted types as managed by the configlet. Like many of our configlets, it gives the illusion of managing a whitelist in the UI, whilst the implementation is a blacklist. This means that when a new product is installed providing a new markup, it doesn't need to be explicitly activated. Concerns - 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. 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. 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. o There doesn't appear to be a way to manage markups per-content-type, which would be useful. I still think this is valuable even if that isn't possible, though. 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. 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! Recommendation and caveats --- I think that this could benefit from some code cleanup and fine tuning, but that it's generally quite solid. Having supported input MIME types hardcoded in every RichWidget-using field by default is really an anti-pattern, and this just decouples that (note that fields that *do* explicitly state their MIME types will not be affected by this - to get the new behaviour, you have to *not* set allowable_content_types on the field). This is obviously very AT specific, and there is no use of any Z3 tech here. Using a view for the configlet would be a trivial, but useful improvement. 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. 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). 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. It probably
Re: [Framework-Team] [PLIP 149 Markup] - Review notes
o It's unclear to me whether/how this corresponds to the work on Wicked should be orthogonal to wicked (just as stx, reST, html etc is). wicked is not format sensitive(another reason why it keeps it's syntactical scope limited). speaking of wicked, got it all running with the plone-3.0 bundle this afternoon(and fixed a blocking bug for wicked's 1.0 release). currently doing a bit of cleanup and will update the bundle. sorry not to have this done earlier due to work constraints. -w begin:vcard fn:D. Whitfield Morriss n:Morriss;D. Whitfield email;internet:[EMAIL PROTECTED] tel;home:615 292-9142 tel;cell:415 710-8975 x-mozilla-html:FALSE version:2.1 end:vcard ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
