At the following link there is a cheatsheet for Adobe Experience Manager (AEM formerly CQ).
http://activecq.com/system/assets/46/original/quick-reference.html
There is a section on the page called "Component Organization"
At the bottom of the list are two sections: views and partials.
My first question is, what would the x and y represent and is there some built in mechanism that already exploits this convention?
If a page included content where this component was the resourceType and the appropriate selectors were in play then those x and y JSPs would also be in play. For instance,
/content/mysite/mypage.views.x.html
But that seems strange. A more likely scenario is that the component is targeted through a sling include that adds or replaces selectors.
<sling:include resourceType="/apps/myapp/components/sample"
replaceSelectors="views.x" />
So what is the intended usage of this feature?
I could be wrong, but I believe the partials folder is referring to this: https://github.com/Adobe-Consulting-Services/acs-aem-commons/issues/10
The idea seems to be to break up the component into inheritable sections for ease of use and development of siblings of the parent.
Related
rails 3.2
I am new to slim, and I have to work with an application that's using it. Reading through some documentation, I see that using something like:
.class
which translates to:
<div class="class"></div>
In the code I inherited, in the .html.slim file, I have:
.form-section.customer_info
When I look through the stylesheets folder, I cannot find customer_info, but I can find form-section.
Shouldn't I be able to find customer_info in one of the stylesheets?
The answer is maybe you can find it in a stylesheet. But there are other cases, where you may not:
Sometimes a class is used as a target for a JavaScript snippet; if you find it mentioned in the javascript for the app, then you likely want to keep it because an interaction may depend on it (read the JS code to determine this).
Sometimes, the class has been removed from the stylesheet and not removed from the code; in this case you may remove it.
However, sometimes a class is added to mark the section of HTML as semantically significant so that styling can be applied to it at a future time; in that case, you may choose to keep it.
For instance, for better or ill, when I am writing code, I will name sections using classes, as .user-list or .part-table to indicate that, as the coder, I know the HTML code is going to contain users or parts. By doing this consistently I can mark out portions of the front end for later consistent styling by usage; that is, all the part tables can be styled the same way, all the user lists can be styled the same way, etc. Again, this is a convention I have seen used and that I practice. Nonetheless, these represent a few reasons why a class may be present in the HTML, but not referenced elsewhere.
I have a problem using the filelist / upload element of TYPO3 at the current new version 7.6.2. I want to use the title or description part instead of the filename while rendering the list.
I found lots of information on that and in TYPO3 version 6.x it worked with:
tt_content.uploads.20.renderObj = COA
tt_content.uploads.20.renderObj.20.1.data = file:current:title
tt_content.uploads.20.renderObj.30 >
When I insert this lines into the TS of the page where I want to use the filelist it does not work with the new css_styled_content for 7.x.
When I include "CSS Styled Content TYPO3 v6.2 (css_styled_content)" to the setup of the template, the filelist works (but other parts of page not).
Therefore the question: Do you know if there are some changes in rendering the filelist at 7.x?
Thanks for your help
Markus
The reason why you can't change the name => title anymore is that you included Fluid Styled Content ext which is required i.e. for rendering the Text & Media CEtype. It massively overrides the CSS styled content and replaces (almost) whole TS declarations with Fluid templates/layouts/partials from typo3/sysext/fluid_styled_content/Resources/Private folder. I.e.: in typo3/sysext/fluid_styled_content/Resources/Private/Templates/Uploads.html:29 there is {file.name} used which should be more advanced condition...
To change it:
Copy all folders from typo3/sysext/fluid_styled_content/Resources/Private to your custom destination i.e.: fileadmin/fluid_styled_content/Private (this is for avoiding loosing of your changes after system upgrade.
It can be any other path, for an instance you can create your custom ext and put it into typo3conf/ext/yourext/Resources/Private/...
Go to your TypoScript template > Constant Editor > Category: Content and set new paths in these fields:
Path of Fluid Templates... - fileadmin/fluid_styled_content/Private/Templates
Path of Fluid Partials... - fileadmin/fluid_styled_content/Private/Partials
Path of Fluid Layouts... - fileadmin/fluid_styled_content/Private/Layouts
After that go to fileadmin/fluid_styled_content/Private/Templates/Uploads.html:29 and replace the code:
{file.name}
with:
<f:if condition="{file.title}"><f:then>{file.title}</f:then><f:else>{file.name}</f:else></f:if>
As you can see this way you can also change other CEtypes and their typical settings (i.e. add the responsive classes if working with RWD).
On the other hand take a look there are some drawbacks of this solution, i.e. default layouts repeats the <div id="c123">... which is invalid :/
P.S.:
Also just realized that Fluid Styled Content doesn't handle other things, i.e. different layouts for Uploads (that the first thing I saw, didn't check other CEtypes) so you need to consider yourself if it is OK for your project at the moment. I prefer to stay with old way (no need for Text & Media CE) and disable FSC now (I'm pretty sure, that soon it will be nice alternative for CSC, but not now imho :/) To revert typical state you can use these lines mentioned in the GitHub here within your PageTS.
I want to use chapters and chapter-menu as a e.g. image gallery, reference module or other collections in Typo3 Neos.
As there are multiple domains with different content in my installation i have a problem with the NodeTypes.yaml:
All my site packages are based on NeosDemoTypo3Org. Because i don't want to have multiple entries "chapter", "chapter menu", "youtube" and so on, i deleted the NodeTypes.yaml in my copies of NeosDemoTypo3Org (which is still installed).
When i add a page with content element "chapter menu" to a package and put some chapters in it, the chapter overview is only displayed, if am putting the NodeTypes.yaml back into my package configuration. But then again i have multiple entries of the same thing.
How/where can i configure this to fit my needs?
That should be no problem. Just having the Chapter etc. in one NodeTypes.yaml is enough for now (until we implemented separation per Site which we want to have at some point). But I guess you adapted all occurances of "TYPO3.NeosDemoTypo3Org" in your TypoScript to match the new package name? You need to of course change that back for everything that is related to those NodeTypes. The TypoScript must point to the correct name for this NodeType. And you have to declare the TypoScript in each package because TypoScript is NOT shared in contrast to the NodeTypes.
What you could do is create a "base package" that contains the NodeTypes and TypoScript (and Tempaltes for those) and include the TypoScript in each of your Site packages.
Intro:
I'm trying out LESS in an asp.net mvc environment.
I use dotless for server side processing (and I wouldn't want to use client side processing especially afer publishing the complete project).
I have to apply a design where there are different color schemes depending on different things (e.g. time of the day).
Less felt very powerful in this case as designing a parameterized css and only changing like 10 variables at the beginning of the file for every theme was really uplifting.
Problem:
But I would need to somehow change the color themes from an outside parameter.
Ideas:
First I thought that an URL parameter like style.less?theme=fuschia would be good, but I found no way to parse something like this.
Then I thought that making a very short blue.less, green.less, orange.less consisting only declared color variables, and including the main.less in every one of them would be a solid solution.
I had no chance to try out the second solution, but I thought this would be a good time to ask for advice on the most robust way of doing this.
The problem again is: I want to control some things in my less file from the outside.
Yes you can (because I implemented that feature for exactly that reason).
Dotless supports parameters from the outside via the querystring parameter.
<link rel="stylesheet" href="style.less?foo=bar" />
Will let you use the following less:
#foo = bar;
The parameter injection code is very simple. it just prepends the variable declarations to your normal less file, so anything that comes as a querystring parameter will follow the above syntax.
The code in question is very simple: https://github.com/dotless/dotless/blob/master/src/dotless.Core/Engine/ParameterDecorator.cs
AFAIK, you cannot pass parameters for dotnetless to use to do the compile.
As a suggestion, why not just call different less files? This would be fairly easy to do by using a Viewbag property.
To make the different less ones, You first create a less file with each set of colors in them. Then you import your base css file. dotnetless will merge the color definations in the parent file with the usages in the base file. So you have something like -
#baseGray: #ddd;
#baseGrayDark: darken(#baseGray, 15%);
#baseGrayLight: lighten(#baseGray, 10%);
#import "baseCss.less";
I just tested this on and MVC3 project and it works.
Recently I created a spike of a view engine, in which views are plain classes, and the content is created by using funny using-scope blocks.
The code together with a simple sample site is available at http://code.google.com/p/sharp-view-engine/
Here I'd like to hear your opinions regarding such an idea. Is it completely weird or maybe someone likes it?
I would actually not like that.
I can agree with DSLs (such as a Parser-Combinator or for generating XML Nodes in a data-context), but in this case I think that too much is being put in code that. And, in the end, this just complicates boundaries and leads to hard-to-maintain code. (You can already do the same, but with more verbosity just using the "standard" Web Controls. You can always use {subblock} in C# to limit a variables scope.)
The approach I prefer to use is templates with bindings (but no "code in templates"). That makes it easy for the "designer" (hopefully not me, or the next person to come along and) edit the layout of the view how they see fit. However, the core logic (the available controls and bindings) are kept in the code -- uncluttered. (Another advantage with the templates is that if they externally housed they do not require a recompile for every little change.)
Simplicity and maintainability are like ... zen.
This is an interesting idea taken to the extreme I'd say. At my shop we're using html conventions for pretty much everything except our layout. The only real html we have in the project is our Spark master page. For generating the content itself we use a convention engine that that spits out a semantic html model. (We're using the HtmlTags library from FubuMVC to build the semantic model.)
An example convention for rendering a multiline text box looks like:
public static HtmlTag Build(ElementRequest req)
{
return Tags.TextArea
.Rows(6)
.Id(req.ElementId)
.Attr("name", req.ElementId)
.Text(req.StringValue());
}
These conventions get triggered from reflecting on the view model (or we can manually call them from a helper method). The output is rendered (via ToString()) into the content section of our master page. We're joking that pretty soon we won't even need a view engine.
ps here's how we handle nesting. (Your using blocks look cluttered!)
return Tags.Div.Nest(
Tags.Button("save").AddClass("positive"),
Tags.Span.Text(" or "),
Tags.Anchor.Text("cancel").AddClass("negative")
);
Nest() is an extension method that simply takes a params array of HtmlTag and appends them to the parent's children collection.