How can I apply a branching logic for an entire section. At present, I have to do it to individual questions within the section.
If you are on a sufficiently recent version (version 12.0.0, released 2021-11-22), you can employ form display logic; that is, apply branching logic to the display of an entire form.
Prior to its inclusion in the core code, this functionality was provided by an external module called 'form render skip logic'.
Ask your local admin for advice.
I realized redcap does not have an easy way to do this except via exporting the data dictionary and copy pasting the branching logic across all questions of interest then re-importing.
Related
I would like to add a non-standard variant of a language already supported by Stanza. It should be named differently from the standard variety included in the common distribution of Stanza. I could use a modification of the corpus for training the AI, since the changes are mostly morphological rather than syntactical, but how many steps would I need to take in order to make a new language variety for Stanza from this background? I don't understand what data are input and what are output in the process of adding a new language in the web documentation.
It sounds like you are trying to add a different set of processors rather than a whole new language. The difference being that other steps of the pipeline will still work the same, right? NER models, for example.
If that's the case, if you can follow the steps to retrain the current models, you should be able to then replace the input data with your morphological updates.
I suggest filing an issue on github if you encounter difficulties in the process. It will be a lot easier to back & forth there.
Times when we would actually recommend a whole new language are when 1) it's actually a new language or 2) it uses a different character set - think different writing systems for ZH or for Punjabi, if we had any Punjabi models
I'm using h2o's xgboost implementation in Python. I've saved a model to disk and I'm trying to load it later on for analysis and predicting. I'm trying to access the input features list or, even better, the feature list used by the model which does not include the features it decided not to use. The way people advise doing this is to use varimp function to get the variable importance and while this does remove features that aren't used in the model this actually gives you the variable importance of intermediate features created by OHE the categorical features, not the original categorical feature names.
I've searched for how to do this and so far I've found the following but no concrete way to do this:
Someone asking something very similar to this and being told the feature has been requested in Jira
Said Jira ticket which has been marked resolved but I believe says this was implemented but not customer visible.
A similar ticket requesting this feature (original categorical feature importance) for variable importance heatmaps but it is still open.
Someone else who found an unofficial way to access the columns with model._model_json['output']['names'] but that doesn't give the features that weren't used by the model and they are told to use a different method that doesn't work if you have saved the model to disk and reloaded it (which I am doing).
The only option I see is to just use the varimp features, split on period character to break the OHE feature names, select the first part of all the splits, and then run a set over everything to get the unique column names. But I'm hoping there's a better way to do this.
I want to make the editor experience better and more visually pleasing when filling in content on a page (In all properties view). Could be a simple divider or a heading..
I am already using tabs, whenever it makes sense. Also, I have been experimenting with using blocks as properties. This adds a nice separation with at clear heading, but it is so much more code to maintain and a bit of a mess to be honest when the properties truly belong to the page type.
Out-of-the-box, it is not possible to decorate properties with headlines, unless you use block-properties, as you mention yourself.
However, I thought your question was quite interesting, and I discovered that extending Episerver to accommodate this behavior is surprisingly easy. I have written an example solution, which you're free to use as you like: https://arlc.dk/grouping-properties-with-headlines-without-property-blocks.
If you dislike the solution, an alternative approach would be to introduce your own Property-type (Headline), and create a 1) a custom dojo-widget to simply display a headline, and 2) an EditorDescriptor to set the ClientEditingClass.
Linus wrote an excellent blog post on this here: https://world.episerver.com/blogs/Linus-Ekstrom/Dates/2012/7/Creating-a-custom-editor-for-a-property/.
EDIT:
I see, I have skipped too quickly over the overriding part.
You don't have to override any files by replacing them, and you won't have to extract Shell.zip (unless you're curious how Episerver has implemented their widgets). The part that overrides the specific component is define("epi/shell/form/Field". As long as your definition of this widget is loaded after shell, dojo will use your implementation, whenever something is requiring "epi/shell/form/Field". The thing that ensures your implementation is loaded after, is in module.config, under 'This injects our field-implementation [...]'.
The path ~/ClientResources/Scripts/Shell/Field/Field.js is simply the location I have chosen to put the overriden version of Field.js. You can put it wherever you like, as long as you update module.config accordingly, with the new path.
It works like this: First, Episerver defines widget A. Then you define a widget with the same name, A. When anything tries to fetch A, it returns your implementation, rather than Episerver's.
I need two paginations on one page, is it possible to do this with codeigniter?!? Of course they must operate independently of one another.
Yes and no. If you want two different pagination visuals (customized renderings of the library) then sure. The problem you'll run into is by default the pagination library will pull the current page out of your $ci->uri->segments() list automatically to determine which page to mark as "active".
I do not know of a way to explicitly override this. Perhaps if you made a MY_Pagination that took an additional $config value for current page you could get it to behave like that. I haven't looked at the library's code in a while so you'd have to do some digging.
Honestly though, I'd suggest you build your own, it's not incredibly hard to do some simple math to determine what numbers to link.
Also you'll run into issues with CI's Pagination Library if you want the "current page" part to be NOT the last segment in your url. This may have been fixed lately but last time I looked it was the stop-gap for me using the library all together.
Bottom Line Invest the time in making your own if you want more than it's basic functionality, it's simple enough, just make yours reusable if you can.
I'm trying to play with the new syntax coloring capabilities of VS2010 based on Noah Richards' diff coloring sample. The goal is to create syntax coloring for SpecFlow (http://www.specflow.org).
In my case, finding the syntax elements are fairly complex and not line-level. Therefore, when I implement the GetClassificationSpans I don't want to re-parse the entire file, but rather take the state of the beginning of the changed text and parsing the content from that point on.
I thought that I can get the previous classifications as ClassificationTags. I did this using the IBufferTagAggregatorFactoryService class.
It works, but I'm not sure whether this is the best way to go. Shall I create only tag aggregator for the entire classifier class or I can create it every time when GetClassificationSpans is called? Shall I create a special tag to remember the parsing state?
Maybe this is anyway not the right way to go, I'm also interested in other suggestions.
Br,
Gaspar
Edit: I've found a good article series in the topic: http://www.hill30.com/MikeFeingoldBlog/index.php/2009/07/31/django-editor-in-vs-2010-part-1-colors/
Essentially, you'll have to remember the state yourself. Most VS language services keep a state cookie for the beginning of each line that they update on text change.
At any point, getting classifications (through either a classifier aggregator or tag aggregator) will always result into a call into the current classifiers/taggers, so it won't be returning any type of cached state (or the "last" classifications returned). The editor doesn't really cache this information, and just acts as a dumb pass-through for the information your classifier provides to the visible lines being formatted.
Also, If you do it from a classifier (provided by either an IClassifierProvider or ITaggerProvider), you are setting yourself up for some nasty recursion, especially if your classifier responds to GetClassificationSpans by calling into the aggregator (which then calls back into your classifier for some earlier text, etc.). If your classifier needs to consume other classifications to work correctly (and not its own classifications), the only safe way to write that is to:
Implement your "classifier" as an ITagger<IClassificationTag>, and provide it from an IViewTaggerProvider.
Grab an ITagAggregator<IClassificationTag> from an IBufferTagAggregatorFactoryService, but only once.
Implement IDisposable on your tagger and dispose the tag aggregator in Dispose().