I have a table component, and each cell have to have a parsys (to allow authors to drop text, images, etc). That parsys must have a bespoke text component (in-house) within it as default.
In Sightly I've tried the following without results:
<sly data-sly-resource="${'table-col-header-{0}' # format=[column], resourceType='/libs/wcm/foundation/components/parsys'}">
<sly data-sly-resource="${'table-col-header-text-{0}' # format=[column], resourceType='/apps/componentlibrary/components/content/text'"/>
</sly>
Depending the actual limits in terms of rows/columns I would either opt for the cq:template node approach or an extension of the parsys which would include functionality to include pre-defined components. The OOTB parsys only includes what's pre-defined by templates (either page templates or component specific templates)
The cq:template node approach consists out of adding a node under the component definition which contains the structure it should have. This would allow you to predefine a text component (or other stuff) for each cell. But this would require finite limits on your rows and columns. If a component is added through the sidekick (and I believe the touchUI as well - but not 100% sure) it copies the whole structure of this node onto you're component location. Which in your case would mean that every single row/column would be copied and would result more nodes in the repo than you actually need (most of the time). This approach would be fine as long as the limits are rather low. Be aware that this approach does not work if you would include this 'table' component directly inside another component.
The second approach requires you to extend the parsys component to make it 'smarter' and provide 'default' items. This is more flexible, but also subjects to dealing with changes/enhancements that Adobe makes to that component.
As per the specification, data-sly-include should be used with a script.
Related
I wanted to modify my problem and broke it down to some groups.
None of the groups have solvers attached to it. So they are just groups (composed of few components) that make it easy for the user to
differentiate various parts of the product. (each being a group).
I am confused with the IndepVarComp() and Metadata (declared in the initialization)
So far I have always used a single group and a single IndepVarComp() where the outputs were always the design variables.
If I continue this approach I could use metadata and pass large dictionaries i.e self.options.declare('aa', types=dict).
But looking at other codes based on openmdao, they seem to use indepvarcomp as if it is the metadata (ie. they dont change during iterations.and they are used as a component inside that group)
Could you guide me if one or the other is right way to
IndepVarComp outputs should be used for any output that could conceivably be a design variable or a parameter that you might wish to change in your run script.
Metadata should be used for anything that is explicitly intended to be constant. It is intended to be set once during instantiation and then not changed after the fact.
My firebase project is growing fast and I have a lot of children in some paths (the structure is kept flat as possible).
my tree looks like this
/client/section
-key: value
-key: value
...
In some sections I've got 80k+ children and growing fast (I could easily hit 1mil+ in a few months). I was thinking of splitting the sections into section1, section2,... but the problem is that I have to do the numChildren (which of course loads all the children) check before I insert another child (to keep the section inside the desired limit).
Another idea was to change the section to date Y-m-d or just Y-m but that would again generate a lot of paths.
With the new schema I'd also like to add some properties to the current children (so I have to do some work on the schema anyway).
Another idea was to feed this data into a relational DB.
I'd like you input on how to structure the schema for the future.
Thank you!
I have the following problem:
I have a list of Components, that contain Rectangles with a width of either 200 or 800. I'd like to filter this list, and only create objects of the Rectangles with a width of 200 as I work on a small screen.
Preferably I do not want to create all objects, check their width, and destroy those with the wrong width again. For obvious reasons I really only want to create those with a width of 200.
To do this I would need to aquire knowledge of the width, before I instantiate them.
As far as I have seen, there is no publicly available and documented way of introspecting/reflecting the Component prior to it's instantiation.
My question is: Is there a non-public way to gain knowledge about what is packaged inside of my Component? Might it be possible with C++?
Or would it at least be possible to find out what kind of Object is encapsulated? Whether it will be a CustomComponent1, a Button, a RedRectangle...
Unfortunately not. You can't even predict it, since the Component could even point to a qml file that hasn't even been downloaded yet, if it was fetched from the network.
There are a couple of things you can try though, if you have room to approach the problem from another angle:
What you can do is pass properties from outside the component into it as it gets created. Assuming you control the code within the Component, you can then adjust how the internal elements get created based on the value of the property(ies) that was(were) set from outside.
If that's not good enough, say your Component provides multiple elements and you only want to create the ones that match your criteria (possibly a combination of many), then you can introduce a second Component layer within the first Component, and have that second Component either create the actual element if it matches your criteria, or an empty Item{} if it doesn't, which is as close as it gets to not creating anything.
I hope that helps!
I have standard basic article content type which, amongst other things, contains an image field which is configured to contain an unlimited amount of values.
I'm now trying to create a view that lists some of the fields in this content type but I want to limit the number of images that are returned for this specific field to 3 random images in the list (or less). Is this something that can be achieved right in my view configuration or do I need to do something ninja? I'm not aware of everything that's possible php wise to "rewrite" / "filter" the results of my view but I'm confortable with anything programming related.
I'm using drupal-7 with Views 7.x-3.0-alpha1
Thanks!
AFAIK there is no way through the Views UI to randomize the selections of a grouped field.
I can see two possible ways, in theory to achieve what you want.
Use hook_views_query_alter to alter the SQL query for the view. I'm not sure Views support what you need to randomize the results, but you have the ability to alter the query that views generates, and might be able to randomize it.
Select all results, but using theming to only show the randomly selected options. This could be done in a preprocess function. Views provides several, depending on your display option, hook_views_view_unformatted might be what you need.
I effectively want two nodes:
Normal Node
Premium Node
The only difference will be that the premium node can take more images and a few other features. What is the best strategy to go about this?
have two distinct nodes with the differences
have one nodes and somehow find a to apply an UPGRADED attribute to it?
I would prefer (b), as I want users to be able to upgrade nodes. And migrating a normal node to a premium node will be very difficult.
Any idea how I can accomplish b?
I would create two different content types (CCK), and either write custom code to translate between the two or use a module like Node Convert (in order to upgrade a node); it might be complicated at first, but you would have the advantage of being able to apply all of your restrictions (allowed image count, permissions etc) on a per-content type basis.
Here is an excerpt from the Node Convert project page:
... adds a menu tab "Convert" on the node view page, i.e. node/1/convert, which gives the ability to convert the node from its current node type to another node type. The module provides the means to transfer all the field values of the current node type into fields on the destination node type, or discard them.
The module integrates with Actions, Rules, Views Bulk Operations and Admin Views nicely. It has support for exporting templates into Features using CTools Exportables. It also provides a hook that enables developers to execute additional code on conversion.
You might be able to implement (b) as two different input filters - one for non-upgraded and one for upgraded. Then "upgrading" the node would be as simple as changing the input filter applied to its contents.