I am using single clientlib for all the pages in my site. Only for one page, i need to exclude one css file from clientlib.
In this case, Should I create a different clientlib and a different template for that page ?
Or
Is there any other way to do this?
The contents of the clientlibs are determined by the css.txt and js.txt files, and these are just hard-coded lists. The clientlibs are assembled when the application is deployed so modifying their contents at run-time would be problematic.
So you are going to need multiple clientlibs to describe the two different lists of css files. Keep in mind that you can use "embeds", "depends", and "categories" relationships to make referencing them easier. Imagine two simple client libs named A and B - A contains A.css and B contains B.css.
Now imagine I have two web pages: Cats.html and Dogs.html. Cats needs both style sheets, but Dogs only needs B.css. To achieve this, I can give clientlib A a category of just "cats" and clientlib B a category of both "cats" and "dogs".
This way when I get my clientlibs for the Cats page using category "cats", I'll get both style sheets. And when I use category "dogs", I will only get B.css.
There is a good explanation here: http://blogs.adobe.com/experiencedelivers/experience-management/clientlibs-explained-example/
Related
I'm currently looking for a way to capture only svelte components on the DOM tree during development mode. I can see that we I run npm run dev all elements and conponents have the "class='svelte-somerandomID'". Does this only happen in development mode?
Yes, it's only in during development that all elements get a scoping class -- and only with some tools. Actually it's a hack we've added in vite-plugin-svelte to enable more power CSS only HMR.
The classes you're referring to are what Svelte uses to make the CSS in a component apply only to the elements of this component. It adds a class that is unique to the component to all elements that can be affected by the component's CSS, and it also modifies your CSS rules to add the same class to them.
Normally the compiler only adds the scoping class to elements that can actually be targeted by the existing CSS rules in your component. If you really want all the elements in a component to have the scoping class, you can use the same trick that I linked to above: add the following rule to your component's CSS.
* {}
By default the generated class names are a hash of the component's CSS content. But you can also customize them with the cssHash compiler option. Note that vite-plugin-svelte also changes how the class names are generated, to be based on the file name instead of the content.
Since every element in the component would be targeted by this roule, this will cause the Svelte compiler to add the scoping class to all the elements.
If you wanted to automatically generalize this to every element of every component, you may want to do it with a preprocessor (if you need some inspiration, the code I've linked too actually implement this with a preprocessor).
I'm not sure if this is what you really want though. For one thing, only elements get a scoping class: components don't get a scoping class, because components don't have dedicated elements in the DOM (only the ones you may or may not add via the component's markup). The above trick would only give you a mean to select every element of a Svelte component. There might probably be easier or cleaner ways to achieve what you really want. For example, a simple wrapping component, or an action, that would use wrappingElement.querySelectorAll('*') or something...
If I create html template element which contains several css class definitions and then clone this template into 1000 instances using owns shadow DOMs, what happens?
I've experimented and I'm not sure if it creates also 1000 identical css class definitions in memory, what would not be efficient.
In Correct way to apply global styles into Shadow DOM is discussed duplicating of styles. Yes, all styles are applied to the elements, thus they are duplicated regardless of whether they are created using template or not. But what about class definitions? Are they shared between template instances or are they duplicated?
I'm trying to document a C# project using Doxygen.
With the default configurations, after generating the HTML output, this is what I get for the namespace documentation.
The output adds both Classes and Interfaces to the same list.
I've tried changing some of the configurations, for instance trying to set OPTIMIZE_OUTPUT_JAVA=YES to see if something changed, but nothing seems to change.
Do you know if it is possible to generate an output with two different lists, one for classes, other for interfaces, and possibly another for enums?
Thanks.
You could do this manually with pages.
DISABLE_INDEX = YES
GENERATE_TREEVIEW = NO
Then manually create pages for each of your categories and include the objects you want on each page.
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.
I want to make a table of data in a UiBinder. I need programmatic access so I can add data at runtime, but I'd like my designer to have access to header names, column styles, etc, in the ui.xml file.
Is there a solution that meets these needs? A Grid perfectly satisfies my programmatic access, but I don't see a way to specify rows or cells in a Grid from the ui.xml.
I'd let the designers change the style via CSS files: Either include those in your host page, or use CssResource in a ClientBundle.
The header names etc. can be provided e. g. by properties files via GWT's internationalization Constants (even if you only want to support one language).
If you want to go one step further, and let the designer specify, which columns to show, and in which order, then it might be a good idea to create your own widget. Maybe the CricketScores example serves as a good starting point on how to use an XML attribute to specify the columns from your ui.xml.