Document constraints in JSDoc - jsdoc

I have a function which is a React component. The element it creates has position:absolute; In order for this property to work in a predictable way the parent element should be positioned with position: relatieve;. I would like to let future users of this component to know about this constraint. Is there a JSDoc tag for such a purpose? How would you let users of this component know about this important constraint?

You need to highlight that your component has a run-time dependency on a particular external state. There is no specific jsdoc tag for this, you'd need to document it in the description.
In jsdoc2md you can declare any arbitrary tag, if that helps - you could invent your own tag to document it.
Custom tag example:
/**
* This function has a wonderful custom tag
* #createdIn Nigeria
*/
function customTaggedFunction () {}
Produces this output:
customTaggedFunction()
This function has a wonderful custom tag
Kind: global function
Createdin: Nigeria

Related

Doxygen: extract specific doxygen defines into separate documentaion

I have some source code (STM32 Peripherial Lib) with existing doxygen parameters which my Doxygen Builds without Problems.
For my project I want to generate a document with all functions in each file and a specific information which I want to add to the functions. But I want to keep the old informations for another doxygen configuration.
Is that possible?
I already added this for testing:
\ifnot "SECTION_DEFINE"
<normal Doxygen Parameters from original Source Code>
\elsif "SECTION_DEFINE"
#brief Function Check TODO
\endif
With this I could deactivate the existing documentation, but I need to write this \ifnot \elsif \endif to every function.
Can I just declare a Tag and only generate the documentation for this specific tag?
Kind regards
Andi
You may create a "related page" where only your additional information will be displayed with the \xrefitem command. As \xrefitem will also create a special text section within your original documentation you may want to combine it with your original idea of using section labels and conditional documentation. To top this concept off, use aliases in order to make your documentation more readable.
Consider this example code:
/** ST documentation
* foobar
* \exclusive for andi's function \endif
*/
void andreas(void);
/** ST documentation
* foobar
* \exclusive for beni's function \endif
*/
void benjamin(void);
You may use this alias in your Doxyfile: exclusive=\if SECTION_DEFINE \xrefitem viparea "Exclusive" "VIPs".
As long as SECTION_DEFINE is not defined, the "exclusive" information will not be included in your documentation. As soon as this section is defined, a "related page" (here: viparea.html) is created in your HTML documentation containing your documented items (here: andreas and benjamin) with the exclusive paragraph behind the command. The result:

AEM 6.0: Additional parameters when using data-sly-resource?

I am trying to implement something which I hope is relatively straight forward... I have one component (lets call it the wrapper component) which contains another component (lets call it the inner component) inside it via the data-sly-resource tag:
<div data-sly-resource="${ 'inner' # resourceType='/projectname/components/inner' }"></div>
I would like to pass in some additional parameters with this tag, specifically a parameter that can be picked up by sightly in the inner component template? I am trying to specify whether the inner templates outer html tag is unwrapped based on a parameter being passed in when the component is called via data-sly-resource.
After experimenting and perusing the sightly documentation, I can't find a way of achieving this.
Does anyone know if this is possible?
Many thanks,
Dave
You can use the Use-API to write and read request attributes if the alternatives proposed here don't work for you.
A quick example of two components where the outer component sets attributes that are then displayed by the inner component:
/apps/siteName/components/
outer/ [cq:Component]
outer.html
inner/ [cq:Component]
inner.html
utils/ [nt:folder]
setAttributes.js
getAttributes.js
/content/outer/ [sling:resourceType=siteName/components/outer]
inner [sling:resourceType=siteName/components/inner]
/apps/siteName/components/outer/outer.html:
<h1>Outer</h1>
<div data-sly-use="${'../utils/setAttributes.js' # foo = 1, bar = 2}"
data-sly-resource="inner"></div>
/apps/siteName/components/inner/inner.html:
<h1>Inner</h1>
<dl data-sly-use.attrs="${'../utils/getAttributes.js' # names = ['foo', 'bar']}"
data-sly-list="${attrs}">
<dt>${item}</dt> <dd>${attrs[item]}</dd>
</dl>
/apps/siteName/components/utils/setAttributes.js:
use(function () {
var i;
for (i in this) {
request.setAttribute(i, this[i]);
}
});
/apps/siteName/components/utils/getAttributes.js:
use(function () {
var o = {}, i, l, name;
for (i = 0, l = this.names.length; i < l; i += 1) {
name = this.names[i];
o[name] = request.getAttribute(name);
}
return o;
});
Resulting output when accessing /content/outer.html:
<h1>Outer</h1>
<div>
<h1>Inner</h1>
<dl>
<dt>bar</dt> <dd>2</dd>
<dt>foo</dt> <dd>1</dd>
</dl>
</div>
As commented by #AlasdairMcLeay, this proposed solution has an issue in case the inner component is included multiple times on the request: the subsequent instances of the component would still see the attributes set initially.
This could be solved by removing the attributes at the moment when they are accessed (in getAttributes.js). But this would then again be a problem in case the inner component is split into multiple Sightly (or JSP) files that all need access to these attributes, because the first file that accesses the request attributes would also remove them.
This could be further worked-around with a flag telling wether the attributes should be removed or not when accessing them... But it also shows why using request attributes is not a good pattern, as it basically consists in using global variables as a way to communicate among components. So consider this as a work-around if the other two solutions proposed here are not an option.
There is a newer feature that request-attributes can be set on data-sly-include and data-sly-resource :
<sly data-sly-include="${ 'something.html' # requestAttributes=amapofattributes}" />
Unfortunately it doesn't seem to be possible to construct a Map with HTL (=Sightly) expressions, and I don't see a way to read a request attribute from HTL, so you still need some Java/Js code for that.
unfortunately, no. there is no way to extend sightly functionality. you cannot add new data-sly attributes or modify existing ones. The best you can do is write your own helper using the USE API
If you just need to wrap or unwrap the html from your inner component in different situations, then you can just keep the html in the component unwrapped, and wrap it only when needed by using the syntax:
<div data-sly-resource="${ 'inner' # resourceType='/projectname/components/inner', decorationTagName='div', cssClassName='someClassName'}"></div>
If you need more complex logic, and you need to pass a value to your inner component template, you can use the selectors. The syntax for including the resource with selectors is:
<div data-sly-resource="${ 'inner' # resourceType='/projectname/components/inner', selectors='mySelectorName'}"></div>
The syntax to check the selectors in the inner component is:
${'mySelectorName' in request.requestPathInfo.selectorString}"
or
${'mySelectorName' == request.requestPathInfo.selectorString}"

