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
