Viewing all children classes with Yelp - mallard

I'm viewing the Rhythmbox documentation using Yelp. It's useful, but a few things are missing. Sometimes I want to view all subclasses of a particular class. There doesn't seem to be a way to find that out using the Yelp documentation viewer.
Eg. RB.Source has children RB.AutoPlaylistSource, RB.BrowserSource, RB.MediaPlayerSource, RB.PlaylistSource.
Is there a way to view such information?
Backstory: I'm viewing documentation generated using g-ir-doc-tool.

It's not so much an issue with Yelp. Yelp just shows the pages that were generated with g-ir-doc-tool, which unfortunately do not include known subclasses at this time. g-ir-doc-tool is still very much a work in progress. You should file an enhancement request at bugzilla.gnome.org, product glib, component introspection.
https://bugzilla.gnome.org/enter_bug.cgi?product=glib&component=introspection

Related

silverstripe dynamic backend for flexible frontend

I'm searching for a while, but didn't find a practical answer for the following problem:
An Articlepage in the Frontend can contain different types of sections. For example a block text section and than a text section with left photo an at the end an wallpaper photo.
Now I want to implement this in my backend dynamically, so that I can choose, which type of section and -even more important- how many sections my article should contain.
In my recent project I've solved the problem as an Articlesection with a Dropdown, wich contains the different section styles. And one article hat xy Artilesections as childpages. In the frontend I included all Childpages of the Article - so to speak the Articlesections, where I've checked with if conditions, which sectionsystyle I have in this Section and here I styled the section as I want.
For example Artilce1 has 2 Childpages: Articlesection1 and Artilcesection2.
In AS1 I have choose in the dropdown: right text with left photo and check with if conditions, to style the section. The same with AS2, that is for example a wallpaper photo.
This semiprofessional solution worked, but there are some bugs with displaying the Article correct in the backend, because I have to declare the Articlesections as Includes and not native childpages. And in generell this don't seems like the developers of silverstripe want the users to do it this way..
Are there better ways to implement a dynamically changing backend, so I can decide, which and how much sections I have in the frontend.
Take a look at https://github.com/sheadawson/silverstripe-blocks. There's quite a few addons that offer similar functionality as Blocks such as Elemental. The following blog post might also be useful too - https://www.silverstripe.org/blog/silverstripe-strips/.
Thank you for your reply, but there is a problem, because I don't work a lot with the terminal and the composer. In principle I want to install sheadawsons silverstripe-block. I have installed the composer and run the command:
"composer require sheadawson/silverstripe-blocks" it seems like it installed that correctly, because I became no errors, but what then? With dev/build -to refresh the database- happened nothing and the following instructions in the readmy chanced nothing. Should I copy any files in my Sivlerstripe web folder or what else..? I'm a bit desperate, because there is such a poor documentation.
Tank you

Get the results of an (existing) code inspection

