When using TemplaVoila, the template data structure is mapped to the HTML template file by pathes like
body[1]/INNER|div.grey[1] div.content_area[1] div.left_column[1] div.left_content[1]
while this is obviously as precise as possible, it is not very effective, because every change to an DOM element above the mapped one would break the mapping, which happens quite frequently and is totally pointless. I like to patch TemplaVoila to rely on the last matching path segments only, which will suffice in almost any condition, as my HTML is always tagged by id's or classes on the mapped elements.
For the start, it would be cool if it would maybe just use
.left_content[1]
instead of the path shown above. But maybe it don't work in a matching fashion like CSS selectors do.
I just can't figure out where to start. Can this be done by TS config? Are changes to TemplaVoila's PHP needed? Can a new extension do this?
Add an unique class or even better id to the desired element, so you won't need to count the occurrences. TemplaVoila hasn't possibility to use CSS-like selectors first, last etc.
The mapping does not rely on the full path, but tag name and id, if the element mapped has an id attribute set.
Having an (even unique) class attribute only forces TemplaVoila to map the absolute element path, as classes are not necessarily unique.
So no special configuration is needed, if all mapped elements have unique id attributes set.
Related
While idly browsing the DOM specification, I came upon this passage:
Elements have an associated namespace, namespace prefix, local name, custom element state, custom element definition, is value. When an element is created, all of these values are initialized.
Looking at other parts of the specification, I learned that it is apparently supposed to be a string value or null. However, I have not been able to find out what is it actually supposed to be used for.
Of what use is this concept?
The common way to write the TypoScript is in Configuration/TypoScript/setup.txt.
But there also two other way to write TS. One with ext_typoscript_setup.txt and other with ExtensionManagementUtility::addTypoScriptSetup().
Can someone explain me what the difference is and when should i use which one?
Theoretically the usage of ext_typoscript_setup.txt files has been deprecated. Theoretically because it has never really been removed from the core.
ext_typoscript_setup.txt and ExtensionManagementUtility::addTypoScriptSetup() do quite the same thing as those will always load the given TypoScript. However the problem is that sometimes people have a hard time overriding those default code. To make it even more complicated there is the select field Static Template Files from TYPO3 Extensions inside the sys_template record which can influence the order.
As a solution (or at least how I handle it):
Always use the way of having TS in Configuration/TypoScript/... and let the integrator decide how and in which order it is included. Some people include TypoScript within their SitePackage, some in sys_template record, ...
However I also use ext_typoscript_setup.txt in rare case if some TS must be available and which won't be changed by an integrator.
Whenever a part of a language label needs to be somehow highlighted, what is considered as best practice here?
I'm usually trying to avoid html tags in language labels as far as possible by splitting label into a parts and wrapping into corresponding tags in Fluid.
In worst case label is wrapped with CDATA:
<trans-unit id="my.label">
<source><![CDATA[Here comes a <strong>bold text</strong> and then <em>italic</em> and now <span class="fancy">fancy styled</span> stop]]></source>
</trans-unit>
But this mixes content and presentation, which can bring pain afterwards, when CSS is refactored and some classes are renamed.
Another solution, coming into my mind, is to move all the texts, that may contain html tags, out of XLF to either plugin's FlexForm RTE field or some configuration record with RTE fields. But it also looks rather like hack.
How do you solve such an issue usually?
For me there are some possible options, depending on the kind of text.
1.) Avoid HTML as much as possible
2.) If this HTML is wrapped around any arguments, move the HTML out and use it as argument for the <f:translate /> ViewHelper.
3.) Sometimes it is hard to use arguments as the translation is just different and I then use different partials/sections for the different languages and don't use any language file.
4.) I use the CDATA approach.
An addition to Georg Ringer's answer (whose point 1 is definitely the way to go, if at all possible):
5.) Use what XLIFF offers. XLIFF 1.2 has elements to mark tags inside translatable content - to be precise, it has too many such elements. One possible representation of your example would be
<trans-unit id="my.label">
<source>Here comes a <bpt id="1"><strong></bpt>bold text<ept id="1"></strong></ept> and then <bpt id="2"><em></bpt>italic<ept id="2"></em></ept> and now <bpt id="3"><span class="fancy"></bpt>fancy styled<ept id="3"><span></ept> stop</source>
</trans-unit>
This looks messy in code, but it has the advantage that an XLIFF aware translation editor will present this to your translators in a way that is easy for them to work with, like this:
.
The translator will be able to move these tags if the text order needs to be changed in the target language, and they can delete these purple tags in whole if they don't make sense in the target language: for example some complex Chinese characters look awful in bold face. They will not be able to delete parts of tags either.
One possible solution could be the use of parameters in the translation strings. Those parameters could be filled with translated strings which are wrapped in tags (by TS or fluid). This might result in a very complex translation handling as the strings are broken down to multiple strings (which might partially loose context).
Another solution could be the use of markers (like ###B### for <b>and ###_B### for </b>) for the tags which are replaced at the end (and which could vary for different devices). This also is complex and needs a good configuration and invents something like a further markup.
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.
I see some posts on this same issue but would like further clarification as I cannot get any of these answer to work especially as I can't pick the answer out of the Jquery documentation.
I want to combine some classes for the convenience of cascading appropriate styling. I could simply replicate the styling in a single class but I am assuming that that would be bad practice.
<div class="left_Item drop_Down" id="col_1">some stuff</div>
$(".left_Item, .drop_Down#col_1").whatever....;
// matches every occurrence of class left_Item with the single occurrence of //drop_Down#col_1 ... this tallies with the multiple selector documentation.
$("#col_1").whatever....;
//obviously does match as the selector is only looking at the id.
//however
$(".drop_Down#col_1").whatever....;
//does not match Does this imply that the classes cannot be matched separately? So....
$(".left_Item.drop_Down#col_1").whatever....;
// various posts on so state that this should match it does not for me. Nor does
$(".left_Item .drop_Down#col_1").whatever....;
$(".left_Item").filter(".drop_Down#col_1).whatever....;
// various posts on so state that this should match also but it does not for me.
So firstly I assume that I am doing the correct thing using multiple classes. If not I'll stop trying to make this work!
Secondly please can some one give the correct jquery syntax to match an element with multiple classes.
Thx
The syntax is as follows (for CSS or jQuery):
.class1.class2
In your case:
$(".left_Item.drop_Down").whatever...
If you want to use an id as well as a class selector, then put the id first:
$("#col_1.left_Item.drop_Down")
Though since ids are supposed to be unique, I don't understand why you don't just use $("#col_1")
If the classes are your main focus then try this.
$('.left_Item.drop_Down').whatever...
But if you want an Id that has classes left_Item drop_Down you might do this
$('#col_1.left_Item.drop_Down').whatever...