Bug 103288 - ItemSearchWidget returns a ContentBundle but expects a ContentPage
ItemSearchWidget returns a ContentBundle but expects a ContentPage
Status: CLOSED WONTFIX
Product: Red Hat Enterprise CMS
Classification: Retired
Component: other (Show other bugs)
nightly
All Linux
medium Severity medium
: ---
: ---
Assigned To: Archit Shah
Jon Orris
:
Depends On:
Blocks: 108447
  Show dependency treegraph
 
Reported: 2003-08-28 11:38 EDT by Randy Graebner
Modified: 2007-04-18 12:57 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-11-10 16:02:01 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Randy Graebner 2003-08-28 11:38:50 EDT
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:
Comment 1 Randy Graebner 2003-09-07 12:40:01 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.