GTM Reduce number of tags

GTM up and running, main UA tag in place along with a ClickListener tag.
To reduce the number of macros, i use dataLayer variable Macros for event category, action, label, value & interaction, so they can be used for many rules and tags.
So i want to collect data from one link/button (Add to Fav), i add a rule to listen for the click using {{event}} equals gtm.click and {{Event Label}} equals Add_to_Fav (the label i push to the DL via onclick.
All good so far, but i need to create another UA tag (Track Type - event) that fires on the rule made previously. And this is my question, using this method seems to create many tags. If i have another 20 links that i want to collect data from, do i need to keep creating tags like this. Surely, this will affect page load speed with many tags firing on all pages.
Hope thats all clear.
If you need to retrieve the link text to use it as an event label you do not need many many event tracking tags, that would be horribly verbose. Instead you can use a custom javascript macro - the cool thing about them being that you can use existing macros inside your custom function.
If you create a click listener or link click listener this will create a few macros - one of them is {{element}}, which is the DOM element that received a click.
Now you create a macro of the type "custom java script", which must contain an anonymous function with a return value.
The barebones version of a function that retrieves the text of a clicked link would be
function() {
var el = {{element}};
return el.innerText;
}
(actually you do not need the variable assigment, you could use {{element}}.innerText directly).
You name the macro e.g. Linktext and use the macro {{Linktext}} in your single event tracking tag where it will dynamically be set to the value of the text of the clicked link (although you might want to check cross browser support for innerText, or maybe use innerHTML instead which serves in you use case probably the same purpose).

Symfony 1.4 - are forms always in <table>?

I'm using sfDoctrineAllowPlugin. I need form which has Twitter's Bootstrap semantics. I looked into template and I found, that there is only $form, which is a <table>. How can I format it in my way? I don't want to use table, rows and cols.
There are plenty of render* functions available to display each item in your form.
renderRow
renderLabel
render
renderError
etc ...
But you can also define a decorator (a custom sfWidgetFormSchemaFormatter) for your form to define the way each item will be display. Check this example of adding * for each required field.

Wicket - can you specify markups IDs for elements inside repeaters?

I'm having a hard time testing our Wicket application using Selenium because of the random markup ids.
For individual elements, I can use abc.setOutputMarkupId(true).setMarkupId("myId")
to set their markup id explicitly.
But what if the element is added dynamically using a repeater (like ListView)? Is there a way to specify how the markup id sequence should look like?
Well, can't you do the same thing with ListView? If you make your own ListView implementation, and then in the populateItem(final ListItem<?> listItem) method, on that respective listItem you do:
listItem.setOutputMarkupId(true); // write id attribute of element to html
listItem.setMarkupId("id"+i);
where i is some index you initialize in the ListView's constructor or something?
as Andrei told that its possible but dangerous.
setMarkupId doc:
Retrieves id by which this component is represented within the markup. This is either the id attribute set explicitly via a call to
org.apache.wicket.Component.setMarkupId(java.lang.String), id
attribute defined in the markup, or an automatically generated id - in
that order. If no explicit id is set this function will generate an id
value that will be unique in the page. This is the preferred way as
there is no chance of id collision.
http://www.kiwidoc.com/java/l/p/org.apache.wicket/wicket/1.4.0/p/org.apache.wicket/c/Component#top
and also you cant get the markup id with getMarkupId()