Bug 103288
| Summary: | ItemSearchWidget returns a ContentBundle but expects a ContentPage | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Enterprise CMS | Reporter: | Randy Graebner <randyg> |
| Component: | other | Assignee: | Archit Shah <archit.shah> |
| Status: | CLOSED WONTFIX | QA Contact: | Jon Orris <jorris> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | nightly | CC: | sseago |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-11-10 21:02:01 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 108447 | ||
I have implemented solution 1 for Carrefour with change 35726. Basically, there
are a couple of things that I did
1. Change ItemSearchParamter to accept a ContentItem instead of a ContentPage.
2. Change ItemListModel.java's getKey method. If you map to a bundle the link
does not work so you have to return the key of the primary instance or of a
negotiated instance.
3. I created a Carrefour specific DomainObjectXMLRenderer that overrode the
"walk" method found in DomainObjectTraversal. For CMS, you may want to create a
MultiLingualContentItemXMLRenderer that extends DomainObjectXMLRenderer. This
required me to cut and paste code from DomainObjectTraversal since the code was
not abstracted out enough. I change the section of the "if" block starting with
"else if (propValue instanceof DataObject) {" to check for a ContentBundle and
if so, negotiate the correct item. This works well for Carrefour's purposes. I
then had to change all of the "import" statements to use my new class.
Now, I have to go through and fix the visibility problems with the ContentGroup
set of forms.
|
Description of problem: The ItemSearchWidget and ItemSearchParameter but right now it allows you to browse/search the content section for a ContentBundle. The ItemSearchParameter expects to have a ContentPage and when it gets a ContentBundle (which extends ContentItem) it is not very happy (throws a ClassCastException). So, we need to find a way to map items to each other. I see a couple of obvious ways to do this: 1. We can change ItemSearchParameter to take ContentItems rather than ContentPages which would fix our ClassCastException. If we do this then we would be mapping the ContentItem to a ContentBundle. In the common situation, the item is generated by the DomainObjectXMLRenderer which means that all of the instances under ContentBundle would be printed out which means that our XSL would have to do the language negotiation which is not easy. One way around this is to override DomainObjectXMLRenderer for the Item so that it treats the "content group" property different (DomainObjectXMLRenderer should allow this). This would allow the locale negotiation to happen at the java layer so the xsl is not too difficult. However, if you do this, then do you still make every instance of the item create individual mappings to the content group? Or do you override some code so that acting on one item actually acts on all instances of the them? For Carrefour, mapping them individually would probably be the best. 2. We can change the ContentGroupForms to not show ContentBundles but rather show actual instances, by language and have the user select that. This seems like the most clunky interface and the most work so I would probably shy away from this approach. 3. We can do the locale negotiation at the time of the mapping so even if they pick the ContentBundle when the mapping takes place it would call bundle.negotiate(XXX) and then map the returned item. This may be the easiest solution but it raises the problem of "what if they map a bundle with only a French instance to all 4 instances of an index and then they go back and add 3 more instances to the original bundle...now, you have 3 instances of the index mapped to the 'wrong' language". 4. We can add a step to the mapping process where, after they select the bundle they then select the instance to map it to. Ideas 1 and 4 appear to be the best but I don't have a strong requirement and Carrefour does not have a strong requirement other than the correct languages should match up. However, this is a problem that Carrefour will have to solve in the coming week...although a client specific solution in this case may not be the worst thing. Version-Release number of selected component (if applicable): 6.0 How reproducible: Always Steps to Reproduce: 1. Create an authoring kit that uses a ContentGroup and try to map an item 2. 3. Actual results: ClassCastException Expected results: Mapped item Additional info: