Docpad: confused about extending template data - docpad
I'm totally confused about adding mongo data to template data. I haven't even started trying to get the data from a database as I can't get my templates to see test data (see below). This is in docpad.coffee for the moment, but ultimately g will be the output of mongoDB.
events:
extendTemplateData: (opts) ->
# {templateData} = opts
getGigsData: ->
g = { "date" : "3-4-2013", "location" : "Gent" }
return g
opts.templateData["getGigsData"] = getGigsData
And I hope to access it with <%= #getGigsData().date %>
Thanks so much for some guidance
I should add that this design is based on wanting to make it easy for the band to add gigs, without letting them edit the page content itself as I fear they would mess up the markup - if there are other ways to achieve this goal, I'd be pleased to hear.
Tried this locally. And hit the issue:
debug: Emitting the event: extendTemplateData
→ [2014-02-14 01:38:50.030] [/Users/balupton/Projects/docpad-extras/skeletons/so-21747504/node_modules/docpad/out/lib/docpad.js:1184] [DocPad.emitSerial]
error: Something went wrong with the action
→ [2014-02-14 01:38:50.037] [/Users/balupton/Projects/docpad-extras/skeletons/so-21747504/node_modules/docpad/out/lib/interfaces/console.js:107] [ConsoleInterface.destroyWithError]
error: An error occured:
ReferenceError: getGigsData is not defined
at Object.docpadConfig.events.extendTemplateData (/Users/balupton/Projects/docpad-extras/skeletons/so-21747504/docpad.coffee:42:44)
at ambi (/Users/balupton/Projects/docpad-extras/skeletons/so-21747504/node_modules/docpad/node_modules/ambi/out/lib/ambi.js:25:27)
at DocPad.<anonymous> (/Users/balupton/Projects/docpad-extras/skeletons/so-21747504/node_modules/docpad/out/lib/docpad.js:995:25)
at ambi (/Users/balupton/Projects/docpad-extras/skeletons/so-21747504/node_modules/docpad/node_modules/ambi/out/lib/ambi.js:23:18)
at Task.<anonymous> (/Users/balupton/Projects/docpad-extras/skeletons/so-21747504/node_modules/docpad/node_modules/event-emitter-grouped/out/lib/event-emitter-grouped.js:45:23)
at ambi (/Users/balupton/Projects/docpad-extras/skeletons/so-21747504/node_modules/docpad/node_modules/ambi/out/lib/ambi.js:23:18)
at fire (/Users/balupton/Projects/docpad-extras/skeletons/so-21747504/node_modules/docpad/node_modules/taskgroup/out/lib/taskgroup.js:163:25)
at b (domain.js:183:18)
at Domain.run (domain.js:123:23)
at Task.fire (/Users/balupton/Projects/docpad-extras/skeletons/so-21747504/node_modules/docpad/node_modules/taskgroup/out/lib/taskgroup.js:173:25)
at processImmediate [as _immediateCallback] (timers.js:330:15)
Which indicates that the error is actually inside our event handler, rather than inside our code. That for some reason getGigsData is not being set, despite our:
getGigsData: ->
g = { "date" : "3-4-2013", "location" : "Gent" }
return g
Examining the code, as a CoffeeScript user, I found the issue. As a non-coffeescript user, you can use the coffeescript compiler on the coffeescript website http://coffeescript.org to see the compiled javascript, which is:
({
events: {
extendTemplateData: function(opts) {
({
getGigsData: function() {
var g;
g = {
"date": "3-4-2013",
"location": "Gent"
};
return g;
}
});
return opts.templateData["getGigsData"] = getGigsData;
}
}
});
As we can see that is definitely not what we expected. We are just defining getGigsData inside an object, then doing nothing with it.
The issue is that we used a colon instead of an equals sign, so getGigsData: -> instead of getGigsData = ->. This is not a coffeescript thing, but you would have run into the same issue if this was javascript too, albeit javascript may be a bit more obvious due to the necessary squiggly braces around object definitions.
As a sidenote, if you prefer to use JavaScript with DocPad for whatever reason, that is totally supported. You could use a docpad.json or docpad.js file for your docpad configuration file. Another option, is to continue using CoffeeScript then just wrap JavaScript code within the backtick, see: http://coffeescript.org/#embedded
Related
CKEDITOR4 Mentions Plugin with ajax : javascript error
I have a javascript error using CKEDITOR 4 and the Mentions Plugin.
I can't solve this problem for 2 days, I'm stuck.
I've used the online builder to get CKEDITOR + Mentions plugin.
See my build here: https://ckeditor.com/cke4/builder/fbe187b32ec7c025e28e01a537c72c62
With the following configuration it works fine: I see the drop down list with the names : Anna, Thomas, John
CKEDITOR.config.mentions = [{feed: ['Anna', 'Thomas', 'John']}];
However, when doing an ajax call to get the data, I got a javascript error:
The script /ajax_mention.php
displays
["Anna", "Thomas", "John"]
with the following configuration :
CKEDITOR.config.mentions = [{feed: '/ajax_mention.php'}];
when I type in the editor "#anna", the names do not display
the /ajax_mention.php script is launched and displays the correct data (when I look at the "network" tab on Chrome. see screenshot)
["Anna", "Thomas", "John"]
However, this triggers a javascript error (looking at the Chrome console tab. see screenshot)
ckeditor.js?1645882460:916 Uncaught TypeError: Cannot read properties of null (reading 'addClass')
at g.selectItem (ckeditor.js?1645882460:916:473)
at d.onSelectedItemId (ckeditor.js?1645882460:912:276)
at f.q (ckeditor.js?1645882460:10:246)
at f.fire (ckeditor.js?1645882460:12:91)
at f.select (ckeditor.js?1645882460:920:294)
at f.selectFirst (ckeditor.js?1645882460:920:371)
at d.open (ckeditor.js?1645882460:910:503)
at d.modelChangeListener (ckeditor.js?1645882460:911:234)
at f.q (ckeditor.js?1645882460:10:246)
at f.fire (ckeditor.js?1645882460:12:91)
See screen copy:
https://polyglotclub.com/bug_ckeditor_mentions.jpg
screen copy
The solution was given by the Ckeditor team : see https://github.com/ckeditor/ckeditor4/issues/5107
When we use a hardcoded data in the array, such as ['Anna, 'Geralt'] the createArrayFeed() function changes the input structure from the mentioned above to:
[
{
id: 1,
name: 'Anna'
},
{
id: 2,
name: 'Geralt'
}
]
I've just adjusted data on the backend side to the structure above.
Unable to Call Function in Go debugger
I am following the "Little Go Book" by Karl Seguin, in order to learn Go.
My working environment is Visual Studio Code.
Upon debugging, when I try to call a function from the debug console, i get the following error:
"function calls not allowed without using 'call'", if I try using "call fib(10)", i get "Unable to eval expression: "1:6: expected 'EOF', found fib".
This is the function I am trying to evaluate:
//Fibonnaci
func fib(n int) int64 {
if n == 0 {
return 0
} else if n == 1 {
return 1
} else {
return fib(n-1) + fib(n-2)
}
}
If i try to call the function from the code itself ( from the main() for instance, it works perfectly).
However, if I set a breakpoint and try to call the same function from the debugger console, I get the below error:
Eval error: function calls not allowed without using 'call'
call fib(10)
Unable to eval expression: "1:6: expected 'EOF', found fib"
Failed to eval expression: {
"Expr": "call fib(10)",
"Scope": {
"goroutineID": 1,
"frame": 0
},
"Cfg": {
"followPointers": true,
"maxVariableRecurse": 1,
"maxStringLen": 64,
"maxArrayValues": 64,
"maxStructFields": -1
}
}
Looks like "Function calls via delve 'call' are not supported" yet github issue in microsoft/vscode-go repo :(
The issue vscode-go issue 100 "debug: support function calls via delve 'call'" just got closed with PR 101 and commit 5a7752c / CL 249377 Delve supports function calls. Even though it is still experimental and can be applied only to a limited set of functions, this is a useful feature, many vscode-go users long for. Unlike other javascript/typescript debuggers, delve treats function calls specially and requires different call paths than usual expression evaluation. That is because Go is a compiled, runtime-managed GC language, calling a function safely from debugger is complex. DAP and VS Code UI does not distinguish function calls and other expression evaluation either, so we have to implement this in the same evaluateRequest context. We use a heuristic to guess which route (call or expression evaluation) we need to take based on evaluateRequest's request. This is part of the 0.17.0 milestone, yet to be released, and available for now in the nightly build.
Is it possible to read an SRML error message in Substrate UI, when a transaction fails?
I am not sure of the behaviour of error messages in Substrate runtimes in relation to Substrate UI, and if they inherently cause a transaction failure or not. For example in the democracy SRML I see the following line: ensure!(!<Cancellations<T>>::exists(h), "cannot cancel the same proposal twice"); Which presumably is a macro that ensures that the transaction fails or stops processing if the h (the proposal hash) already exists. There is clearly a message associated with this error. Am I right to assume that the transaction fails (without the rest of the SRML code being executed) when this test fails? If so, how do I detect the failure in Substrate UI, and possibly see the message itself? If not, then presumably some further code is necessary in the runtime module which explicitly creates an error. I have seen Err() - but not in conjunction with ensure!()
As https://github.com/paritytech/substrate/pull/3433 is merged, the ExtrinsicFailed event now includes a DispatchError, which will provide additional error code.
There isn't much documentations available so I will just use system module as example.
First you need to decl_error, note the error variants can only be simple C like enum
https://github.com/paritytech/substrate/blob/5420de3face1349a97eb954ae71c5b0b940c31de/srml/system/src/lib.rs#L334
decl_error! {
/// Error for the System module
pub enum Error {
BadSignature,
BlockFull,
RequireSignedOrigin,
RequireRootOrigin,
RequireNoOrigin,
}
}
Then you need to associate the declared Error type
https://github.com/paritytech/substrate/blob/5420de3face1349a97eb954ae71c5b0b940c31de/srml/system/src/lib.rs#L253
decl_module! {
pub struct Module<T: Trait> for enum Call where origin: T::Origin {
type Error = Error;
Then you can just return your Error in dispatch calls when things failed
https://github.com/paritytech/substrate/blob/5420de3face1349a97eb954ae71c5b0b940c31de/srml/system/src/lib.rs#L543
pub fn ensure_root<OuterOrigin, AccountId>(o: OuterOrigin) -> Result<(), Error>
where OuterOrigin: Into<Result<RawOrigin<AccountId>, OuterOrigin>>
{
match o.into() {
Ok(RawOrigin::Root) => Ok(()),
_ => Err(Error::RequireRootOrigin),
}
}
Right now you will only able to see a two numbers, module index and error code from JS side. Later there could be support to include the error details in metadata so that frontend will be able to provide a better response.
Related issue:
https://github.com/paritytech/substrate/issues/2954
The ensure! macro is expaneded as:
#[macro_export]
macro_rules! fail {
( $y:expr ) => {{
return Err($y);
}}
}
#[macro_export]
macro_rules! ensure {
( $x:expr, $y:expr ) => {{
if !$x {
$crate::fail!($y);
}
}}
}
So basically, it's just a quicker way to return Err. At 1.0, the error msg will only be printed to stdout(at least what I've tested so far), doesn't know if it'll be included in blockchain in the future(so can be viewed in substrate ui)..
react-i18next cannot resolve key
I have a problem with react-i18next not resolving my keys, so everything I get as an output are the keys themself.
I had to embed my project as gui project to a VisualStudio solution. Running my original project works just fine, the solution project in contrast cannot resolve the key part of my translate function call.
t('user:KEY_CONSTANT') //output: KEY_CONSTANT
My i18n.config looks like this:
i18n
.use(XHR)
.init({
lng: i18nHelper.languageDetector(),
load: 'currentOnly',
fallbackLng: 'en-US',
backend: {
loadPath: 'i18n/{{lng}}/{{ns}}.json'
},
ns: ['admin', 'user'],
defaultNS: 'admin',
debug: false,
interpolation: {
escapeValue: false,
formatSeparator: ',',
format: function (vale, format, lng) {
if (format === 'uppercase') return value.toUpperCase();
return value;
}
}
});
When embedding the project in the solution, I had to change webpacks output folder, which I think is the actual reason of malfunctioning, but I can't find where exact the problem occurs. I tried changing the loadPath, but if thats the source of failure, I just didn't try it the right way :S
My project tree looks like:
Solution
|-gui
| |-src
| |-i18n
| |-de-DE(containing the german admin.json and user.json files)
| |-en-US(containing the english admin.json and user.json files)
| |-utils
| |-i18n.js
|-out
| |-prgFiles
| |-html
| |-i18n(contains same items as i18n under src)
In my old project, the webpack output was '/dist/' on the same level as src, in the solution, '../out/prgFiles/html'.
admin.json right now contains no keys at all, user.json contains the keys just like you'd expect:
{
"KEY_CONSTANT": "Actual string value"
}
As said, I tried around a bit with path changes, checked for translate, i18next and i18next-Provider beeing found and everythings fine. It just cant resolve KEY_CONSTANT to the actual value.
Do you have an idea what the problem might be?
set debug option to true in i18next init -> i bet you will get an error stating something like backendConnector failed to load namespace user... make sure the clientside is able to load the translations (the webpack-dev server does a good job in doing so - but in production you will need to serve those file yourself)
Forcing a package's function to use user-provided function
I'm running into a problem with the MNP package which I've traced to an unfortunate call to deparse (whose maximum width is limited to 500 characters).
Background (easily skippable if you're bored)
Because mnp uses a somewhat idiosyncratic syntax to allow for varying choice sets (you include cbind(choiceA,choiceB,...) in the formula definition), the left hand side of my formula call is 1700 characters or so when model.matrix.default calls deparse on it. Since deparse supports a maximum width.cutoff of 500 characters, the sapply(attr(t, "variables"), deparse, width.cutoff = 500)[-1L] line in model.matrix.default has as its first element:
[1] "cbind(plan1, plan2, plan3, plan4, plan5, plan6, plan7, plan8, plan9, plan10, plan11, plan12, plan13, plan14, plan15, plan16, plan17, plan18, plan19, plan20, plan21, plan22, plan23, plan24, plan25, plan26, plan27, plan28, plan29, plan30, plan31, plan32, plan33, plan34, plan35, plan36, plan37, plan38, plan39, plan40, plan41, plan42, plan43, plan44, plan45, plan46, plan47, plan48, plan49, plan50, plan51, plan52, plan53, plan54, plan55, plan56, plan57, plan58, plan59, plan60, plan61, plan62, plan63, "
[2] " plan64, plan65, plan66, plan67, plan68, plan69, plan70, plan71, plan72, plan73, plan74, plan75, plan76, plan77, plan78, plan79, plan80, plan81, plan82, plan83, plan84, plan85, plan86, plan87, plan88, plan89, plan90, plan91, plan92, plan93, plan94, plan95, plan96, plan97, plan98, plan99, plan100, plan101, plan102, plan103, plan104, plan105, plan106, plan107, plan108, plan109, plan110, plan111, plan112, plan113, plan114, plan115, plan116, plan117, plan118, plan119, plan120, plan121, plan122, plan123, "
[3] " plan124, plan125, plan126, plan127, plan128, plan129, plan130, plan131, plan132, plan133, plan134, plan135, plan136, plan137, plan138, plan139, plan140, plan141, plan142, plan143, plan144, plan145, plan146, plan147, plan148, plan149, plan150, plan151, plan152, plan153, plan154, plan155, plan156, plan157, plan158, plan159, plan160, plan161, plan162, plan163, plan164, plan165, plan166, plan167, plan168, plan169, plan170, plan171, plan172, plan173, plan174, plan175, plan176, plan177, plan178, plan179, "
[4] " plan180, plan181, plan182, plan183, plan184, plan185, plan186, plan187, plan188, plan189, plan190, plan191, plan192, plan193, plan194, plan195, plan196, plan197, plan198, plan199, plan200, plan201, plan202, plan203, plan204, plan205, plan206, plan207, plan208, plan209, plan210, plan211, plan212, plan213, plan214, plan215, plan216, plan217, plan218, plan219, plan220, plan221, plan222, plan223, plan224, plan225, plan226, plan227, plan228, plan229, plan230, plan231, plan232, plan233, plan234, plan235, "
[5] " plan236, plan237, plan238, plan239, plan240, plan241, plan242, plan243, plan244, plan245, plan246, plan247, plan248, plan249, plan250, plan251, plan252, plan253, plan254, plan255, plan256, plan257, plan258, plan259, plan260, plan261, plan262, plan263, plan264, plan265, plan266, plan267, plan268, plan269, plan270, plan271, plan272, plan273, plan274, plan275, plan276, plan277, plan278, plan279, plan280, plan281, plan282, plan283, plan284, plan285, plan286, plan287, plan288, plan289, plan290, plan291, "
[6] " plan292, plan293, plan294, plan295, plan296, plan297, plan298, plan299, plan300, plan301, plan302, plan303, plan304, plan305, plan306, plan307, plan308, plan309, plan310, plan311, plan312, plan313)"
When model.matrix.default tests this against the variables in the data.frame, it returns an error.
The problem
To get around this, I've written a new deparse function:
deparse <- function (expr, width.cutoff = 60L, backtick = mode(expr) %in%
c("call", "expression", "(", "function"), control = c("keepInteger",
"showAttributes", "keepNA"), nlines = -1L) {
ret <- .Internal(deparse(expr, width.cutoff, backtick, .deparseOpts(control), nlines))
paste0(ret,collapse="")
}
However, when I run mnp again and step through, it returns the same error for the same reason (base::deparse is being run, not my deparse).
This is somewhat surprising to me, as what I expect is more typified by this example, where the user-defined function temporarily over-writes the base function:
> print <- function() {
+ cat("user-defined print ran\n")
+ }
> print()
user-defined print ran
I realize the right way to solve this problem is to rewrite model.matrix.default, but as a tool for debugging I'm curious how to force it to use my deparse and why the anticipated (by me) behavior is not happening here.
The functions fixInNamespace and assignInNamespace are provided to allow editing of existing functions. You could try ... but I will not since mucking with deparse looks too dangerous:
assignInNamespace("deparse",
function (expr, width.cutoff = 60L, backtick = mode(expr) %in%
c("call", "expression", "(", "function"), control = c("keepInteger",
"showAttributes", "keepNA"), nlines = -1L) {
ret <- .Internal(deparse(expr, width.cutoff, backtick, .deparseOpts(control), nlines))
paste0(ret,collapse="")
} , "base")
There is an indication on the help page that the use of such functions has restrictions and I would not be surprised that such core function might have additional layers of protection. Since it works via side-effect, you should not need to assign the result.
This is how packages with namespaces search for functions, as described in Section 1.6, Package Namespaces of Writing R Extensions Namespaces are sealed once they are loaded. Sealing means that imports and exports cannot be changed and that internal variable bindings cannot be changed. Sealing allows a simpler implementation strategy for the namespace mechanism. Sealing also allows code analysis and compilation tools to accurately identify the definition corresponding to a global variable reference in a function body. The namespace controls the search strategy for variables used by functions in the package. If not found locally, R searches the package namespace first, then the imports, then the base namespace and then the normal search path.