Is that possible? I tried doing it using the admin GUI. When I add the attribute it dissapears from the available attributes, as usual, but if I move it inside the groups on the attribute set there is no option of "copying" or alike.
I realized of this issue as programmatically we are importing products, categories and attributes. On the language attributes we have for example german. It is used in several places, for manual language, for titles, descriptions, etc. We didn't knew about it and just realized when detected that the attribute is only found on the last created group where it was placed.
If it is not possible then how do we solve this issue? Should we create several different attributes to be used on different groups inside an attribute set? Maybe german_manual, geman_language or something similar? Or there is already a solution for this and we do now know it?
Hope I have clearly described my question, is somewhat complicated.
Attribute Set is virtual box for attributes (we can consider attributes as physical properties). Groups inside one Attribute Set is just more virtual boxes to split one big "box" (Attribute Set), they are created to simplify attribute management, divide Attribute Set on logical containers.
Now as I understood from your question, you want 1 attribute to be assigned to 2 different Groups inside 1 Attribute Set. It's the same that put 1 stone into 2 boxes...
Related
I am trying to crawl different websites (e-commerce websites) and extract specific information from the pages of each website (i.e. product price, quantity, date of publication, etc.).
My question is: how to configure the parsing since each website has a different HTML layout which means I need different Xpaths for the same item depending on the website? Can we add multiple parser bolts in the topology for each website? If yes, how can we assign different parsefilters.json files to each parser bolt?
You need #586. At the moment there is no way to do it but to put all your XPATH expressions regardless of the site you want to use them on in the parsefilters.json.
You can't assign different parsefilters.json to the various instances of a bolt.
UPDATE however you could have multiple XpathFilters sections within the parseFilters.json. Each could cover a specific source, however, there is currently no way of constraining which source a parse filter gets applied to. You could extend XPathFilter so that it takes some extra config e.g. regular expression a URL must match in order to be applied. That would work quite nicely I think.
I've recently added JsoupFilters which will be in the next release. These should be useful for your use case but that still doesn't solve the issue that you need an implementation of the filter that organizes the resources per host. It shouldn't be too hard to implement taking the URL filter one as a example and would also make a very nice contribution to the project.
I have multiple Category Bitmaps.
I need it like that for other reasons. (ARKIT w/ SCNTechnique + Metal)
I have a SCNTechnique.plist with a specific pass where i want to exclude 2 specific categories, but i can't add 2 "excludeCategoryMask" in the .plist in the same pass.
Is it impossible to do excludeCategoryMask for two different category bitmaps for the same pass?
If so, it's kind of ridiculous, to have such limitation.
Hope some1 can help.
I copied this grid from another WP and seems like its not working. No clue why. Checked all I can but it doesnt work. In the other WP it works properly with another grids.
Any ideas?
Check the columns in the new grid. Does it have the same attributes than the source grid?
If you copied them from a different KB, it is highly possible that the attributes does not keep the same...
The specifier tries to find to which table the attributes belong. Don't think 'it should work because I copied it from a working wkp' , instead think 'some attribute is messing the specification' and take one by one out until it works, check if the obtained table is the desired one or another one. If it is the desired one, then the last attribute you withdrew is the one messing up the specification process. If it is another table than the desired one, try to withdraw from the grid the remaining attributes and put the ones you withdrew before back into the grid, and repeat the process. At some point you will understand which one is messing up. Also keep in mind that there might be other places with attributes, such as in the 'Load Event', they also influence the process.
It means that Genexus can not resolve the base table, you may be using (or referencing) attributes of different transactions and genexus can not resolve the relationship between them.
I have about 100 special attributes in the default attribute set.
Would I have better or worse performances if I would create about 200 attribute sets (nearly one for each category) and spread the special attributes in those?
Knowing that one special attribute may be in 1 or many attribute sets.
Did someone already made a benchmark for this, or the changes on the performances of the application would be insignificant?
Thank you.
You need to think about the information architecture of your site so that it is efficient and befitting your products. Some consideration is also needed for how you get your data into the database.
For instance, say you sold clothes. You could have different attributes for size, e.g. 'shoe size', 'waist size', 'glove size', 'collar size' and so on. You could then make different attribute sets for 'shoes' where you would just have the 'shoe size' attribute and not the other 'size' attributes. You could also have a 'shoe width' attribute on the 'shoe' attribute set. This would give you fine control over the presentation of the product on the front end, however, when importing data from some supplier CSV you would need to make sure that the attribute set was imported/set too. This may not be operationally sensible if importing thousands of sku's, some of which are shoes, some of which are coats etc.
Some catalogues just have the one attribute set and just the one 'size' attribute, this becomes hard to manage if there are lots of sizes, e.g. trousers can come in lots of lengths and widths and you need attributes like '32W 32L', '32W 34L' and so on, bulking up the attribute option values.
Once you get too many attribute option values it becomes impossible to change/amend them in admin and it becomes impractical to list them in the front end. Performance problems in terms of loading the catalogue can be mitigated against by Magento tricks, e.g. cache, however, if it is operationally possible to use as many attribute sets as are needed to model your products in the best way, then go for it, the pay off will be in improved performance.
There is also a side benefit in that if you do have lots of attribute sets then you can send layout handles to the front end based on attribute set. For instance, if you wanted to show a size guide then you could base that off the attribute set, so 'shirts' would have a different guide to 'shoes'. (In reality you would probably want to make size guides brand specific, but shipping, returns policy and other product content could change based on attribute set as far as front end presentation is concerned).
Let's go with the toolkit example of LongListSelector, but say I'd like to display a flag of its country with the city name, in the GroupHeader.
Is this even possible?
If yes, how and what kind of a strategy do you propose? Remember the cities are grouped by name, and the Flag Image path is not part of the key. The Country name and FlagImage could be in a master table or List for lookup.
It appears to that the simplest solution is to add an image (which uses a converter) to the GroupItemTemplate and the GroupHeaderTemplate and have a lookup up in the converter which determines which path to use for the image based on the key. (Option 1)
Alternatively you could use a compound key (of the group name and image path) for the List being displayed but this might require changes to the toolkit code and so is, potentially, more complicated. (Option 2)
I'd be more drawn to the second option as it feels cleaner to me. The first option feels like a bit of a hack, and I only like to use converters when I have to.
The second option requires you to be happy with the potential long term consequences of adding your own customizations to an open source project which could change in the future in ways which could break your changes.