I am new to writing intellij plugins, so I apologize in advance if my question might be a bit unclear.
I know that (live) code inspections are achieved via Annotators or LocalInspectionTools. I also know there is an API to write a custom Annotator or Inspection tool and I have seen several examples.
What I do not know (my question): is there a manager/helper/"global inspector" that can provide me with the results of an existing code annotator/inspection process (done by the IDE's plugins or by some 3rd party plugin)?
For instance: I do not want to write a custom Lint annotator/inspection plugin for WebStorm. One can configure JSLint/JSHint inside WebStorm settings. The results of the live inspection can be seen over the current file/current open editor.
I would like to get the results of this live inspection, that occurs in the current open editor (inside my own custom code). For this I am interested in the API to get this annotator/inspector and/or the results it provides.
(I apologize for maybe using annotator and inspection terms in a confusing manner)
If there is another question (which I could not find) that duplicates what I have asked above, please re-direct me.
Thank you in advance!
Andrei.
Unfortunately regular annotating process for the linters is asynchronous so you cannot get the annotation results directly (by calling 'Manager' method).
You can create instances of JSLintInspection, JSHintInspection, etc. and call #createVisitor().visit(File) method but the operation is very slow and you must call it outside of AWT thread.
Also you can try to run the method com.intellij.codeInsight.daemon.impl.DaemonCodeAnalyzerEx#processHighlights but as I mentioned above the annotation results for linters can be not available (or outdated)

Unmarshaling SOS DescribeSensor response via JSONIX yields incomplete object

I am attempting to use jsonix to unmarshal xml response from an SOS DescribeSensor request. In the broader scope I am going to be using jsonix to unmarshal all responses from SOS, particularly 2.0. I noticed that the response uses SML or SensorML namespace and so I added the extra module dependencies and sub-dependencies (namely GML_3_1_1, SWE_1_0_1, IC_2_0, SMIL_2_0, SMIL_2_0_Language, and of course SensorML_1_0_1). Before I added these I noticed the return was a generic json (see first screenshot, particularly near sml:physicalsystem). After I added the dependencies I got an error in my console during part of the unmarshaling process which I do not understand (see second screenshot). Here is a link to the xml response from the server for reference. https://drive.google.com/file/d/0B8LdnPVJpHz7M3VGb0FZc2lQcjQ/view?usp=sharing. I would really like to understand if this has anything to do with the ordering of the modules when I create the context though I believe it is fine. Once the solution to this is discovered I have two follow up questions.
Is it reasonable to expect (in general) that using the modules built from the ogc-schemas on the highsource github page should allow me to handle all responses via jsonix? i.e. every element will always be mapped to a defined type. I know these schemas/mappings are very complicated.
Are there any other tools I can use to verify the modules or validate them against schemas to make life easier rather than tracking down elements on an individual basis or tracing through various module files when jsonix seems to parse incorrectly?
Thanks in advance - Richard3d
var context = new Jsonix.Context([XLink_1_0, GML_3_2_1, IC_2_0, SMIL_2_0, SMIL_2_0_Language, GML_3_1_1, SWE_1_0_1, SensorML_1_0_1, OWS_1_1_0, SWE_2_0, SWES_2_0, WSN_T_1, WS_Addr_1_0_Core, OM_2_0, ISO19139_GMD_20070417, ISO19139_GCO_20070417, ISO19139_GSS_20070417, ISO19139_GTS_20070417, ISO19139_GSR_20070417, Filter_2_0, SOS_2_0]);
Disclaimer: I am the author of jsonix and main dev of ogc-schemas.
First of all, you're on the right track, stay on it.
Yes, if you have all the required mappings then you should get a "nice" JSON with all the properties with specific types, cardinatilities etc.
The goal of Jsonix is to provide bi-directional XML<->JSON conversion with deterministic structure, types and cardinalities.
The goal of OGC Schemas is to provide JAXB and Jsonix mappings for all of the OGC Schemas.
So togethere these two should allow to transform any OGC XMLs from/to JSON.
"Generic JSON" was actually just DOM. If a property allows DOM and Jsonix does not have mapping for certain element, it is just taken as DOM. You were just missing SensorML mappings.
You're right the structure of schema dependencies is very complex. But this is something we should take to OGC. :) It's a bit crazy that you need, like, a dozen of schemas to read sensor data. I was actually intending to build automatic loading of dependencies but did not yet implement this feature.
The next GML_3_1_1.AbstractFeatureType problem is probably this issue. Try changing the order of mappings (move GML_3_1_1 to the earlier places). Actually the order of mappings should not be significant, but, well, there's a bug.
Tools to cross-check - no, probably not. My approach is to do roundtrip tests (unmarshal-marshal-unmarshal-check equality). From experience, there are normally a couple of caveats at the start, but then it works by design. Of course there are bugs in Jsonix and there may be problems with mappings, but this gets sorted out.
Also feel to create a support project here:
https://github.com/highsource/jsonix-support
For instance https://github.com/highsource/jsonix-support/s/sos.
Here's an example of such a support project:
https://github.com/highsource/jsonix-support/tree/master/l/lightstalker89
I need this because just downloading XML from Google Drive (a) takes me effort to set up the support project (b) legally dangerous as I have not idea where this XML comes from and if I have rights/license to add these files to my test suites.

Access virtual DOM contents

I wanted to implement a walkthrough tutorial but to do that I realised I needed to be able to select HTML elements from a property value (eg. name or id), ie get the value of a property from an HTML node. I think there currentlyis no way of getting an element's name in elm: could anybody please confirm? Does that mean I need to add something to virtual-dom package?
No, there is no way to really read a tree of Virtual DOM in Elm. If you look at the source for VirtualDom.elm, you'll see that nearly every function is implemented in native JavaScript, in the Native/VirtualDom.js file.
Sure, you could write some kind of native API to cheat the system and inspect the html like you're talking about, but the Virtual DOM was never meant to be used or queried in that way. The model with which you build your view should be the source of truth. Perhaps if you tweaked your design a bit, you would find that you don't really need this requirement after all.

Access closure property names in the content block at runtime

I want to evaluate my content blocks before running my test suite but the closures' property names is in bytecode already. I'm ooking for the cleanest solution (compared with parsing source manually).
Already tried solution outlined in this post (and I'd still wind up doing some RegEx/parsing) but could only get it to work via script execution engine. It failed in IDE and GroovyConsole. Rather than embedding a Groovy script in project's code, I thought I'd try using Geb's native classes.
Is building on the suggestion about extending Geb Navigators here viable for Geb's PageContentSupport class whose contentTemplates contain a LinkedHashMap of exactly what I need? If yes, would someone provide guidance? If no, any suggestions?
It is currently not possible to get hold of all content elements for a given page/module. Feel free to create an issue for this in Geb's bug tracker, but remember that all that Geb can provide is either a list of content element names or a map from these names to closures that create these elements.
Having that information isn't a generic solution to your problem because it's possible for content elements to take parameters and there are situations where your content elements will be available on the page only after some other actions are performed (for example you have to click on button to reveal a section of a page that uses ajax to retrieve it's content). So I'm afraid that simply going over all elements and checking if they don't throw any errors will not cut it.
I'm still struggling to see what would "evaluating" all content elements prior to running the suite buy you. Are you after verifying that your content elements still work to get a faster feedback than running the whole suite? I'm pretty sure that you won't be able to fully automate detection of content definitions that don't work anymore. In my view it will be more effort than it's worth.