So I have GhostDoc Pro and auto documented a project. Great.
The results are, as it says in the C# documentation put it all together verbose compared to the code. Therefore I would like to use the include tag and a separate file for the documentation to make my classes less documentation heavy.
All the classes are auto documented, but the documentation goes into class include files, like this:
/// <include file='MyMathClass.xml' path='docs/members[#name="math"]/Math/*'/>
... some code ...
and another class
/// <include file='MyArtClass.xml' path='docs/members[#name="art"]/Art/*'/>
... some code ...
Is there a feature to do this, or am I going to have to move every documentation tag by hand? I would like every class to have its own include file.
The feature is coming but the current version of GhostDoc doesn't support the
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'd like to have Trac colorize my aspx files but I can't find a way to make it work. I can easily add a mime-type/extension mapping for most Pygments lexers, but the CSharpAspxLexer doesn't have an assigned mime type (see http://pygments.org/docs/lexers/#lexers-for-net-languages). I've tried a couple things but I don't see a way to connect the [mimeviewers] section to Pygments without a mime type. The CSharpLexer works automatically and looks great, but only for .cs files (as it should).
I'm using Mercurial as a repository so I can't set the mime type manually; that's not a good solution anyways. My Trac installation is in Windows. Any thoughts?
I just render it as XML, and the same for a number of other similar files for typical Windows .Net development. My mapping looks like this:
[mimeviewer]
mime_map = text/xml:aspx:ascx:master:resx:config:sitemap:wsdl:disco:map:asmx:mxml:csproj, ...
However, I think you can also enable aspx via the pygments_modes setting (and you need to remove it from the mime_map):
[mimeviewer]
pygments_modes = text/plain:aspx-cs:7
To my knowledge that won't handle ascx and other (very) close relatives of aspx, so I don't use the setting as I find it better to render all variants using the same lexer. And also, I think the XML lexer works really well.
I want to add a simple stylesheet to a plone 4 product. Therfore I added
<browser:resourceDirectory
name="groovecubes.portlet.gallery.css"
directory="css"
/>
to [product dir]/browser/configure.zcml, which should me enable to browse stylesheets in this folder with this syntax: ++resource++groovecubes.portlet.gallery.css/mycss.css. But it doesn't. Not even after a buildout.
Every declaration in [product dir]/profiles/default/cssregistry.xml are therefore not found. What am I missing? Is it the package name?
The packages main configure.zcml contains the line
<include package=".browser" />
which should execute browser/configure.zcml
But is does not. I pasted the packages configure.zcml and browser/configure.zcml
Update II:
It gets even weirder. When I modifiy the head of browser/configure.zcml the file is recognized as malformed when I try to start the instance. But when I modify the relevant entry, startup continues normal.
Update III:
I've tested various things now, but what I found out, is that any malformed tags in .zcml files is ignored by the SaxParser. In every product on my dev and productive instance (Plone 4.2 / Plone 4.1). Is that maybe a new feature, I may have missed?
Update IV:
Solved: I removed the interface declaration from browser/configure.zcml that accidently used the same name. That made my .css available. But I'm still wondering about the described parser behaviour.
You declare the name groovecubes.portlet.gallery.css but try to access it as ++resource++groovecubes.portlet.gallery instead (note the missing .css there).
Either use ++resource++groovecubes.portlet.gallery.css/mycss.css or remove the .css part from the resourceDirectory registration.
If that was just a typo, check that the ZCML file is actually being loaded; the registration itself is fine if the names match.
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).
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.