Data within assemble markdown helper? - assemble

I’ve been using assemble (v0.24.3) for a while now and have just noticed that a feature that previously worked now appears not to - namely being able to put data (such as {{title}}) inside of the markdown helper that assemble provides.
Is there a way to do this in the latest version of assemble?
As a use case - I used to use this to prefix site urls with a certain strings when pushing to github pages, as it needed a slightly more specific base url path, but now that data variable just looks like it gets ignored when rendered.

handlebars will create a new "scope" or "depth" when the context inside a block helper is different than the surrounding context. In newer versions of assemble, the context is added from assemble data for use inside block helpers, which causes handlebars to create a new depth. To ensure that you're using the "parent" depth from inside the block helper, you should use the {{../}} syntax:
{{#markdown}}
# {{../title}}
{{/markdown}}

Related

Sorting methods (by number of arguments) using JetBrains Rider File Layout

I'm using Unity/C# and I try to setup Rider File Layout XML to format code in specific way.
What I want - is to put methods with certain names (e.g. Awake(), Start(), Update() etc.) in front of other methods.
The important part is that I want to move only methods without arguments.
Sorting by name partially works, but it also changes order of methods with parameters (e.g. Update(float dt)).
Is there any way to filter methods with and without parameters using File Layout?
I'm afraid that's not possible, probably you have to write your own R# plugin for this

itextpdf : MarkedObject use

What is the interest of using MarkedObject in itext pdf ?
Show a main use example please. There is only javadoc on the net related to this object.
The MarkedObject class was introduced to allow developers to add attributes to an object when creating XML or HTML. For instance: when you created HTML, you could add an id or class attribute. This use case has disappeared in 2009 when we removed XML and HTML generation from iText.
We thought it could also be used in the context of PDF, more specifically in the context of generating PDF/A. However, we decided to create PDF/A in a difference way, using the IAccessibleElement interface. If you check the API docs, you see that this interface also defines methods to set and get attributes.
In short: you can safely ignore the MarkedObject class: it is no longer used. Writing a "main use example" would be a waste of time.

How to properly check selectors and extensions via RequestPathInfo

I've been working on a component and currently I'm trying to do different things based on the selector chosen for the component.
So basically if I have a component with this structure
myComponent/
dialog.xml
myComponent.jsp
altView.jsp
I know that if I have a Node with resourceType myComponent I can request the alt view via browser by requesting "path/to/component/content.altView.html" and everything is hunky dory.
Similarly I can do a cq include and do something like:
# with cq include
<cq:include path="my/path.altView" resourceType="myComponent"/>
# or with sling include
<sling:include path="my/path" resourceType="myComponent" replaceSelectors="altView"/>
However, when I'm handling the request, I've seen some interesting behavior when looking at the RequestPathInfo Object.
For example, if we look at all 3 of the above cases I might have something like this:
# http://path/to/component/content.altView.html
slingRequest.getRequestPathInfo().getSelectors(); // {altView}
slingRequest.getRequestPathInfo().getExtension(); // html
# <sling:include path="my/path" resourceType="myComponent" replaceSelectors="altView"/>
slingRequest.getRequestPathInfo().getSelectors(); // {altView}
slingRequest.getRequestPathInfo().getExtension(); // html
# <cq:include path="my/path.altView" resourceType="myComponent"/>
slingRequest.getRequestPathInfo().getSelectors(); // []
slingRequest.getRequestPathInfo().getExtension(); // altView
I understand why the cq:include returns different results (we're making a request to my/path.altView and .altView coincidentally serves as the extension in this case). I'm curious if there is a normalized why to pull "altView" (or the selected view) regardless of if it's been used as an extension or selector. Or if this is normal and I just need to check both the extensions and selectors individually.
i.e
selectors = get selectors();
if selectors
do stuff
else check extensions
do stuff
Again thank you very much for your insights, this community is awesome.
[EDIT]
In response to an answer, I thought I'd give a little more context to what I'm doing. Basically our component structure is set up so that each of our components has an associated Java Class that handles the business logic. (I.E. apps/myapp/components/myComponent will map to com.mypackage.components.MyComponent) That said, within my component's Class I need to handle the control flow differently depending on how the component was called (i.e. what selectors/extensions/etc). For example, if my component was called normally I'd do the base behavior, but if it was called with selector (for exmaple) "altView" I would need to handle the alternative view differently, and in this alternative view different data will be available, etc.
My question was along the basis that it seems that i can give the "path" attribute of a "cq:include" tag the selector I want to use:
<cq:include path="my/path.altView" resourceType="myComponent"/>
However, when I check my RequestPathInfo in my component class to decide workflow, "altView" is returned as the extension, not within the String[] selectors. Note, the above compiles fine, and it selectors the correct .jsp file for rendering, the RequestPathInfo object just stores the data in a different place.
I'm starting to guess that places the selector into the path attribute works because the selectors and extensions modifiers alter the behavior vary similarly. mycomponent.altView.html resolves to altView.jsp whereas if I was to do mycomponent.altView it would also attempt to resolve a mycomponent/altView.jsp just as it would do the same for mycomponent.xml to mycomponent/XML.jsp
It seems like you're kind of working around Sling resolution. The easiest way to do "different things based on selector" in a given component (let's say my/new/component) is to create different renderers.
For example, say I am requesting /content/app/page.html, and on that page was the component my/new/component. Or if I request /content/app/page.selector.html, I want a slightly different experience for my/new/component.
In the cq:component, I would create two JSPs: component.jsp and component.selector.jsp. Sling will automatically know, based on the selector in the request, which renderer to use. Obviously each renderer can produce a different experience.
The same is true for extension. In the example, component.jsp and component.selector.jsp are actually equivalent to component.HTML.jsp and component.selector.HTML.jsp. The HTML is just implied. However, you could do component.XML.jsp and component.selector.XML.jsp and Sling will again, pick the most relevant selector, based on the selector(s) and extension of the request.
Now, what if you don't want the selector to show up in the page request's URL (in my opinion you shouldn't)...
You can include your component using sling:include and add the selector, like you've done.
The caveat is that sling:include works a little differently than cq:include, so only use this when you need to. Instead, you could also use Sling mapping to hide the selector from the user. The majority of the time I would recommend this approach.
I'm not sure what you were trying to do with adding the selector to the "path" attribute. I don't think that would do anything. The "path" is defining the resource name (and the node name if the resource is not synthetic). Including the selector in that wouldn't do anything, except make the resource name include a period and the selector.
My question was along the basis that it seems that i can give the
"path" attribute of a "cq:include" tag the selector I want to use:
<cq:include path="my/path.altView" resourceType="myComponent"/> However, when I check my RequestPathInfo in my component class to
decide workflow, "altView" is returned as the extension, not within
the String[] selectors.
As opposed to the cq:include tag, you could alternatively use sling:include tag, which provides attributes to modify the selectors & suffix on the request:
<sling:include resourceType="myComponent" path="my/path" addSelectors="altView"/>
or
<sling:include resourceType="myComponent" path="my/path" replaceSelectors="altView"/>
If you already have selectors on the request that you don't want to apply to myComponent.
In terms of the differences between Sling include & CQ include, there seems to be very little, apart from the latter also supporting script inclusion. From the docs:
Should you use <cq:include> or <sling:include>?
When developing AEM components, Adobe recommends that you use
<cq:include>.
<cq:include> allows you to directly include script files
by their name when using the script attribute. This takes component
and resource type inheritance into account, and is often simpler than
strict adherence to Sling's script resolution using selectors and
extensions.

Is it possible to reuse flexform field definitions using EXT:flux?

I'm new to the fedext-universe. By now, I've created a set of content elements, and they work fine.
There is one drawback though: One set of content elements has some fields in common, and these fields are rather complicated. Usually, I'd move their definition to a partial, but that isn't possible in flux forms. The beginners guide states
Flux templates can use Layouts and
Partials - but a Flux form cannot
be split into Partial templates.
Is there any way to avoid redefining these fields over and over again? Among other things, I've tried to use the <vhs:render.inline> viewhelper along with a custom viewhelper, returning the fluid-definition of the fields, but I can't get that to work.
Flux 7.0 will bring the option to place fields and sheets into Partial templates - if you are currently in a development project, I recommend trying it out from the development branches on Github:
https://github.com/FluidTYPO3/flux/tree/development
Flux 7.0 also will bring the option to create PHP classes which for example create ready-made sheets with a bunch of fields - such a class would be ideal to reuse, simply requiring one PHP class and one Fluid ViewHelper. Such an approach would be more efficient when your forms are rendered, but of course is much more technically demanding than a Partial template.
EDIT: though not yet documented, creating custom sheets involves two simple steps: 1) create a subclass of FluidTYPO3\Flux\Form\Container\Sheet and a subclass of FluidTYPO3\Flux\ViewHelpers\Form\SheetViewHelper - then include your namespace in the template, use your own ViewHelper instead of a flux:form.sheet (and add additional fields if you need them) and then inside the Sheet object, use the $this->createField() method from within object initialization, to automatically add any number of fields with predefined names, labels etc.

How do I associate a CoffeeScript file with a view?

Just installed rails 3.1 rc1 and am trying to grok the best way to manage javascript with the new asset pipeline
By default all coffeescript is compiled into a single application.js file, this is a good thing.
Each seperate coffee script file is appended to the js file and wrapped in an anonymous function which is executed via the call method
A common scenario would be to use some jquery to turn various forms into ajax forms, update UI, etc...
Many of these scripts will be specific to a controller or action, I am trying to grok the 'conventional' way to handle this,
since everything is wrapped in an anonymous function how do I only execute just
the code for a particular controller / action, by default all of the anonymous functions are being executed
I did play around with some hacks where I load the controller and action name into js variables and then in
coffeescript check those to conditionally run code, I don't like that very much
my initial thought was that each coffee file would contain a js namespace/object and I would call the specific ones from the view,
going to spike this using the default_bare = true configuration
see How can I use option "--bare" in Rails 3.1 for CoffeeScript?
EDIT
Looking around some more: this looks like it might be the correct approach - "Can't find variable" error with Rails 3.1 and Coffeescript
There are two common approaches:
Make behavior conditional on the presence of a particular element. For instance, code to run a signup sheet should be prefaced with something like
if $('#signup').length > 0
Make behavior conditional on a class on the body element. You can set the body class using ERB. This is often desirable for stylesheets as well. The code would be something like
if $('body').hasClass 'user'
gistyle is a simple gem that helps you running action-specific javascript codes.
By following its setup, you set some data attributes in your body element, representing the current controller and action names. Then it will only call that action when the corresponding view is loaded.