While working on a dexterity based project I needed one of my content types to support collective.quickupload by marking it with the IQuickUploadCapable interface.
What I'm currently doing is adding an 'implements' to my configure.zcml file:
`<class class="plone.dexterity.content.Container">
<implements interface="collective.quickupload.browser.interfaces.IQuickUploadCapable" />
</class>`
Since my content type is a Container this works however my first inclination was to use a grok style approach instead of declaring it in ZCML. What's the grok/dexterity way to tell my dexterity content type that it implements an additional interface, or should I stick to the current approach?
Also I tried adding the interface as a behaviour in my profiles/default/types/my.dexterity.content.xml file but this didn't work (I didn't really expect it to as behaviours serve a different purpose).
Sean's answer is good. The other way is to create a behaviour and apply that. You need to register the behaviour with:
<plone:behavior
title="Quickupload"
provides="collective.quickupload.browser.interfaces.IQuickUploadCapable"
/>
You can then add 'collective.quickupload.browser.interfaces.IQuickUploadCapable' to your list of behaviours in the FTI.
Your approach using is not good because it means all Container-based Dexterity types get the marker interface, not just your type.
Why not just subclass IQuickUploadCapable as a mixin after form.Schema in your type interface?
You can not use it as a behaviour because it doesn't claim to be used in that way.
As I read from pypi, is intended to be used in a portlet or in a viewlet.
To add it in a grok style you should:
from collective.quickupload.browser.interfaces import IQuickUploadCapable
from plone.directives import form
class IMyContent(form.schema):
grok.implements(IQuickUploadCapable)
And that's it!
Be sure that your content type allows files to be added inside it, so is both folderish and it allows files to be added (or it just doesn't restrict to any specific content type).
Related
I'm trying to register a custom content type, similar to this question on MSDN forums: I want to register a custom extension that is essentially an HTML file, e.g.:
[Export]
[DisplayName("My Custom Markup")]
[Name("mycustom")
[BaseDefinition("html")]
internal static ContentTypeDefinition MyCustomContentType;
[Export]
[FileExtension(".mycustom")]
[ContentType("mycustom")]
internal static FileExtensionToContentTypeDefinition MyCustomFileExtensionDefinition;
So by specifying BaseDefinition as html, I am able to get HTML highlighting in .mycustom files, unfortunately I get nothing else, in particular, the HTML intellisense. From the above link it seems that the only way to have Visual Studio recognize custom extensions as a specific editor type, but I'd have to hack the registry (or more specifically, provide this via the ProvideEditorExtension attribute, but it's only applicable on a VSPackage).
So my question is, basically, is there an alternative way to register a custom extension to an editor programmatically, but without creating a custom VSPackage for it? Other than hacking the registry, of course?
(I could be totally wrong with the approach, in which case your help is very much appreciated!)
The easiest way is to use the technique demoed here:
http://blogs.msdn.com/b/noahric/archive/2010/03/01/new-extension-css-is-less.aspx
This is effectively "hacking the registry" but in a supported way. You're simply wrapping the needed keys in a .pkgdef file (essentially a .reg file) that can be contained in an editor extension.
I created a content in my Plone 4.3 site (no grok here) with the very nice Dexterity through-the-web editor. Now I'd like to customize the default view for this content.
I've read Martn Aspelli's book but the problem is that through-the-web content does'nt have a specific interface (so I can't use it to create my specific view).
If you want to do this all through-the-web, then do the following:
Create a template for your view in the "custom" folder of
portal_skins (through the ZMI). You'll probably want to start with a
copy of something like the page template
(portal_skins/plone_content/document_view). Give it a name like
your_content_type_view. Test it by appending /your_content_type_view
to the URL for a sample object.
Edit the Factory Type Information (portal_types/your_content_type/Default
view method) to be your_content_type_view.
What you will have done is create a skin-level view for the type. This is different from the browser views that Martin is discussing, which do indeed require a class. The Dexterity development team is working on a way to provide TTW maintenance of browser views, but that's for a later version of Plone.
Meanwhile, if you later transfer your Dexterity content type to a Python add on, you'll be able to use your template, possibly unmodified for a browser view.
I've created a Dexterity product that includes container and non-container Dexterity content types. Having discovered collective.documentviewer (yay! thanks! huzzah!), I'd like to use its dvpdf-group-view, but that is registered in ZCML as being for Folders, and my Dexterity containers don't qualify. I've looked through the web interfaces available on my container type, added SiteRoot, and that enabled the view to be applied, but is also completely wrong.
I'm confident there's a right way to do this, and I'm pretty sure it's central to the whole adapter/interface mechanism, but I just can't find it in any of the books.
Anyone care to try an explanation? First, the line or two that would enable a Dexterity container to pretend it's also a Folder; second, how to change the default view of a single instance of a Dexterity type so that it presents a foreign component's view?
Thanks.
1. Register the view for dexterity containers too
The view is registered for the Archetypes folder interface (Products.CMFCore.interfaces._content.IFolderish), but your dexterity container does not provide this interface (but plone.dexterity.interfaces.IDexterityContainer).
The reason may be that the product and/or the view is not compatible with dexterity.
Anway, you can try it out yourself by registering the view also for the the IDexterityContainer interface by putting a little ZCML in the configure.zcml in your package (see also the Creating a package section of the Dexterity Developer Manual):
<configure
xmlns="http://namespaces.zope.org/zope"
xmlns:browser="http://namespaces.zope.org/browser">
<configure package="collective.documentviewer">
<browser:page
name="dvpdf-group-view"
for="plone.dexterity.interfaces.IDexterityContainer"
class=".views.GroupView"
template="templates/group-view.pt"
permission="zope2.View"
layer=".interfaces.ILayer" />
</configure>
</configure>
The <browser:page> is copied from the collective.documentviewer configure.zcml but I've changed the interface for= to the dexterity container interface, so that the view also works for dexterity containers.
The inner <configure package="collective.documentviewer"> tells the ZCML parser that the configuration should be applied as if the configure.zcml would be directly in collective.documentviewer - this allows you for example to use the original template (otherwise you would have to copy it or do some nasty things).
I did not test it myself: it may still be that the view needs an archetypes container and does not work with a dexterity container. It may also be that you have to register more components from the documentviewer for dexterity containers (maybe the menus? take a look at what is registered in the original configure.zcml.
If everything works well you should consider doing the changes in collective.documentviewer on github directly and make a pull-request to the author (be aware that dexterity is not plone-core yet). But first ask if and how you should do it :-)
2. Changing the default view
With plone it is possible to define multiple views for a specific type. The view can then be selected in the display menu per instance of this type. If you open up http://localhost:8080/Plone/portal_types/manage_main and click on your type, there is a field Available view methods, where you can add the view-name (dvpdf-group-view) on a seperate line.
After you create a new object of your type or visit an existing one, you have a "Display"-menu which should list the view. Select it and this object now has this view as default.
(If you want to make the view not selectable on other objects of this type you could just remove it from the type configuration so that it is not selectable anymore - the existing configuration of your object will stay).
I am working on a Plone add-on that requires a re-skinned alternate edit form for Dexterity content. I need to be able to display only part of the edit form in an AJAX overlay (using JQuery UI, not JQuery tools, so it seems more reasonable to do this server-side than to filter in JavaScript)**.
Documentation from Dexterity Developer's Guide seems to indicate I can have a custom template using macros. Something is missing from this section though -- maybe some critical context for folks not using grok to bind views, but perhaps something else. Creating a template-only view fails (cannot find names from view class, obviously), and attempting to bind a custom template in ZCML to either the stock view class or to a subclass of it both fail (the template is ignored in favor of the stock template).
My goals:
Have an edit for that is wrapped in a bare template that essentially just includes the content inside the #content div.
I do not want merely an unwrapped z3c.form rendering, I need a minimal template to wrap it too -- just not the stock Plone viewlet managers and furntiture.
What does not work:
from plone.dexterity.browser.edit import DefaultEditForm
from Products.Five.browser.pagetemplatefile import ViewPageTemplateFile
class MyEditForm(DefaultEditForm):
index = ViewPageTemplateFile('my_edit_template.pt')
The ZCML equivalent (defining the index with runtime magic) also does not work here.
How can I inject a custom template into an edit form?
** I am working on Solgema.fullcalendar compatibility with plone.app.event's Dexterity-based type. Solgema.fullcalendar uses jQuery UI for popups, not plone.app.jquerytools overlay helpers; for consistency, it makes sense to have this minimal view and not attempt to mimic the filter mechanism in JavaScript of normal Plone overlays.
z3c.form looks for the template as the template attribute, so you need to assign your custom template to the template attribute of your edit form subclass, rather than index (which is where the template ZCML attribute puts it).
from plone.dexterity.browser.edit import DefaultEditForm
from Products.Five.browser.pagetemplatefile import ViewPageTemplateFile
class MyEditForm(DefaultEditForm):
template = ViewPageTemplateFile('my_edit_template.pt')
I'm working on a Drupal site/theme. The CSS and PHP modifications are fairly easy; they just take a little time to learn and get working exactly how I want.
However, I'm having issues applying CSS styles to some elements because of what I think is a property function.
The code looks like <h2 property="dc:title" datatype="" class="node-title">.
What is a property function and what does it do or control within the page? Also how can I modify or remove it?
It's not a property function; it's an attribute that is used from RDFa, and that is added from the RDF module.
The easier way to remove those attributes is to disable the module, but I would not suggest doing it, as the purpose of that module is to enrich your content with metadata to let other applications better understand its relationships and attributes.
Alternatively, if the problem is just with that property, used for the nodes, then you can implement code similar to the following one:
function mymodule_preprocess_node(&$variables) {
if (isset($variables['title_attributes_array'])) {
$variables['title_attributes_array']['property'] = NULL;
}
}
The module should be executed after the RDF module, to allow its hook to be executed after the one implemented by the RDF module.
I have not seen any compatibility problem between the attributes added by the RDF module and the JavaScript code executed by Drupal core or third-party modules. It would probably be the case to investigate why you are having problems with the JavaScript code when those HTML attributes are added.
in your css file, put:
h2[property="dc:title"]{color:#FFFFFF;}
or if it is a link, you may need:
h2[property="dc:title"] a {color:#FFFFFF;}
From wikipedia, check out RDFa
RDFa (or Resource Description
Framework – in – attributes) is a W3C
Recommendation that adds a set of
attribute-level extensions to XHTML
for embedding rich metadata within Web
documents.
It is basically a way to add more metadata to XHTML docs for better semantics.