maybe someone can help me on this. I am trying to generate a document via the DocumentGenerator interface. All in all this works well, except that the DocumentGenerator does not replace the Report Constants with actual values (which are defined on the report package stereotype.
This is the general flow of the document creation code (which generally works):
var gen = Repository.CreateDocumentGenerator();
gen.SetProjectConstant("ReportName", "My Project");
gen.NewDocument(string.Empty);
gen.ReplaceField("ReportName", "My Project");
gen.InsertCoverPageDocument(tags[REPORT_COVERPAGE]);
gen.InsertBreak(DocumentBreak.breakPage);
gen.InsertTOCDocument(tags[REPORT_TOC]);
gen.InsertBreak(DocumentBreak.breakPage);
gen.DocumentPackage((int)nativeId, 0, template);
gen.SaveDocument(fileName, DocumentType.dtDOCX);
I tried ReplaceField and SetProjectConstant both and one at a time before and after calls to NewDocument/InsertCoverPageDocument:
Strangely there is one constant that is being replaced: ReportSummary.
When I run the document generator via "F8" all constants are being replaced correctly.
Other project constants are being replaced correctly.
I can reproduce the behaviour on EA v14.1.1429 and v12.0.1215.
Does someone have a hint for further troubleshooting? Thanks in advance!
========== UPDATE ==========
When I use ReplaceField at the end (before the actual call to SaveDocument the following Report Constants get replaced: {ReportTitle} and {ReportName}
I discovered some workaround: when I manually remove the predefined {Report~} constants from the template and re-add them as Project Constants, their values get replaced correctly.
I will examine this further and give an update as
I did some further investigation on this and came to the following conclusion and workaround (as I have received no comments or answers on this):
I deleted all references to ReportConstants in my EA templates and replaced them by ProjectConstants with the same name.
In my code where I want to generate the documentation I (re)set all ProjectConstants with the actual values via SetProjectConstant and additionally added a call to ReplaceField to replace the constants with the actual values.
The previous mentioned calls are inserted directly before the call to SaveDocument document.
tags.ForEach(t =>
{
if (string.IsNullOrWhiteSpace(t.Key)) return;
generator.SetProjectConstant(t.Key, t.Value);
generator.ReplaceField(t.Key, t.Value);
});
generator.SaveDocument(fileName, DocumentType.dtDOCX);
If someone comes up with a better resonse or explanation for the behaviour I am happy to accept this as answer.
I have also found that when you call ReplaceField on these project constants in a CoverPage template, the formatting defined in the template is overwritten. It seems that some of the SetProjectConstant calls actually set the values as you would expect, and the rest do not.. hence the need to call both sets of APIs.
Related
Is the property "health.config.enabled" still valid and being processed in current Spring Cloud?
If yes, where in the code it is being done?
The property is in the current official documentation and has worked well for me so far (in cloud clients).
But as a whole string, it cannot be found anywhere in the current source code (besides the doc source).
For me as a beginner, it was easy to find in the old version of ConfigClientAutoConfiguration.java
Recent version of ConfigClientAutoConfiguration.java does not contain that whole property name, although I guess it's still being processed but in a more abstract way that I don't understand yet. Thus I'd appreciate even a hint in the form of "what used to be done on line "#ConditionalOnProperty(value = "health.config.enabled", matchIfMissing = true)" before is now roughly done on line XY".
Thanks.
It is replaced by #ConditionalOnEnabledHealthIndicator("config") (see here).
From the javadoc for that annotation
Blockquote
#Conditional that checks whether a default health indicator is enabled. Matches if the value of the management.health.<name>.enabled
So the new property is management.health.config.enabled
I have been researching about this term for so many hours, but I found anything useful yet.
Hope you can help us building this redmine plugin, or provide us some research links to help us find the correct key.
What we want to build
The thing is we want to update one custom field in redmine (let's name it 'Target_CF') whenever another one is created or updated.
We are looking for incrementing possible values of Target_CF, so we can have all custom field's names available to select.
Of course, we want to achieve this without directly editing Redmine's Core, so we thought developing a plugin would be the best approach.
Our plugin also creates and configures a new custom field (the one mentioned above), but I will let this out of the question, because I think it is not relevant for this.
Where we are right now
We have identified some hooks that could be useful for us, as the following:
:controller_custom_fields_new_after_save
:controller_custom_fields_edit_after_save
We have the following directories/files structure so far:
plugins/
custom_plugin/
init.rb
lib/
hooks.rb
The code we have written
init.rb
require_dependency 'hooks'
Redmine::Plugin.register :custom_plugin do
name 'custom_plugin'
author 'author name'
description 'description text'
version '1.0.0'
end
hooks.rb
class Hooks < Redmine::Hook::ViewListener
def controller_custom_fields_edit_after_save(context={ })
#target_custom_field_name = "Target_CF"
CustomField.find_by_name(#target_custom_field_name).possible_values.push(context[:custom_field].name)
end
end
The result of this code is none. I mean, no erros, no updates, nothing at all. There is no change in our possible values after editing/creating another custom field. We are sure there is something we don't know, some concept or workflow, and due to this we are doing something so badly.
Please, help us understeand what we are missing.
Previously we have succesfully developed another plugin that overwrites certain views. So we have kind of little skills in views related plugins, but zero experience at all at controllers ones.
We are using a Redmine 3.2.0 stack by Bitnami and a mysql database.
Well, finally we found out how to extend base controller's methods. I will post it here so hopefully this can be useful to anyone who finds the same doubts we had.
After some more researching, we conclude that it is mandatory to extend base controllers, in order to not directly modify core methods.
This is our final directories/files structures:
plugins/
custom_plugin/
init.rb
lib/
custom_plugin/
issue_custom_field_patch.rb
We previously stated that we could use some hooks to inject our desired functionality, but it seems not to work that way with controllers. On the other hand, we built a patch which will extend target class functionality.
Our final working code
Init.rb
require 'redmine'
ActionDispatch::Callbacks.to_prepare do
require_dependency 'issue_custom_field'
unless IssueCustomField.included_modules.include? CustomPlugin::IssueCustomFieldPatch
IssueCustomField.send(:include, CustomPlugin::IssueCustomFieldPatch)
end
end
Redmine::Plugin.register :custom_plugin do
name 'custom_plugin'
author 'author name'
description 'description text'
version '1.0.0'
end
issue_custom_field_patch.rb
module CustomPlugin
module IssueCustomFieldPatch
def self.included(base) # :nodoc:
base.extend(ClassMethods)
base.send(:include, InstanceMethods)
base.class_eval do
unloadable
after_save :update_possible_values
end
end
end
module ClassMethods
end
module InstanceMethods
def update_possible_values
self.reload
updatedPossibleValues unless self.name == "Target_CF"
end
private
def updatedPossibleValues
#safe_attrs = ['project', 'description', 'due_date', 'category', 'status', 'assigned_to', 'priority', 'fixed_version', 'author', 'lock_version', 'created_on', 'updated_on', 'start_date', 'done_ratio', 'estimated_hours', 'is_private', 'closed_on']
#custom_fields = IssueCustomField.all.select {|cf| !cf[:position].nil?}.collect {|cf| cf.name}
#possible_values = #safe_attrs + #custom_fields
CustomField.find_by_name("Target_CF").update possible_values: #possible_values
end
end
CustomField.send(:include, IssueCustomFieldPatch)
end
Functionality explained
As we stated in the question, we needed to update Target_CF possible values each time the users create/modify/removes a custom field from Redmine.
We extended IssueCustomField's class's instance methods, triggering our new function 'updatedPossibleValues' after each save. This includes creating new custom fields, and of course, updating existing ones and removing them. Because we reload our list of possible values each time, we had to control if its position were nil. If it is, this means that custom field has been removed.
Because of the ultimate action of this patch, which is the updating of another custom field, this also triggered our function, causing an infinite loop. To prevent this, we linked our functionality to every other custom field which name was not 'Target_CF'. A bit rusty fix, but we couldn't find a better approach.
I hope this can be useful to somebody in the future, as they could invest a fraction of time that we spent on this.
Comments, fixes and improvements are very welcome.
Based on: https://www.redmine.org/projects/redmine/wiki/Plugin_Internals which is a bit outdated, but finally could complete the code with help of another resources and forums.
I'm working on a Pug template in VS Code and whenever I try to use the emmet abbreviation input:text (or any input for that matter), it resolves to input#(type="text", name="").
It's not the end of the world, but it's driving me crazy, and I can't figure out why it's doing so or how to change it.
I guess my question is: is there any way to change this behavior or any place that I can draw attention to this?
The problem is the treatment of the attributes id and class for indent-based syntaxes (Slim, Pug, etc.).
For some reason it removes the attribute from its current position and pushes to the front the strings # for id and . for class.
This is controlled with 2 regex statements near line 3297 in
C:\Program Files\Microsoft.VS.Code\resources\app\extensions\emmet\node_modules\vscode-emmet-helper\out\expand\expand-full.js
Change
const reId = /^id$/i;
const reClass = /^class$/i;
to
const reId = /^Xid$/i;
const reClass = /^Xclass$/i;
You must also remove the cached version of this file in the directory
C:\Users\__username__\AppData\Roaming\Code\CachedData\__some_hex_value__
Restart VSC and it should work.
For linux systems you have to find the location of these files.
I finally understand why this is happening, and that my confusion was basically a misunderstanding of proper form creation.
All text inputs should have an id associated with them, so Emmet is expecting an ID in the shorthand. So this:
input:text#user
resolves to
input#user(type="text", name="")
Which works great! Too bad it took me months of confusion to I realized how daft I am!
Say I've written a class in a package, called mypackage.myclass. I've written my own HTML documentation for the package and the class, and have included this within the MATLAB help browser as described in the MATLAB documentation.
I can display this HTML documentation by using the help browser to navigate directly to it, but typing doc mypackage.myclass does not display it; instead it displays some HTML documentation that is auto-generated by helpwin (which is a nice feature, but not what I want - the auto-generated documentation is too techy for my users).
How can I force doc to display my documentation, rather than the auto-generated documentation?
Equivalently:
When you run doc docTopic, inside the doc command the Java class com.mathworks.mlservices.MLHelpServices.showReferencePage(docTopic) gets called. If a reference page for docTopic exists, it displays it and returns a success value. If a reference page doesn't exist, it returns a failure value, which then causes helpwin(docTopic) to get called. Somewhere there must be some catalog that connects values of docTopic with individual reference HTML files. How can I fiddle with that catalog - or can I create one for my package?
MathWorkers and #Yair, please give me enough undocumented rope to hang myself with :)
As far as I know this is not possible and not intended by MathWorks. I don't know of an undocumented way of doing this either. As far as I remember the keywords for doc are hard-coded somewhere.
Depending on your setup you can try the following: Prepare your own doc command that uses web(..., '-helpbrowser') to display HTML pages in MATLAB's help browser:
function doc(topic)
my_topics = {
'foo', 'foo.html'
'bar', 'bar/help/intro.html'
};
for i = 1 : size(my_topics, 1)
if strcmpi(topic, my_topics{i, 1})
web(my_topics{i, 2}, '-helpbrowser');
return;
end
end
% Fall back to MATLAB's doc. Note that our doc shadows MATLAB's doc.
docs = which('doc', '-all');
old_dir = cd();
c = onCleanup(#() cd(old_dir));
cd(fileparts(docs{2}));
doc(topic);
end
If you put that function in a file doc.m and put the corresponding directory at the beginning of the MATLAB path (see help addpath) then it will be called instead of the built-in doc.
Of course you could use some other place to store your custom doc mapping (a file, for instance) or use some kind of dynamic lookup scheme.
UPDATE: As of MATLAB R2012b, the '-helpbrowser' option of web is undocumented. This is probably related to the GUI changes in that MATLAB version, which also include the help browser. web(..., '-helpbrowser') still works as intended, but that may change in future versions of MATLAB. As far as I know, there is no documented way of opening any HTML page in the help browser in R2012b.
I'm using toLocalizedTime to output a date, as below
<span tal:content="python:here.toLocalisedTime(date.get('start_date'))"/>
This outputs eg. 2007/08/02, I'm just curious as to how one would alter the output so that it reads 02/08/2007
I'm not having much luck finding much info on toLocalizedTime, would someone point me in the right direction?
This depends on whether you have English selected as the site language (Site Setup >> Language). If so, then the default settings are used. You can change the defaults by dropping down into the ZMI, then into 'portal_properties', then 'site_properties'. The fields to change are either 'localTimeFormat' or 'localLongTimeFormat' depending on whether you pass in 'long_format=1' to the toLocalisedTime function.
If on the other hand, you have translations set up, the format may instead be pulled from the translation file for the locale selected. I'm not sure what is the easy way to change the format in this case (other than switching the site back to English). I guess you can register your own translation file but I've never needed to do that so you're going to have to look up the details.
Date string formatting follows the Python rules (http://docs.python.org/library/time.html#time.strftime).
Perhaps even more detail than you need:
here.toLocalizedTime()
is defined in the plone browser view at...
CMFPlone/browser/ploneview.py
which looks up the 'translation_service' utility, to call its 'ulocalized_time' function, defined at...
CMFPlone/TranslationServiceTool.py
which itself calls the 'ulocalized_time' function defined at...
CMFPlone/i18nl10n.py
As always, you can learn interesting things by grepping the source code ;-)
For an up to date answer for Plone 4.3 (after going through the source code)
These fields are now in the registry found at:
http://localhost:8080/yoursite/portal_registry
Then filter on "i18nl10n", which should give you the 4 fields you need to change.