I'm using Doxygen v1.8.16, on my C# class library. I’d like all of my documented class pages to include text that states what namespace it is part of. I COULD accomplish this manually by adding all the documented class in a namespace to a group using the /ingroup namespaceGroupName command, in the class's comments. But as this seems awfully redundant, time-consuming and error-prone, I’m wondering:
Is there any way to configure the display of a class's namespace, on a class's page (for all classes in all namespaces), without manually editing/listing each class?
Currently, what I'm looking for can only be found on my alphabetical “Class Index” page, where it shows both the class name and the namespace it belongs to, with text as links, in this form: ClassName (Name.Space)
I should mention, I intentionally set the option in my config file: HIDE_SCOPE_NAMES = YES
While changing this option to NO would technically work, it would affect more than just the documented class page, which I don’t want to do. (I would also prefer to have the namespace as a separate text item, like in parenthesis or a different font/size/line.)
Edit: Here is an example of the standard output, and in orange, the change/addition to the output that I'm looking for. (I realize the namespace is displayed in the menu right above the class title, but I need it in the same area as the other groups.)
Related
I'm currently looking for a way to capture only svelte components on the DOM tree during development mode. I can see that we I run npm run dev all elements and conponents have the "class='svelte-somerandomID'". Does this only happen in development mode?
Yes, it's only in during development that all elements get a scoping class -- and only with some tools. Actually it's a hack we've added in vite-plugin-svelte to enable more power CSS only HMR.
The classes you're referring to are what Svelte uses to make the CSS in a component apply only to the elements of this component. It adds a class that is unique to the component to all elements that can be affected by the component's CSS, and it also modifies your CSS rules to add the same class to them.
Normally the compiler only adds the scoping class to elements that can actually be targeted by the existing CSS rules in your component. If you really want all the elements in a component to have the scoping class, you can use the same trick that I linked to above: add the following rule to your component's CSS.
* {}
By default the generated class names are a hash of the component's CSS content. But you can also customize them with the cssHash compiler option. Note that vite-plugin-svelte also changes how the class names are generated, to be based on the file name instead of the content.
Since every element in the component would be targeted by this roule, this will cause the Svelte compiler to add the scoping class to all the elements.
If you wanted to automatically generalize this to every element of every component, you may want to do it with a preprocessor (if you need some inspiration, the code I've linked too actually implement this with a preprocessor).
I'm not sure if this is what you really want though. For one thing, only elements get a scoping class: components don't get a scoping class, because components don't have dedicated elements in the DOM (only the ones you may or may not add via the component's markup). The above trick would only give you a mean to select every element of a Svelte component. There might probably be easier or cleaner ways to achieve what you really want. For example, a simple wrapping component, or an action, that would use wrappingElement.querySelectorAll('*') or something...
I have a bunch of namespaces (containing free functions) and classes (containing member functions, obviously), each of which has a Doxygen comment at the top level and some Doxygen comments for its members. They're within a top-level namespace (one for the whole project) and secondary namespaces (to break the project into packages). Like this:
proj/pkg1/foo.hpp: class proj::pkg1::Foo
proj/pkg1/bar.hpp: class proj::pkg1::Bar
proj/pkg1/baz.hpp: namespace proj::pkg1::Baz
proj/pkg2/one.hpp: class proj::pkg2::One
proj/pkg2/two.hpp: namespace proj::pkg2::Two
I don't have any #file comments. They'd be totally redundant, because there's already exactly one main comment per component, which is attached to the main class or namespace.
I tried running this through Doxygen, and the result is a mess:
The namespaces and classes are separated into two different hierarchies, both in the header row and the navigation panel. But I want them all in a single tree, because e.g. pkg2::One belongs alongside pkg2::Two.
The main hierarchy of namespaces is buried three levels down the navigation panel (Project name -> namespaces -> namespace list). It's next to "Namespace Members" - who uses that!?
There's another hierarchy for the files (and directories). This is redundant because these exactly match the hierarchy of namespaces (and classes).
This is digressing a bit now, but I'd also like to add comments to the package namespaces. These have the same problem of separating classes and namespaces (not such a big deal) but also show up various free functions e.g. operator<<(proj::pkg2::One.
Is there any way to clean things up a bit? Maybe with Sphinx and Breathe?
Example screen shot
Here is what Doxygen produces by default on the above code (it doesn't even mention Baz and Two!), and what I prefer it to look like:
This is a particularly horrible hack, but I mention it for the record. You could decide that classes are dealt with best by Doxygen, and relabel all the component namespaces (the third-level ones) to classes. Like this:
namespace proj {
namespace pkg1 {
/// #brief The Doxygen comment goes here.
#ifdef DOXYGEN
class
#else
namespace
#endif
Baz {
Then set PREDEFINED = DOXYGEN in the Doxyfile.
Obviously, the drawbacks to the this are that it looks ugly as sin in the source code, and it's confusing that it shows up as a "class" in the documentation.
To get the ball rolling, here's a possible solution:
Change expectations a bit: instead of hoping for the two level structure to be presented to readers all in one go, put up with part of it presented at a time. Make the user click through a separate page for each namespace in the tree:
The documentation page for the proj namespace shows all the packages it contains (i.e. in the example it shows namespaces pkg1 and pkg2).
Each package namespace page shows all of the classes and component namespaces in it (in separate lists, which is a little annoying, but at least all the stuff for each package is together).
You can hide the tree view with GENERATE_TREEVIEW=NO and hide the header row DISABLE_INDEX=YES.
The mainpage can just be a link to the top-level proj namespace page (with the usual content of the main page moved to the proj detailed description) with code like this:
/**
#mainpage
#ref proj "Click here for the proj documentation"
*/
A slight variation is to manually list the packages in the main page with code like this and bypass the proj namespace page. This would work well for a project that doesn't have an overall top-level namespace, or where you want finer control over the main page.
/**
#mainpage
Packages:
- #ref proj::pkg1 #n #copybrief proj::pkg1
- #ref proj::pkg2 #n #copybrief proj::pkg2
*/
I need to implement a custom ResultHandler but I am confused about how to actually integrate my custom class into the software package.
I have read this: http://elki.dbs.ifi.lmu.de/wiki/HowTo/InvokingELKIFromJava but my question is how are you meant to implement a custom result handler such that it shows up in the GUI?
The only way I can think of doing it is by extracting the elki.jar package and manually inserting my custom class into the source code, and then re-jarring the package. However I am fairly sure this is not the way it is meant to be done.
Also, in my resulthandler I need to output all the rows to a single text file with the cluster that each row belongs to displayed. How tips on how I can achieve this?
There are two questions in here.
in order to make your class instantiable by the UIs (both MiniGUI and command line), the classes must implement our Parameterization API. There are essentially two choices to make your class instantiable:
Add a public constructor without parameters (the UI won't know how to set your parameters!)
Add an inner static class Parameterizer that handles parameterization
in order to add your class to autocompletion (dropdown menu), the classes must be discovered by the MiniGUI/CLI/other UIs. ELKI uses two methods of discovery:
for .jar files, it reads the META-INF/elki/interfacename service files. This is a classic service-loader approach; except that we also allow ordering instances.
for directories only, ELKI will also scan for all .class files, and inspect them. This is mostly meant for development time, to avoid having to update the service files all the time. For performance reasons, we do not inspect the contents of .jar files; these are expected to use service files.
You do not need your class to be in the dropdown menu - you can always type the full class name. If this does not work, adding the name to the service file will not help either, but ELKI can either not find the class at all, or cannot instantiate it.
There is also a tutorial on implementing a custom result handler, but it does not discuss how to add it to the menu. In "development mode" - when having a folder with .class files - it will show up automatically.
I am automating using Selenium, Capybara and siteprism.
Using rubymine, I want to get code completion such that I can type #page. and get a list of the methods (this works) and a list of the elements and sections defined in the page object using siteprism.
Is there any way to do this in Rubymine?
Sublime text editor does this, but yet it doesn't handle the class names and methods very well.
In site-prism the methods on a page-object class such as the getters, waiters, etc are added dynamically by the class methods element, elements, section, sections when the class is evaluated. This adds several methods about a particular element for each listing in the class.
That means there's no way for rubymine to simply read the files looking for def to determine what methods should exist on any instance of #page.
You might be able to code something up to get it working, but there's no straightforward solution.
I've been working on a component and currently I'm trying to do different things based on the selector chosen for the component.
So basically if I have a component with this structure
myComponent/
dialog.xml
myComponent.jsp
altView.jsp
I know that if I have a Node with resourceType myComponent I can request the alt view via browser by requesting "path/to/component/content.altView.html" and everything is hunky dory.
Similarly I can do a cq include and do something like:
# with cq include
<cq:include path="my/path.altView" resourceType="myComponent"/>
# or with sling include
<sling:include path="my/path" resourceType="myComponent" replaceSelectors="altView"/>
However, when I'm handling the request, I've seen some interesting behavior when looking at the RequestPathInfo Object.
For example, if we look at all 3 of the above cases I might have something like this:
# http://path/to/component/content.altView.html
slingRequest.getRequestPathInfo().getSelectors(); // {altView}
slingRequest.getRequestPathInfo().getExtension(); // html
# <sling:include path="my/path" resourceType="myComponent" replaceSelectors="altView"/>
slingRequest.getRequestPathInfo().getSelectors(); // {altView}
slingRequest.getRequestPathInfo().getExtension(); // html
# <cq:include path="my/path.altView" resourceType="myComponent"/>
slingRequest.getRequestPathInfo().getSelectors(); // []
slingRequest.getRequestPathInfo().getExtension(); // altView
I understand why the cq:include returns different results (we're making a request to my/path.altView and .altView coincidentally serves as the extension in this case). I'm curious if there is a normalized why to pull "altView" (or the selected view) regardless of if it's been used as an extension or selector. Or if this is normal and I just need to check both the extensions and selectors individually.
i.e
selectors = get selectors();
if selectors
do stuff
else check extensions
do stuff
Again thank you very much for your insights, this community is awesome.
[EDIT]
In response to an answer, I thought I'd give a little more context to what I'm doing. Basically our component structure is set up so that each of our components has an associated Java Class that handles the business logic. (I.E. apps/myapp/components/myComponent will map to com.mypackage.components.MyComponent) That said, within my component's Class I need to handle the control flow differently depending on how the component was called (i.e. what selectors/extensions/etc). For example, if my component was called normally I'd do the base behavior, but if it was called with selector (for exmaple) "altView" I would need to handle the alternative view differently, and in this alternative view different data will be available, etc.
My question was along the basis that it seems that i can give the "path" attribute of a "cq:include" tag the selector I want to use:
<cq:include path="my/path.altView" resourceType="myComponent"/>
However, when I check my RequestPathInfo in my component class to decide workflow, "altView" is returned as the extension, not within the String[] selectors. Note, the above compiles fine, and it selectors the correct .jsp file for rendering, the RequestPathInfo object just stores the data in a different place.
I'm starting to guess that places the selector into the path attribute works because the selectors and extensions modifiers alter the behavior vary similarly. mycomponent.altView.html resolves to altView.jsp whereas if I was to do mycomponent.altView it would also attempt to resolve a mycomponent/altView.jsp just as it would do the same for mycomponent.xml to mycomponent/XML.jsp
It seems like you're kind of working around Sling resolution. The easiest way to do "different things based on selector" in a given component (let's say my/new/component) is to create different renderers.
For example, say I am requesting /content/app/page.html, and on that page was the component my/new/component. Or if I request /content/app/page.selector.html, I want a slightly different experience for my/new/component.
In the cq:component, I would create two JSPs: component.jsp and component.selector.jsp. Sling will automatically know, based on the selector in the request, which renderer to use. Obviously each renderer can produce a different experience.
The same is true for extension. In the example, component.jsp and component.selector.jsp are actually equivalent to component.HTML.jsp and component.selector.HTML.jsp. The HTML is just implied. However, you could do component.XML.jsp and component.selector.XML.jsp and Sling will again, pick the most relevant selector, based on the selector(s) and extension of the request.
Now, what if you don't want the selector to show up in the page request's URL (in my opinion you shouldn't)...
You can include your component using sling:include and add the selector, like you've done.
The caveat is that sling:include works a little differently than cq:include, so only use this when you need to. Instead, you could also use Sling mapping to hide the selector from the user. The majority of the time I would recommend this approach.
I'm not sure what you were trying to do with adding the selector to the "path" attribute. I don't think that would do anything. The "path" is defining the resource name (and the node name if the resource is not synthetic). Including the selector in that wouldn't do anything, except make the resource name include a period and the selector.
My question was along the basis that it seems that i can give the
"path" attribute of a "cq:include" tag the selector I want to use:
<cq:include path="my/path.altView" resourceType="myComponent"/> However, when I check my RequestPathInfo in my component class to
decide workflow, "altView" is returned as the extension, not within
the String[] selectors.
As opposed to the cq:include tag, you could alternatively use sling:include tag, which provides attributes to modify the selectors & suffix on the request:
<sling:include resourceType="myComponent" path="my/path" addSelectors="altView"/>
or
<sling:include resourceType="myComponent" path="my/path" replaceSelectors="altView"/>
If you already have selectors on the request that you don't want to apply to myComponent.
In terms of the differences between Sling include & CQ include, there seems to be very little, apart from the latter also supporting script inclusion. From the docs:
Should you use <cq:include> or <sling:include>?
When developing AEM components, Adobe recommends that you use
<cq:include>.
<cq:include> allows you to directly include script files
by their name when using the script attribute. This takes component
and resource type inheritance into account, and is often simpler than
strict adherence to Sling's script resolution using selectors and
extensions.